Why does my App crash at 8.05 or 8.06 km of activity recording?

I'd suggest placing System.println() statements at strategic points in your code, and then create a .txt file in /GARMIN/APPS/LOGS to capture the output. The .txt file must be named to match the name of your PRG (e.g. myapp.prg -> myapp.txt). This may help you narrow down where the crash is occurring if you're not sure.

It's odd that there's not CIQ_LOG.txt entry--do these crashes ever cause the device to reboot, or does the app just quit? If the device crashes/reboots, look for an ERR_LOG.txt at the root of the device's mass storage volume and send that along to me. As a last resort, we could look at your source if you're willing to forward it to us (send to [email][email protected][/email]). My main concern is that there's some kind of VM bug that you're encountering.

Thanks, Brandon. This is really very helpful!

I'd suggest placing System.println() statements at strategic points in your code, and then create a .txt file in /GARMIN/APPS/LOGS to capture the output. The .txt file must be named to match the name of your PRG (e.g. myapp.prg -> myapp.txt). This may help you narrow down where the crash is occurring if you're not sure.

I didn't know this, but it is an excellent suggestion.

So far I had implemented a debug property which is stored as part of the app's properties in each and every suspicious or important function in my source code (this slows down the app quite significantly, BTW). First thing on the next app start is to read the property and display it at the screen. Turns out that in all tested cases the app terminated around 8.05 or 8.08 km "nominally" by calling the onClose() function and completes it. Looks like a fairly normal shot down. However, it is NOT INITIATED by the user. No button or menu press involved.

It's odd that there's not CIQ_LOG.txt entry--do these crashes ever cause the device to reboot, or does the app just quit? If the device crashes/reboots, look for an ERR_LOG.txt at the root of the device's mass storage volume and send that along to me. As a last resort, we could look at your source if you're willing to forward it to us (send to [email][email protected][/email]). My main concern is that there's some kind of VM bug that you're encountering.

See above. Apparently the app closes down in a fairly nominal way - however without any external interaction. Sure I would be willing to share my (currently pretty ugly and messed up) source code with you, but first I'll try your suggestion to write to a log text file and see whether I can nail it down myself.

OK, Finally I could nail the problem down (and I believe it is not an App problem but a system issue).

After some debugging, using Sys.println-statements, it turned out that my App was terminated nominally, i.e. by closing the FIT file, terminating the session, saving the status etc. However, the termination was not caused by the user. No button press or any other action. It was also not caused by an App-internal condition. It was rather caused by the fact that I called the nominal app termination function in the onHide() method of the View, as the template recommends ("Save your App's status here").

Now the question is why onHide got called at all, and why it was always called between 8.05 km and 8.12 km. On one occasion I noticed by pure luck that the system had opened a screen that looked a bit like a 2 or 3 data field display. My App does not invoke any of these. So the system does, for whatever reason. And it only does so on the actual device, never on the simulator.

I noticed the same unwanted and unpleasant interruption of my App when I try to set a lap marker. This doesn't happen silently in the background, but for some reason the system pops up a screen that is unwanted. This does NOT happen on the simulator, either.

I really believe that this is a bug or at least unwanted and disturbing "feature" of the system. Can anybody look into this, please?

(BTW: I fixed the app by removing the cleaning-up code from onHide() and execute it only on a user-initiated Menu item to terminate the session).

IIRC, there is an automatic close of the recording after a certain amount of time of no activity on some devices (something like 5 minutes but it could be more). Could it be a time issue and not a distance issue? The screen you sometimes see at the could could be the "resume" screen when it hits the timeout. This is there in the case where you are a recording something, but forget to end the recording - so that the recording doesn't continue forever....

As far as marking laps and getting the system lap display on the real device, I see the same thing, and there seems to be no way to disable it. But in my app, it's not a concern, as it goes away in a few seconds. It doesn't show on the simulator, and is just one of the ways the simulator differs from the real devices.

To test the timeout theory, you don't need to walk 8.x kms. Just start the app and don't go anywhere for a while! :)

Apps should not time out after any period of inactivity. There was a bug in older Fenix versions that would cause apps to automatically close after a timeout period.

The native lap screens appearing is the default behavior of the system. There are apps that prefer having this behavior, so I don't believe we will completely remove them, but an option to disable these is under consideration.

Regardless of the lap behavior, triggering app state in onHide is not something you want to do. There are other system events that can cause a native view to push over your main app view. On the Fenix 3 pressing the Clock key (hold Down) will push the native clock page over your app from any context.

The "Save your App's status here" comment should not be associated with onHide. That comment would be more appropriate for onStop. We will check the comments in the default template.

It seems the auto-lap feature is not being disabled for your activity and is triggering at 5 miles (8.04672km). This is a bug, and we will look into that as well.

Could it be a time issue and not a distance issue? ...

To test the timeout theory, you don't need to walk 8.x kms. Just start the app and don't go anywhere for a while! :)

It is not a timeout issue.

I tested (for example, among others):

1) Over night, F3 on a table, recorded for 7 hours straight. The distance was small (accumulated GPS errors). No problem encountered.

2) On a motocycle to reach the 8 km in a reasonable time (if you want to reach 8 km playing golf, you would have to go on a 18 hole round and spend half a day). The app terminated while driving.

So for sure not a time/inactivity issue. But thanks anyway.

It seems the auto-lap feature is not being disabled for your activity and is triggering at 5 miles (8.04672km). This is a bug, and we will look into that as well.

Thanks a lot, Brian. Your help and support is very much appreciated!

This confirms more or less my suspicion. My app should be fine now (unless I produced a different bug), and is already uploaded to the store.

This 8.05 km bug was in the device firmware, and was recently fixed. It should be available in the future 920XT firmware release.

By FIX - the CIQ guys meant remove that feature entirely and thus one have to implement the lap screen manually