I am creating a native social app which includes features such as Direct Messages, Voice and Video Calls etc and I have been trying to find a way to be able to receive data payloads from Firebase Cloud Messaging containing values such that I create a custom notification based on the type values from the data payload eg for VOIP calls I’d like to set a remoteInput action to see if a person declines or accepts a call or for direct messages add a remoteInput action for a quick reply and so far I haven’t had any luck especially with background services not being allowed anymore ever since the release of Android 8.1. So I would like to know if there’s a workaround I’ve been missing or if it’s even possible and if it is how do these popular apps do it. Thank you in advance.
Its same as your mentioned, once after the release of 8.1 apps are now more strict in regarding the background running process. There are actually two insights I had received while developed some projects. 1) More the app is used by the user, the app is sort of whitelisted and can receive more notifications, i.e., the system actually tracks the frequency of app usage. 2) You have the possibility to ignore your app from battery optimization process hence more chance of background process to run.
I have been trying to do something similar to truecaller app, where my app is supposed to show a screen after a call gets hung up. Was achieving this by registering android.intent.action.PHONE_STATE implicit broadcast in the manifest file.
But it is not working if I change the app to target Android O, because of the Android O broadcast limitation, and I'm trying to figure out an alternative solution to this use case.
Alternative solutions suggested in android docs: Job scheduler or register a service with context.
Job scheduler: Because of the Job scheduler optimizations there will be some delay to receive the callback. So it will affect the user experience if our app screen is shown a few min after the phone call and polling to check for new call logs every few seconds causes battery drain issue.
Register service with context in Java: I want the behavior to work even if the app is not active or alive. This will not work if the system kills the Service.
Register a Foreground Service: This requires a notification to be shown to the user all the time, which would be spam the user, and running a service 24/7 consumes lots of resources which defeats the whole purpose of broadcast limitation.
Please suggest an alternate solution so that the user experience remains the same.
Thanks in advance
Eventually, the action was added to the "Implicit Broadcast Exceptions" list so you can add ACTION_PHONE_STATE_CHANGED to your manifest and it will work:
https://developer.android.com/guide/components/broadcast-exceptions
ACTION_CARRIER_CONFIG_CHANGED,
TelephonyIntents.ACTION_*_SUBSCRIPTION_CHANGED,
"TelephonyIntents.SECRET_CODE_ACTION", ACTION_PHONE_STATE_CHANGED,
ACTION_PHONE_ACCOUNT_REGISTERED, ACTION_PHONE_ACCOUNT_UNREGISTERED
OEM
telephony apps may need to receive these broadcasts.
You have only one solution, use a foreground service and register the broadcast receiver in the service.
As there is NO proper solution to read the PHONE_STATE from Android O. The best alternative we can go for is to trigger a job on new call log entry from the content provider. By this, the behaviour is maintained of showing a screen(with a few sec of delay) after the call ends.
NOTE : The disadvantage is we cannot get the state of the phone call(Ringing or off_the_hook etc.,). The call back will only be received after the new call log has been added to the System DB.
For me, and my production app, the solution would be to avoid targeting api 25 and above, until a better workaround/api comes up.
If your app targets level 24 or below, you're not affected by the new Implicit Broadcast Limitations and your app can still listen to PHONE_STATE broadcasts even when your app is not running.
An app targeting lower APIs can still be downloaded and installed normally on new Android versions, the only reason to update your sdkTarget value is if your app requires usage of new APIs.
There seems to be an broadcast exception for ACTION_NEW_OUTGOING_CALL but not one for incoming call (or when call ends). It seems like a bug to have one for outgoing but not one for incoming. There's been a bug report filed in google issue tracker. Hopefully their answer will clarify what we should be doing.
I'll update this answer if/when the bug tracker gets updated.
As mentioned here: https://issuetracker.google.com/37273064#comment4, ACTION_PHONE_STATE_CHANGED (android.intent.action.PHONE_STATE) will be whitelisted for the Android O release. Though they may be replaced with a different mechanism in a future release.
My goal is to detect when music starts playing on the device. In my case I want to launch volume controls on an Android Wear device but that's irrelevant for the question.
I know there is AudioManager.isMusicActive() but it requires polling. I would rather listen for a broadcast without keeping a service alive indefinitely.
The other alternative would be to listen for headphones being plugged in but apparently Intent.ACTION_HEADSET_PLUG is only delivered to dynamic receivers as this answer suggests.
I'm a bit clueless here. How can I listen for any audio related events without constant polling?
I have this use-case for Android Beam. I could have tested it myself but my app is not available in Google Play yet.
Here it goes:
I want to beam some content from my phone and the receiver phone does not have it. So with AAR, the app will be fetched from Google Play on the receiver phone. So far so good. So I download and login.
My question is: Once the app is downloaded will the receiver app still have the information that was beamed or should the sender initiate Beam again? Will my data in first Beam be lost? How should this be handled?
Theoretically, the onResume should be called to handle the intent.
Any thought if someone has come across such a kind of case.
The data will be lost, unfortunately. Think of it as if the NDEF message with the AAR will have been delivered to the Play Store app. (The Play Store app will not be able to deliver it to your newly installed app.)
The only solution is to Beam again.
I’m playing around with Google Play Game Services and multiplayer support. If I invite a player with this service, is it possible to send a notification to the receiver automatically? When I use the demo project nothing like this occurs. The documentation however says:
If the signed-in player accepts an invitation from the notification area on the Android status bar, your app should accept the invitation and go directly to the game screen (skipping the main menu).
This doesn’t explicit says that notifications are supported, but it gives my some hope at least :-). According to this question: Google play game services invitations get lost notifications seems to be supported, but I have never received any.
notifications are supported and will be sent to the receiving player... if the players are not in each other's circles sometimes the notification does not get displayed, depending on the receiver's settings. maybe that is why you haven't received any?
Ok, I finally solved much thanks to #smiller.
First of all I had my test account circled just as Following. This is not enough! Some other circle (Friend, Familiy etc) has to be used. If the person is just in the following circle, onRoomCreated is called with status code 6 (STATUS_NETWORK_ERROR_OPERATION_FAILED) on the inviter's application.
A secondary problem I had was that data synchronizing was turned off on my device. Obviously this has to be turn on. Unfortunately the inviter never get some feedback on this, it just waits forever.