Android O : PHONE_STATE broadcast limitation
Asked Answered
E

6

35

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

Eustace answered 16/8, 2017 at 14:54 Comment(0)
E
2

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.

Eustace answered 28/8, 2017 at 9:14 Comment(0)
D
4

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.

Deitz answered 14/6, 2018 at 19:31 Comment(0)
C
3

You have only one solution, use a foreground service and register the broadcast receiver in the service.

Containment answered 18/8, 2017 at 5:52 Comment(4)
We expect something better because foreground service requires a notification to be shown. Don't you think that would be a spam to the user? And running a service 24/7 consumes lots of resources.Mortality
There's no other solution.Containment
+1 I'd just like to add - the notification isn't so bad. For instance, LastPass password manager shows it 24/7 for its background service and it consumes very little resources. Also, FB messenger will show the notification if there is a "face" on the screen.Butyrate
What do you think about scheduling a job using JobScheduler to trigger for every new call log entry in its database?Mortality
E
2

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.

Eustace answered 28/8, 2017 at 9:14 Comment(0)
A
0

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.

Alcorn answered 4/9, 2017 at 10:40 Comment(3)
Do you know that starting from nov 2019 you won't be able to make an update targeting lower than android 8 developer.android.com/distribute/best-practices/develop/…Decanal
@JenyaKirmiza yes, we're already targeting api level 26 for a while now, fortunately, google came to their senses and whitelisted the android.intent.action.PHONE_STATE intent action, so it's now easy again to listen on incoming call eventsAlcorn
android.intent.action.PHONE_STATE broadcast not being called when the app is closed. any solutions.Stephenstephenie
H
0

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.

Hydrate answered 25/9, 2017 at 21:43 Comment(0)
Z
0

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.

Zoan answered 21/11, 2017 at 14:9 Comment(1)
Is it whitelisted?Sension

© 2022 - 2024 — McMap. All rights reserved.