Navigation Fails on the Street after 18 Minutes

[K-Leon]

I'm experimenting with latest Master - on Simulator everything works fine, but as soon as it is running in the Wild on a real Device the whole thing get's slower over time and around Minute 18 it slows so down, that the device goes black and "hangs in Lock Screen". There is no error Message - nothing. Just a Device freeze. If you stop the car and wait for about 2-3 Minutes everything recovers. It seems like there accumulated a lot of Processing tasks.

I'm still investigating, but is there a possibility of an Memory Leak ( Objects not getting freed ) or there is exponential more processing time with increasing amount of Location Fixings? The 18 Minute Mark is reproducable for me - but only on the Street. Not in Simulator.

My implementation follows the proposed from the newly merged UI Lib.

[K-Leon]

Additional Info:

09-09 21:41:39.430 788-808/? E/ActivityManager: ANR in com.android.systemui
                                                PID: 31952
                                                Reason: Broadcast of Intent { act=android.intent.action.TIME_TICK flg=0x50000014 (has extras) }
                                                Load: 15.67 / 15.64 / 13.3
                                                CPU usage from 4108ms to -11220ms ago:
                                                  98% 20065/com.example.navi: 81% user + 16% kernel / faults: 35913 minor 2 major

Edit:

Going forward i could verify it's a performance issue occuring on older Devices which are overheating. Lowering the fastestInterval Time helps, but this makes the Tracking really hard / inconvenient.

I already tried an Workaround for #210 (it's not clean - so no PR yet). But it's not helping enough - is there something else which could help reducing the processing amount significant?

Reducing the max Update frequency to 2 Seconds helps, but makes the user experience worse.

[davols]

Interesting. I haven't reproduced it myself. However I've been running street tests with LG G6, Pixel XL and OnePlus 3 (They do get hot, at least the Pixel). But we've recently rolled out (small staged rollout) a version of our app with navigation and shall see if this pops up in the crash logs.

Reducing the max Update frequency to 2 Seconds helps, but makes the user experience worse

I definitely think it could help to have an implementation like #54 in order to make the UX better in such a case. Imo Kalman overall, for tunnels etc is a great feature. But I guess it would be possible to ask for a lower update frequency on lower end devices and rely more on a kalman filter/estimator.

[K-Leon]

You won't see this popping up in Crashlogger like Fabric. The Device stalls and eventually catches up if the driver stops or goes in an endless crash loop because it can't restore Basic OS Activities. So It eventually brings the whole device down.

We could reproduce it with an two year old Sony Xperia Z5. Other "Lower End" Devices got really hot - ready to cook a nice lunch ;)

[cammace]

@danesfeder resolved a number of performance issues in #219 which seems to have fixed this issue. Closing but if the same observation is made in a future test drive, please let us know.