Develop Reference

Android O : PHONE_STATE broadcast limitation

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.

Broadcast receiver not working when app is cleared from RAM

I am new to android. I am making an alarm clock. Its working perfectly until the user clears the app from the RAM. On searching, I found that broadcast receivers don't work if the app is cleared from the RAM. So, what exactly should I do? Will sending the broadcast from a service help? Also if you have a link to a good tutorial to Services in android, pls do share. Also let me know if there is some other way to solve my problem.

In Xiaomi devices, you just have to add your app to Autostart list, to do so, follow these simple steps given below:
Open Security app on your phone.
Tap on Permissions, it'll show you two options: Autostart and
Permissions
Tap on Autostart, it'll show you list of apps with on or off toggle
buttons.
Turn on toggle of your app, you're done!

You can register broadcast receivers either inside the activity at runtime or in the manifest. You want to adopt the latter approach

In the past I have similar problems with AlarmManager, AlarmReceivers and this kind of things. There are some tips that can help you in your code:
Make sure that you are scheduling your alarm correctly.
Make sure that you are setting the propers permissions on the manifest.
Take care if the device is locked or it was rebooted.
There is a quite useful tutorial that helps me to control and make a "Hello World!" example with AlarmManager: AlarmManager Repeating Example
Note: In API 19 and higher, the method setRepeating is not exactly (maybe the alarm triggers at 10:00 or at 10:15), so you must use setExact.
Hope it helps!

You can register broadcast receiver in two ways
1. From your activity.
2. From your manifest.
if you registered broadcast throught activity, It wont receive after your activity is destroyed, So thats is where we register BroadcastReceiver in manifest.
This link will help you BroadcastReceiver

What happens to BroadcastReceiver when application is updated?

I am setting an alarm (launched every 10 minutes) using AlarmManager together with BroadcastReceiver in my application.
What exactly happens when the application is updated (either by updating through Google Play or by installing application with higher version code directly through ADB), will the receiver still work? Can I trigger some actions related to BroadcastReceiver when the application is updated?

You can register a receiver for the action ACTION_PACKAGE_REPLACED to be notified when your app is updated.
But, in your particular use case : you probably setup the alarm when your app starts. After an application update: your app starts again and so the alarm will be setup correctly.

You use AlarmManager to create alarms.
What makes you use BroadcastReceiver to create an alarm?
Is it that you have 2 applications and you are using BroadcastReceiver from app1 to launch the alarm[manager] from app2 ?
Otherwise, I believe your approach is wrong and BroadcastReceiver is renundant.
UPDATE
On the basis of your updated question, the crux of the question seems to be :
Will the BroadcastReceiver work if the applivcation is updated?
As long as you have the correct BroadcastReciever code in the updated verion of your app, it will.
Can I trigger some actions related to BroadcastReceiver when the application is updated?
You want to change your BroadcastReceiver/ remove your BroadCastreceiver -- you can.
Want some specific code to trigger on application being updated: use ACTION_PACKAGE_REPLACED as ben75 suggested

Wake an application after market update

I would like my app to wake up after it has been updated using the market (play store).
How can I accomplish that?
By waking up, I mean the Application.onCreate() to be executed.

As Commonsware mentions, the ACTION_PACKAGE_REPLACED does the trick. You just need to compare your package name with the data for the intent, otherwise you catch all packages being replaced.
In newer API's (12 on up) there is the ACTION_MY_PACKAGE_REPLACED which is only sent to the application that was replaced.

In principle, having a manifest-registered receiver for ACTION_PACKAGE_REPLACED should have this effect. Android should have to terminate your process to do the update, causing a fresh process to be created to deliver this broadcast to you.
That being said, I haven't tried this.

Executing code when Application is updated/reinstalled

I have Some Alarms set via AlarmManager to do some periodic jobs.
I set/reset them when user opens the app for the first time & on every boot_complete event.
But when the app is reinstalled via ADB then my alarms do not fire anymore. looks like the OS deletes the Alarms on reinstall of the app. I assume this will happen if the user updates the app from the market also.
If I can receive a broadcast or some sort of callback in the event of reinstall/upgrade etc of my application, I can set the alarms again. but i don't know if it is possible or how?
Can someone please help me out.

Yes, this is possible.
You can create a broadcast receiver that listens for any PACKAGE_* events the system sends, but you won't receive them for your own application except for when your application is being upgraded — you'll get PACKAGE_REMOVED followed soon after by PACKAGE_REPLACED.