Conflict around push-to-talk (PTT) and media/podcast player

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use a media application (e.g. podcast player) while not using osmtracker 
(that app is not even started)
2. Long press the hardware media/home button

What is the expected output? What do you see instead?
Expected behavior: stop/start the media playing (as it has always done
Actual behavior: media playing continues or doesn't start, while a beep is 
heard, and when unlocking the screen, osmtracker is started, trying to find 
satellites.

Also, since osmtracker wasn't running, the application is showing it is 
recording track #0 (which doesn't exist). To Stop osmtracker, one has to press 
the Save button. The track in question (even if the satellite fix was obtained) 
is nowhere to be found.

What version of the product are you using (See "About" screen)?
v0.6.8.
This behavior wasn't the case in previous versions. I suppose this commit 
introduced this issue:
https://github.com/nguillaumin/osmtracker-android/pull/43

Make/model of your device, and Android version?
Samsung Galaxy SII - Cyanogenmod 10.1.3 (Android 4.2.2)

Please provide any additional information below.
I would suggest either:
- adding an option to not use the push-to-talk (PTT) feature in osmtracker
- make the PTT feature only work when osmtracker is functioning (i.e. a track 
is currently being recorded)

I use my media player much more often than osmtracker, and it is very useful to 
be able to long press a hardware key to stop the media from playing, when e.g. 
somebody talks to you, instead of having to get your phone out of your pocket 
and press the pause button, or just taking the plugs out of your ears and 
having the podcast continue to play (and then having to unlock the phone and 
try to go back to where you were). With the new PTT feature of osmtracker, this 
is unfortunately what I now have to do.

I use AntennaPod as my podcast player.

Original issue reported on code.google.com by emil...@klein.st on 20 Jan 2015 at 9:26

[GoogleCodeExporter]

Interesting... Unfortunately I'm not very familiar with the code since it was 
contributed by somebody else.

AntennaPod seems to be open source so there might be some clues in there: 
https://github.com/danieloeh/AntennaPod/

Original comment by nicolas@guillaumin.me on 20 Jan 2015 at 10:36

[GoogleCodeExporter]

I suspect it's priority related, after having read:
- 
http://android.stackexchange.com/questions/13620/what-determines-which-applicati
on-acts-to-a-bluetooth-avrcp-command
- https://code.google.com/p/media-button-router/
- https://groups.google.com/d/msg/android-developers/494TKtLrD2U/UfJ7pc2tWUYJ
- 
http://android-developers.blogspot.com.au/2010/06/allowing-applications-to-play-
nicer.html

So there doesn't seem to be a "proper" fix... Perhaps, according to this last 
blog post, removing the MEDIA_BUTTON intent in the manifest, but keeping the 
registerMediaButtonEventReceiver() call would cause it to react to the button 
only when the app. is in foreground?

Original comment by nicolas@guillaumin.me on 20 Jan 2015 at 10:45

[GoogleCodeExporter]

Looking at AntennaPod's code, they also have the MEDIA_BUTTON intent defined in 
the manifest:
https://github.com/danieloeh/AntennaPod/blob/9659c18d899349d9be1573fb9520defc7d3
a19cd/core/src/main/AndroidManifest.xml#L31

However, the difference I've seen is that osmtracker defines that intent with a 
priority of 10000, which I assume is a high priority that overrides the others. 
Might removing that priority solve this issue?
https://github.com/nguillaumin/osmtracker-android/blob/6c1eb906a137aef821e188497
bf0742fe854cbbb/AndroidManifest.xml#L49

From the Android documentation 
https://developer.android.com/guide/topics/manifest/intent-filter-element.html

Use this attribute only if you really need to impose a specific order in which 
the broadcasts are received, or want to force Android to prefer one activity 
over others.

The value must be an integer, such as "100". Higher numbers have a higher 
priority. The default value is 0. The value must be greater than -1000 and less 
than 1000.

I'd thus suggest removing the priority.
If you want to create a temporary .apk, I'm willing to test and let you know if 
this solved the problem.

Original comment by emil...@klein.st on 20 Jan 2015 at 11:56

[GoogleCodeExporter]

If we remove the priority it goes back to zero I guess, how can we be sure that 
the PodCast app. will take precedence if they're both at zero?

That might fix this specific case, but that wouldn't work with other apps that 
set a negative priority for instance. That's why I thought it would be neat to 
find a solution that works everywhere such as catching the event only when 
OSMTracker is in the foreground (assuming that works).

That being said it's probably worth testing removing the priority to see if 
that helps...

Original comment by nicolas@guillaumin.me on 21 Jan 2015 at 8:12

[GoogleCodeExporter]

Prior to osmtracker implementing this feature, if I pressed the media button 
when AntennaPod was not running, nothing would happen. So it looks like 
AntennaPod has found a way to only handle the call when it is not running. 
Might it be that with a high priority, Android itself keeps track of that and 
wakes the app up, as it is "so important"?
Let's see what happens when the priority is removed.

Original comment by emil...@klein.st on 21 Jan 2015 at 8:41

[GoogleCodeExporter]

Hi Nicolas, any possibility you'd create an .apk with the priority removed, so 
that I can test it out?

Original comment by emil...@klein.st on 28 Jan 2015 at 2:29

[GoogleCodeExporter]

Sure, attached.

Note that you'll need to enable a developer option to be able to install this 
unsigned APK, and it's likely you'll have to uninstall it when switching back 
to the official version so there's a risk you'll be loosing your tracks... Make 
sure you backup everything!

Thanks.

Original comment by nicolas@guillaumin.me on 28 Jan 2015 at 11:10

Attachments:

• OSMTrackerAndroid-0.6.9b-debug.apk

[GoogleCodeExporter]

Issue 260 has been merged into this issue.

Original comment by nicolas@guillaumin.me on 4 Feb 2015 at 8:22

[GoogleCodeExporter]

Thanks for the test .apk Nicolas.
I have installed it, and the incorrect starting of OSM doesn't occur anymore.
Note that I had not tried to use the actual push-to-talk feature in OSM before, 
so I'm not really sure how/when it should work. I've tried running the 
application (from the test .apk), recording a track, got the GPS fix, then 
locked the phone/shutting down the screen, turned it back on, and long-pressed 
the home button. That didn't result in a voice-memo being taken though.

As far as I'm concerned, this is fixed (not starting while I'm running my 
podcast app) but I'm not sure if this feature still works as supposed to.
On Github I have asked zdila, who added this feature, to comment on this issue.

Original comment by emil...@klein.st on 4 Feb 2015 at 8:53

[GoogleCodeExporter]

Cool thanks for testing! I'll wait a bit for zdila comment and release it soon

Original comment by nicolas@guillaumin.me on 4 Feb 2015 at 8:54

[GoogleCodeExporter]

I can confirm the APK has also fixed the issue (260) I was having on my Xperia 
Z1 Compact running Android 4.4.4.

Doesn't record a voice memo for me when actually in OSMTracker - but that's 
probably because I've got "Headset Button Controller" intercepting the Mic 
button as a Play/Pause command for a specific music app.

Original comment by kevswind...@gmail.com on 5 Feb 2015 at 8:36

[GoogleCodeExporter]

Original comment by nicolas@guillaumin.me on 6 Feb 2015 at 11:50

• Changed state: Fixed
• Added labels: v0.6.9

[GoogleCodeExporter]

I tried three different phones (Runbo X6, Sony ST21i (Xperia Tipo) and Lenovo 
Yoga Tablet 2) with two headphone sets (one with single button, second with 
three buttons).

Good news is that it works without setting priority on intent-filter.

Strange thing is that even with priority set to 1000 I was unable to reproduce 
reported issue with any phone or headset I listed.

I think you can close this issue.

Original comment by m.zd...@gmail.com on 28 Feb 2015 at 11:16