[BUG] QuickCapture - when device sleeps, app eventually crashes

[pjdohertygis]

-------------Updated report using our new GitHub template------- App

• QuickCapture v1.18 (although it appears this issue has occurred in earlier versions as far back a v1.13)

Device / OS

• iPhone 13 with iOS 17.1.2 (although it appears this issue has occurred in earlier iOS)
• Android (will get models later)

Describe the Bug - App will crash (either close entirely or reload the orange loading screen) when the phone is locked and device has tracklogs on. We are still trying to determine if it is related to location sharing and/or having the map open.

Expected Behavior - App should not crash when collecting tracklogs for extended periods of time and varying internet connectivity.

Reproduction Steps -

Project(s)

• Sandbox https://arcg.is/14fK4

• Sandbox with Location Sharing (requires NSARGC access, contact Paul or Jared)

Scenario 1 - Long duration, tracklogs turned on, location sharing turned on. Go for a hike or long drive where there is intermittent internet access. It seems to occur most often when I go on hikes to the top of a mountain and take photos outside of the app. This may be coincidental but start with this use use case and narrow down the cause once it is replicated.

Scenario 2 - Same as Scenario 1 but with the Sandbox Project (no location sharing).

Scenario 3 - TBD.

Priority Impact: p1 time sensitive

Impact This crash may be occuring during incidents and not being reported. The outcome is potentially lost data if they did not know the app crashed and they continue searching an area. Therefore, while challenging to reproduce it is ideal if identify the root cause and fix ASAP.

------------Initial Report------------------ Here are results of a test I did yesterday. Is this expected? Is this something that is being addressed in v1.13 already or a new issue I should report through Esri Support?

I think the biggest concern isn't just the crash, it is the fact that there wasn't even an error message so the end user would not know it crashed.

[@xiao8579 @IsmaelInRedlands - hoping you are getting some well-deserved actual time off, but will send this is an email early next week, I just didn't want this to slip through the cracks.]

[xiao8579]

@pjdohertygis Our guess is that the crash is caused by the map (by Runtime). Can you try the above workflow without opening the map page, see if it still crashes? In the meantime, we're doing some tests too to investigate this.

[pjdohertygis]

@pjdohertygis Our guess is that the crash is caused by the map (by Runtime). Can you try the above workflow without opening the map page, see if it still crashes? In the meantime, we're doing some tests too to investigate this.

Ok I will test this tomorrow with the map closed. Thank you!

[pjdohertygis]

Here is a test by FL-TF2 with an iPhone 13 Pro

No crashes but probably a mix of leaving the map open and closed. This is decent battery usage, about what I expected. I wonder if using only LKL in v1.13 and no Tracker tracklogs if that will improve battery use?

[pjdohertygis]

@xiao8579 so results below suggest perhaps it is the map causing the crash. I'll try one more test tomorrow with map open on the SONIM device.

[pjdohertygis]

This happened again today....

[pjdohertygis]

Will try with TestFlight release v13.366 next week

[pjdohertygis]

It seems like the new build lasted a little longer before crashing?

[JohnHasthorpe]

@pjdohertygis - Are you still seeing this issue?

[KeithJGw]

These QC crashes seem like they may be related to this issue. 2023118 QC crashed Samsung Galaxy A53 inflight in Airplane Mode while returning from InSPIRE 2023 during tracklog entry and marked Other at 17SLV3450814645. I did not have the map open. Later restarted QC and tracklog at Other 16SFE6843849746. [Tracklogs entered as Other aren’t visible so later edited to Damage Observation.]

20231211 QC crashed / quit Samsung Galaxy A53 during online tracklog entry. I did not have the map open. Start 12/11/2023 5:02 PM Pacific, crash ‘End Time 12/11/2023 5:02 PM’ Track Length 6.69 miles marked with Other waypoint at 10SEH2583656221. [Traced remainder of the route via IM 1.0 as ExB 2.0 was difficult.] Also entered several tracklogs over a good distance on an older Samsung Galaxy J7 Star WiFi only phone with base map loaded before leaving that hasn’t crashed, yet.

[JohnHasthorpe]

@KeithJGw - What version of Android is running on the device?

[KeithJGw]

@JohnHasthorpe Sorry, I neglected to log the version at those times and know now to do so. For the A53, it's updated once or twice since the first occurance since returning from InSPIRE and one update since 12/11/2023. Last update was 12/16/2023 and currently it shows One UI version 6.0, Android version 14. I believe Android version 14. Sorry if that's not much help. The Samsung J7 Star that didn't crash is One UI version 1.0, Android version 9. Edit in: yes, on the A53 Android 14.

[KeithJGw]

Note: I've been able to enter several hundred miles of tracklogs on a Samsung A53 Android v14 without QC crashing except for those two times.

[pjdohertygis]

@JohnHasthorpe - I still see this issue almost every time I go hiking on v1.17 and now v1.18.

Currently I am testing on v1.18.94, iPhone 13, ios 17.1.2.

It may be related to going in and out of coverage but is very hard to replicate. Usually I am out hiking with tracklogs running, my iPhone will be locked and in my backpack outer pocket. When I get to the top of a peak to take photos and open QuickCapture, it will crash and open up again. The tracklog will be accurate up to the point of crash and local to the device. It sounds like this is happening in training and real-world events but going unreported.

I even tried restarting my phone to make sure it is not a memory issue.

I've sent along the diagnosis to quickcapture email, but not positive it will be capture in the logs. I'll keep testing.

[JohnHasthorpe]

@pjdohertygis - Could you share some further information:

• Does the app crash at the point that you open the app?
• Is location sharing on during the crash? i.e. is anything being sent to the server?
• Has the project map been opened in the QuickCapture project?
• How long has the app been recording a line before you get to the peak (i.e. what is the travel time)?
• Is console UI and logging active in the app? If so, can you re-test with both switched off?

We have your logs and review

[pjdohertygis]

@JohnHasthorpe Good questions. I will try to setup some testing sessions and reproduce the issue based on the questions below. As of 1/4 here is what I know / don't know. I'll also ask our user community to pay closer attention and report if they see this particular issue. During Hurricane Idalia, one task force (not a FEMA task force) complained that the app crashed several times, but the complaint didn't reach us for months later.

Does the app crash at the point that you open the app? In at least some instances, yes, I go to open it by swiping up (iPhone) and finding the app. At that point it goes to the orange screen to reload the app. In other instances, I recall the app just being closed on its own already.

Is location sharing on during the crash? i.e. is anything being sent to the server? Generally yes I share location using our Sandbox Location Sharing Project. I'll do more testing with both and see if there is a pattern.

Has the project map been opened in the QuickCapture project? Generally at some point I will open the project map before starting the hike - unsure if it was "left open" when I locked my phone. I will test leaving the map open, locking my screen and then hiking.

How long has the app been recording a line before you get to the peak (i.e. what is the travel time)? 2-3h maximum, in at least one instance only an hour. I'll start to keep track of that as well

Is console UI and logging active in the app? If so, can you re-test with both switched off? No I've turned off the console UI since you last mentioned this is an issue and don't think that is a factor since it has been happening since before I knew that existed.

[pjdohertygis]

This weekend 01/06 and 01/07 I did two tests with no crashes.

Test 1 - 90 minute hike, using location sharing, and map was left open while phone is locked. Intermittent internet. but never lost it entirely. Test 2 - 60 minute hike, using location sharing, and map was left open while phone is locked. 4G internet throughout.

Next weekend I'll try to get a longer more remote hike in that is more similar to US&R conditions during a hurricane.

[pjdohertygis]

@JohnHasthorpe after additional testing, it appears that we can replicate crashing behavior.

Open project Start tracklog After a while, take some photos or videos with iPhone 13 OUTSIDE of the app, just with the built in camera app. This results in a crash about 50% of the time, especially if in a low connectivity environment.

Next we will try to see if this a memory issue by comparing the crash rate with a freshly restarted phone or note.

[JohnHasthorpe]

Thanks for this feedback Paul. We will see if we can mirror this behaviour.

[pjdohertygis]

I am still seeing this issue from time to time - most recently during a hunting trip and somehow it appears that the tracklog I was creating was actually "lost".

[KeithJGw]

I'm also seeing it. Sometimes after taking pics in out of app and other times not. Also had a section of tracklog disappear maybe lost GPS lock, but it has the continual tracklog change into the store. I traced it in via Intel manager around the block and noted it in the tracklog comments and event point Other at 10SDH9880395058. Sorry I haven't done entries into GitHub for issues I've come across. Sometimes there is more than one issue at a time. I started a log in February and stalled around June and need to catch up. Although it has timestamp notes, it doesn't follow our GitHub issue format so not sure if it's usable or what to do with it. When QC crashes, I edit the tracklog to Damage Observation and add comments and add Other point w comments. If you filter my areas with tracklogs to team New Team / Other and Other, User name kjohnson_GISCorps and Damage Observation they stand out.