Alright, so I'm writing an app to make an external headset perform certain functions. I'm trying to replicate functionality similar to this guy:
https://market.android.com/details?id=com.kober.headset
The list of things it can make the headset button click do is: play/pause, previous track, redial last phone #, launch specified app, etc. I don't know how to do this stuff though! Sort of lost with how to get started here. I'm also kind of confused how the overall program flow should work.
Right now I can register button clicks via a broastcast receiver and correctly and pass that number (single/double/triple click) to a service to run in the background. I'm using a background service so the user doesn't need to be in the app to use the functionality.
Am I on the right track? How do I go about making clicks play/pause music, next/previous track, etc? Are there certain intents I should be using?
Cheers.
Am I on the right track?
Be sure to stop your service when it is no longer needed (e.g., after you have determined the clicks and performed the operation). Otherwise, I see no problems there.
How do I go about making clicks play/pause music, next/previous track, etc?
First, write a music player app. There are no documented and supported APIs to "play/pause music, next/previous track, etc" for most of the several thousand music players out there.
Related
I'm debugging the integration of a media app with Google Assistant, and everything is working as planned, except for one thing. When a phrase is spoken that should send ACTION_SKIP_TO_PREVIOUS to my app's media session (eg: "Previous song | track"), it first sends ACTION_SEEK_TO for position zero, followed immediately by ACTION_SKIP_TO_PREVIOUS.
Whilst in most use cases this would be OK (assuming each queue item is a single track), in my case the queue consists of a single track, which I split into "chapters". My handler of ACTION_SKIP_TO_NEXT and ACTION_SKIP_TO_PREVIOUS handle these chapters, but by seeking to position zero first (which is the start of my first chapter), this makes my handler unworkable.
Curiously, only the voice activated action does this. Manually tapping the button (e.g. on the Android Auto head unit display) sends only ACTION_SKIP_TO_PREVIOUS, as expected.
Is it possible to disable this automatic ACTION_SEEK_TO behaviour? I understand why in many typical use cases it could be helpful, but not this one. Is there anything that can be done (other than not enabling ACTION_SEEK_TO, which works but I'd rather not do)?
I want to use the media buttons to control a foreground app, but not for audio use.
So the goal is to detect button clicks to do certain things in the app.
I can achieve that by using MediaSession and the MediaButtonReceiver. see here
The problem is that when the app is used, often users play music in the background, so the audio focus of the background app takes over the MediaSession and i cannot control my app anymore.
Is there a way to achieve that? Directly listening for button clicks with onKeyDown does not seem to work.
sadly there is no way for two active MediaSessions at the same time. if another app is playing music and run MediaSession then yours doesn't have focus and isn't active... this is made for purpose - better UX - only one "player" app can play music (or video). if this wouldn't work like that and you could play music by few apps at once then how should work media button on e.g. headphones? pasuing/resuming all players? this is just not user-friendly, so Android team introduced MediaSession pattern with option for calling "focus on me now" by any app, but then another app/MediaSession pauses and doesn't get any inputs (this active session does)
if you need physical buttons presses then onKeyDown should work (inside Activity or eventually using AccessibilityService, which would work "globally" in whole system). if you need some on-screen notification buttons presses then just make custom layout for your notification with as much buttons as you like, even styled as a player
note that in Android 11 active MediaSessions notification is stickied to top of notification section when you drop down status bar. your custom notification will be somewhere below between all others (you can manipulate position a bit using priority param for notification/channel)
The question is: How to manage (for example stop, start) music in music players like Tidal or Spotify from my app.
For example when i click button in my app the music from tidal on my phone stops plaing.
Thanks! John
For loose control, target intents with ACTION_MEDIA_BUTTON directly at the broadcastreceiver of the app you want to stop. This allows commands which have an associated key event.
For tight control, use MediaSessionManager. This allows a maximum of control, but requires an active NotificationListener.
I've came across some radio app's that share a common, how can I say, way to implement their functionality, and (since I'm new on android dev) I'm really curious about it.
I'll use some images from the app "Simple Radio" to illustrate my doubt.
So, in what I call the main activity, you simply have a feed of radios from where you can choose one to play.
If no radio is playing/stopped on background, what you see when a radio is choosen is this activity, the one I call the streaming activity:
However, if one radio was playing/stopped on background, and you choose another one, what you'll see is this toolbar in the end of the feed:
So.. I know there's a background service for streaming the choosen radio, but how do they manage to control the radio both on the main and streaming activity? Is that possible because services (and it's current state) can be accessed from anywhere or something?
I know there's a background service for streaming the choosen radio, but how do they manage to control the radio both on the main and streaming activity? Is that possible because services (and it's current state) can be accessed from anywhere or something?
The background service is actually a background Service, an Android controller that is independent of activities.
This controller runs until it is told to stop, and has nothing to do what is visually on screen. The visual components can communicate with the Service to send instructions to it and vice versa.
All,
I have searched for an answer to this, but I'm not getting anything exact... It's my first time writing an Android app, so please be gentle :)
I'm pretty bummed about the minimal headset support in Android - unlike e.g. iPhone, it only natively seems to support a single button, so no volume control on headset compatibility. Additionally, if I'm listening to music and a call comes in, the OS pauses the music automatically, but the headset button still functions ONLY as a media button - I can't use it to answer/end the call. If I answer the call via the screen and press the headset button, the music starts again, but the call continues...
I'd like to create a 'middleman' app that can pick up that the headset button has been pressed (via Keyevent.KEYCODE_HEADSETHOOK) and can then determine whether to perform the default ACTION_MEDIA_BUTTON action (toggle play/pause in my chosen media player) or, if there is an incoming call, pause the music and answer the phone (and then, when pressed again, end the call and restart the media player). Perhaps even check for ACTION_MULTIPLE on the headset button to assign different options (ACTION_MEDIA_NEXT, ACTION_MEDIA_PREVIOUS etc.). Perhaps also be able to determine whether different buttons on the headset have been pressed (if the headset is e.g. a fancy iPhone headset) and 'translate' those button presses into the appropriate ACTION_MEDIA_*). This might not be possible if the OS can't tell the difference between different buttons, obviously.
Obviously such an app would have to receive the intent with a high enough priority that it would be able to abort the broadcast before the current media player gets it.
I've been tinkering with creating assorted BroadcastReceiver classes and intent filters etc., but part of the problem is that the bult-in Android emulator that comes with Eclipse doesn't seem to have the ability to simulate a user plugging in the headset and/or subsequently clicking the headset button. Therefore, every time I get somethign that looks promising, I have to put it onto my actual phone and try it out - time-consuming and a hassle.
3 questions then:
Am I missing somethign obvious - is this a real problem and if so, has it already been solved?
If it IS a problem, is it possible to write such a middleman app?
Are there any other Android emulators that can check for headset-related activities?
Thanks,
Rory
i´ve already written exactly this kind of app. Its called like the topic of this thead: Headset Button Controller ;-)
http://www.androidpit.com/en/android/market/apps/app/com.kober.headset/Headset-Button-Controller
Cheers Christoph