I am developing an Android app that will run as a service most of the time. The user would be able to control it via the status bar -- including the ability to stop the service altogether.
Even though I am able to make a custom view and put buttons on the Notifications area [see Figure 1], I would like to be able to put it above the "Android"/Service Provider's name. Much in the same way as the Music Player app does this [see Figure 2]. That way, even if the user clears their notifications, my app's control panel will remain active as long as the service is running.
What's the best way to do that, please?
Original Image Link
Your ROM has hidden the Ongoing header; both the Music player and the hardware control widget use the ONGOING_EVENT flag to remain where they are (someone correct me if I'm wrong). Confirm this by loading your app onto your patched phone - the documentation specifically names e.g. Music players (and other times your process is still going on in the background) as times when you should use this flag.
You might like to note that the same page recommends the FLAG_NO_CLEAR flag - if all you want is for it not to be cleared when the user clicks clear notifications (this is recommended for ongoing apps).
Related
I wonder if it is possible to build an application for Android that waits for incoming calls and only allows the ones that are in an internal white list to show and make sound.
I know this is what a normal call blocker would do and I know that it is possible..however what I really want is:
If a call arrives that is not in the white list, I don't want to reject it, I don't want the caller to know the call was rejected. I just want my app to be aware of it but make it invisible to the current phone app. I could mute the phone and the call wouldn't ring but the phone app would still popup in front of everything or at least on the status bar.
If a call arrives and it is in the white list then the app would do nothing..just allow the phone app to treat it.
I think I can do this by implementing my own dialer app, but would much prefer not having to do that and just use whatever the user already has.
Thank you
Carlos
At least for iOS, apps like Spotify, Hangouts, and Google Maps have a way of showing that they're still active when in the background (when you temporarily leave them to check a different app, etc.). This typically appears as a thicker status bar in iOS.
Other variants:
What is this bar called, and is this possible to implement for Android? I have a video chat app (in both Google Play and App Store) that uses TokBox (essentially WebRTC), and it renders this bar already for iOS when backgrounded, but not Android.
The consistent way to indicate an ongoing phone call in Android is using a notification. The Android phone app also uses a notification in this scenario:
To prevent the user from dismissing this notification, you can use the FLAG_ONGOING_EVENT or FLAG_NO_CLEAR - see https://developer.android.com/reference/android/app/Notification#FLAG_ONGOING_EVENT
On iOS, you might want to set a specific Audio Mode and Audio Category to get the right status bar look.
See https://developer.apple.com/documentation/audiotoolbox/audio_session_services/1618405-audio_session_modes
and https://developer.apple.com/documentation/audiotoolbox/audio_session_services/1618427-audio_session_categories
Further, the Background Audio capability is required - otherwise, your Apps audio session will be stopped after moving it to the background.
To achieve an even more consistent user experience, you might want to integrate the iOS CallKit or the Android ConnectionService, see
- https://developer.apple.com/documentation/callkit
- https://developer.android.com/reference/android/telecom/ConnectionService
It can be implemented in Android by using a notification and adding a flag FLAG_NO_CLEAR
This is a link where this is explained pretty clearly
I'm trying to figure out the right way to add Chromecast buttons (pause, play, etc) to an Android Notification. I've set up a custom notification that sends PendingIntents to a ChromecastService. That service is trying to interact with a class I built called ChromecastAdapter. The ChromecastAdapter implements MediaRouteAdapter and contains all the listeners and state that go along with casting. However, all this state is gone as soon as I exit the application. So, my ChromecastService doesn't end up having access to the Chromecast once my app is gone.
It seems to me that the only way to get this to work is refactor all the Chromecast state into a Service that implements MediaRouteAdapter. I really don't want to do this since I'm pretty happy with the way things are now.
Since these interactive Notifications are required by Google, I feel like there has to be a standard way of interacting with a cast from a Notification. Am I on the right track here? Do I have to place all my Chromecast interactions behind a Service?
What the behavior should be depends on the type of app and the requirements of the app. If your app is "gone" (in the sense that the Application instance is gone), then the question that you should ask yourself is whether you would want to keep a notification mechanism to stay around; there are apps that when they are killed, the receiver also gets closed and user is sent back to the home screen on the chromecast device, in which case there is no reason to keep a notification around.
On the other hand, there are apps that based on their requirements, you would want to let the cast device continue what it was doing (for example play the video) even if the mobile app is gone. In those cases, you may want to have a notification mechanism in place for "bringing up" the app. To achieve that, you need to maintain certain amount of information/state/objects in a service, enough to be able to establish a connection again and "join" the running app. In addition, your "service" needs to be aware of the status of the app on your receiver so if that app is killed (say, someone else starts casting a different app to the device), it can be notified and exit.
I am writing a metronome app, I have the sound running from a service which I would like to keep running when the user is outside the app (browsing etc) and hasn't made a conscious effort to press the stop button.
It seems I should be using startForeground() as it's not the kind of thing you want in the background without paying attention to, and I really don't want the service to be killed at any time. Ideally I wouldn't be showing the notification while the app is in focus though. I notice that the Google Play Music app works this way, it only shows the notification when outside the app. Is anyone able to tell me how they have done this, I would find it hard to believe they wouldn't be using startForeground() after reading all the documentation stating you should be using it for this sort of app?
On the other hand, is this really desired behavior? It seems good to me, but I noticed that pretty much every other app I use with a long running service (HTC's music app, Navigation, few others) shows the notification icon at all times, whether in the app or not. I am interested in what is considered correct behavior. Any help much appreciated, thanks.
Is anyone able to tell me how they have done this
They probably call stopForeground() when one of their activities returns to the foreground, and startForeground() when they think the user has left (e.g., onUserLeaveHint()).
I am interested in what is considered correct behavior.
I do not think there is a definitive "correct behavior" in this area. It is easier to do what the other apps do and leave the Notification around, until the user indicates that they no longer want the background work to run.
Note that while you may want "to keep running when the user is outside the app", the user might not. Certain types of apps (e.g., music players) can safely assume that the user wants the audio to keep going; a metronome, IMHO, does not rise to that level. Please allow the user to configure this behavior, such as through a SharedPreference.
For this question I'm going to quote another user who got no response to their question:
I've written an Andoid app that uses the hardware Volume buttons for another purpose.
It works fine if the app is running and visible, but when I turn the
screen off or let it time out, the button clicks don't get into my
handlers.
Does anyone know if there is a way to detect these button clicks when
the screen is off?
Source: AV695's question
I'm working on an app myself that makes use of the volume buttons, but as this user also noted, the normal behavior of checking buttons with onKeyPress stops working once the screen is off. This is because the Activity gets paused on screen off.
Is there a way to keep the activity running while the screen is off, or check for the usage of the volume buttons when the screen is off? I tried using a Service for this before but it's impossible to check for the volume keys like that as noted by Commonsware.
I doubt that this is supported (without resorting to a battery-draining wakelock) at either the platform, kernel, or underlying radio firmware levels without modifications to the last to bring volume presses during sleep to the attention of the kernel.
Within the realm of reasonable system-ROM modifications, a more reasonable one might be to modify an existing open source ROM for the device to insert some custom platform level code into the handling of the power button usually used to wake up the device preparatory to unlocking it - that at least we know does get the attention of the kernel. That code could then inform the user by sound or vibration if there are unacknowledged notifications.
You could optionally wait briefly, check device orientation, or look for another key press to avoid doing this in an annoying way when the user is holding the device outside their pocket and trying to unlock it.
Or you could not use the volume key and just set a timer to wake up every 15 minutes and vibrate if there are unacknowledged notifications, avoiding the need to fumble in ones pockets.
You mention it's a custom request: if implies it's one off or low-volume, another option to consider would be that a few vendors have "bluetooth watches" out with an SDK that lets you push notifications from an android device.
If you can capture the notification when it's generated, you could push it to the user's wrist, and then let the phone go back to sleep.
You cannot intercept the key while your application is in background, but instead of listening to the KeyPress itself. You can register a ContentObserver, as described in this question.
As Chris Stratton mentioned, the only way to keep your App alive is by using battery-draining wake locks.
However, since I found myself in the same situation, I came up with another solution. Unfortunately, you'll need a rooted device as well as the Xposed framework.
With Xposed, which replaces the zygot process so you can hook yourself into any constructor and method of the system, you will be able to catch the raw KeyEvents before the system handles them.
This is done in PhoneWindowManager.interceptKeyBeforeQueueing(). By using a XC_MethodHook, you can use beforeHookedMethod() on the afore mentioned method to catch every hardware button event, even if the device is in deep sleep.
After catching events you are interested in, you can create a temporary wake lock to do your things but don't forget to release the wake lock after you finished your work.
A good example of how to accomplish this is the Xposed Torch Module.
If you, however, rely on a non rooted system, the bad news is that it's simply not possible without draining the battery...
I was also trying to implement volume button press detection in my app and I left that part to be developed later once the core part is done. I was able to detect volume key press while screen is on even when phone is locked, from a background service.
Background Video Recorder 2 (BVR2) (and possible BVR1 also, I did not try) is one of the apps that can detect volume key press even when screen is off. While trying to implement volume key detection while screen is off in my app, I installed BVR2, hoping to find how it works. To my surprise it gave my app the ablity to detect volume keys even when screen is off. My app had a ContentObserver to monitor volume changes, but was not working when screen is off. When BVR2 is active my app also could detect volume key press when screen is off. Still digging.
But BVR2 has its own trigger action, that is to record video, an action you may not want to occur just for the sake of you application detecting volume key presses.
Another app is QuickClick. This app can give your app what it lacks, the power to detect volume key presses even when screen is off, without extra unwanted actions. Just install QuickClick and do not configure any action. Create a ContentObserver to monitor for stream volume changes and you are ready. You app will now be able to detect volume key presses even when screen is off.
Please note that my app runs as a background service.
Both of the apps mentioned above are meant for other uses, but uses volume key detection to perform action. I am in no way connected to any of the apps mentioned.
If these apps, and possibly dozens others, can detect volume key press, it can be done. I request experts to find out how to do it, so that we can implement in our app without relying on another app.
If you find this answer useful, please up-vote.
I am not sure if it is as simple as this but check this android blog:
Allowing applications to play nice(r) with each other: Handling remote control buttons
It explains the usage of a broadcast receiver that receives the up/down volume controls and other music controls.
In summary you should use registerMediaButtonEventReceiver