The issue was most likely related to a race condition (selectedTrackId can change in the UI thread, while the track is being processed in the handler thread).
Simulated slow drawing by adding 50ms, works pretty cool :)
Found in user error reports (3rd top issue):
java.lang.StringIndexOutOfBoundsException
at com.google.android.apps.mytracks.util.ChartsExtendedEncoder.getEncodedValue(ChartsExtendedEncoder.java:45)
at com.google.android.apps.mytracks.util.ChartURLGenerator.getChartUrl(ChartURLGenerator.java:162)
at com.google.android.apps.mytracks.util.ChartURLGenerator.getChartUrl(ChartURLGenerator.java:60)
at com.google.android.apps.mytracks.util.StringUtils.generateTrackDescription(StringUtils.java:366)
at com.google.android.apps.mytracks.io.SendToMyMaps.doUpload(SendToMyMaps.java:581)
at com.google.android.apps.mytracks.io.SendToMyMaps.access$10(SendToMyMaps.java:538)
at com.google.android.apps.mytracks.io.SendToMyMaps$5.run(SendToMyMaps.java:517)
at android.os.Handler.handleCallback(Handler.java:587)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:123)
at android.os.HandlerThread.run(HandlerThread.java:60)
In particular:
1) Add a workaround to {start/end}Recording to update recordingTrackId to trigger a notification
2) Add a bunch of unit tests for MyTracks
3) Clear minor style issues in a few classes
Allow users to choose the default track name policy. By default, we'll switch
to a new, timestamp-based name. If they change the pref, they'll get the
old-style 'track n' style.
1) Make sure no one but service changes recordingTrackId (which is owned by it)
2) Cache sharedPreferences
3) Clear recordingTrackId if it doesn't correspond to a valid track or the service is not recording
4) More unit tests
Sandor Dornbush