Develop Reference

How reliable are Broadcast Receivers across different brand phones?

I have manifest declared Broadcasts for android.intent.action.PHONE_STATE and android.intent.action.NEW_OUTGOING_CALL. I tested my app after I removed it from Recent apps screen. I tested it on two phones:
MOTO G4 Play(Nougat)- After I removed my app from Recent apps screen on this phone I was receiving broadcasts.
ASUS(Lollipop)- After I removed my app from Recent apps screen on this phone I was not receiving broadcasts.
One way after reading such questions on SO I got is that I can do it by starting a sticky service so what it will do is not terminate my process and I will continue to get broadcasts.
What should I do to ensure that I receive broadcasts on every phone without using a service ?
Edit-1:I register my broadcasts as follows in Manifest
`
<receiver android:name=".PhonecallReceiver">
<intent-filter>
<action android:name="android.intent.action.PHONE_STATE"
android:enabled="true"/>
</intent-filter>
<intent-filter>
<action android:name="android.intent.action.NEW_OUTGOING_CALL"
android:enabled="true"/>
</intent-filter>
</receiver>
`
#Override
public void onReceive(Context context, Intent intent) {
Log.e("onReceive ","Called"); //This is how I check whether broadcast was called or not
//... other code
}

Think of notification broad cast that can be used to generate notification for your app, so broadcast is pretty reliable.
You are using manifest declared broad cast so theoretically, you should be able to receive broadcast regardless of whether your app is in foreground or background ( similar behavior was expected in all phone since your app targets same API). But there has been cases where mobile devices has ignored/bug some of the contract as a result some expected behavior breaks. It is very likely that similar thing happened in your ASUS based test.
From the broadcast manager documentation ,
If you declare a broadcast receiver in your manifest, the system
launches your app (if the app is not already running) when the
broadcast is sent.
However there is exception .Android has some updates on this behavior recently to restrict some of this features.
Note: If your app targets API level 26 or higher, you cannot use the manifest to declare a receiver for implicit broadcasts (broadcasts that do not target your app specifically), except for a few implicit broadcasts that are exempted from that restriction. In most cases, you can use scheduled jobs instead.
So what I believe is you should be receiving all broadcasts as long as you target API level less than 26 regardless of your app being active or not. Moving forward to API 26 or greater, you will receive broadcast regardless only if it is explicit OR exempted broadcast as per above quote.
What you encountered is probably that device specific issue which was not supposed to happen. Try testing in few more devices to rule this out.
You may want to read this for more clarification.
p.s. try not using error logging for info/debug like Log.e("onReceive ","Called");

Mobilock app starts before BOOT_COMPLETED broadcast... How is it possible?

There is a kiosk app called Mobilock. This app starts way faster (Almost 5 seconds before) than my own app which starts with BOOT_COMPLETED broadcast.
My own app has the highest priority which is max value of integer. So this is not about the priority.
These guys have found a way to start their application 5 second sooner than BOOT_COMPLETED broadcast.
Has anyone got an idea about what they are doing?

Oh my god! I've luckily found it. :)
This Page Says : Apps must register their components with the system before they can run during Direct Boot mode or access device encrypted storage. Apps register with the system by marking components as encryption aware. To mark your component as encryption aware, set the android:directBootAware attribute to true in your manifest.
Encryption aware components can register to receive a ACTION_LOCKED_BOOT_COMPLETED broadcast message from the system when the device has been restarted. At this point device encrypted storage is available, and your component can execute tasks that need to be run during Direct Boot mode, such as triggering a scheduled alarm.
You just need to put
android:directBootAware="true"
So the code in manifest is;
<receiver
android:directBootAware="true" >
...
<intent-filter>
<action android:name="android.intent.action.LOCKED_BOOT_COMPLETED" />
</intent-filter>
</receiver>

Listen also to android.intent.action.QUICKBOOT_POWERON and android.intent.action.LOCKED_BOOT_COMPLETED.
It seems to be device-dependant, which broadcast is sent first.

Receivers not receiving intents after boot on Galaxy S5 (on battery only!)

I am trying to get a BOOT_COMPLETED receiver to work on a Galays S5 Neo device (running 5.1.1) to start a service right after the device is fully booted.
So in the manifest i defined
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
and also added a receiver for the BOOT_COMPLETED intent
<receiver android:name="com.xyzMyApp.BootCompleteReceiver" >
<intent-filter android:priority="999" >
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>
</receiver>
This works fine on nearly all devices no matter if used on battery or not. On the Galaxy S5 Neo this is only working when the device is connected to power on boot. If i use the device on battery and do a reboot, it can take up to 5 minutes until the intent is received.
I also tried to receive other broadcasts like android.net.wifi.RSSI_CHANGED or android.intent.action.USER_PRESENT or android.intent.action.TIME_TICK to maybe use them as a replacement for the boot completed event. The idea was that those events happen pretty often and so after a reboot it won't take very long until one of the receivers is triggered. Turns out that the behavior is the same, on battery it can take up to some minutes until ANY of the receivers receives ANY intent.
I also disabled all kinds of battery optimization for apps i found in the system settings but that did not solve the issue.
Thanks for every hint or idea.

Try to add QUICKBOOT_POWERON as some devices have issues in receiving BOOT_COMPLETED broadcast:
<receiver android:name="com.xyzMyApp.BootCompleteReceiver">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED"/>
<action android:name="android.intent.action.QUICKBOOT_POWERON" />
</intent-filter>
</receiver>
Also make sure your app is not installed on external storage(SD card) as suggested on this answer

Android shutdown/power off broadcast receiver not starting

I want to create a traffic widget, and store the used traffic at each device shutdown. The problem is that I can't get the shutdown receiver to trigger.
I used the following code:
IntentFilter actionShutdown = new IntentFilter("android.intent.action.ACTION_SHUTDOWN");
IntentFilter quickPOFF = new IntentFilter("android.intent.action.QUICKBOOT_POWEROFF");
TrafficDataUpdate trafficDataUpdate = new TrafficDataUpdate();
getContext().registerReceiver(trafficDataUpdate, actionShutdown);
getContext().registerReceiver(trafficDataUpdate, quickPOFF);
I also tried with the receiver declared in manifest, but no success:
<receiver android:name=".receivers.TrafficDataUpdate">
<intent-filter>
<action android:name="android.intent.action.ACTION_SHUTDOWN"/>
<action android:name="android.intent.action.QUICKBOOT_POWEROFF"/>
</intent-filter>
</receiver>
Do you have suggestions?
Can someone recommend me another way of counting the data traffic, without the shutdown receiver?

Use one IntentFilter, not two, teaching it to listen for both actions. Your second registerReceiver() is implicitly unregistering the first receiver.
Also note that this will only work so long as your process is still in memory. Usually, your process is not in memory, and it is in the user's best interests for your process to not be in memory. Please replace this implementation with one where the receiver is registered in the manifest, as is shown in the following StackOverflow threads:
Android ACTION_SHUTDOWN Broadcast not working
BroadcastReceiver's behaviour for ACTION_SHUTDOWN
handling phone shutdown event in android

Boot completed Broadcast receiver is not working for dynamic registration

I created a broadcast receiver and registered in in manifest using following approach it is working fine
static way registering broadcast receiver (working fine)
<receiver
android:name="DeviceRestartListener"
android:enabled="true"
android:exported="false" >
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
</category> -->
</intent-filter>
</receiver>
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
But when i tried to register the broadcast receiver programmatic (instead of static way) using following way it doesnt work
Programmetic registering (not working)
DeviceRestartListener dataBroadcastReceiver = new DeviceRestartListener();
IntentFilter filter = new IntentFilter();
filter.addAction(
"android.intent.action.BOOT_COMPLETED")
//registerReceiver(dataBroadcastReceiver, filter); //DOESNT WORK
registerReceiver(dataBroadcastReceiver, filter, "android.permission.RECEIVE_BOOT_COMPLETED", null); //DOESNT WORK
No compilation and run time error. But the receiver is not receiving broadcast after device restarts
Thanks

All the Broadcast receivers will not work even when they are statically declared in manifest or registered dynamically using Application context. for example Intent actions like
Intent.ACTION_SCREEN_OFF
and
Intent.ACTION_SCREEN_ON
have to be registered dynamically. These actions will not be fired when they are declared in manifest. some Intent actions like
Intent.ACTION_TIME_CHANGED;
Intent.ACTION_TIME_TICK;
Intent.ACTION_TIMEZONE_CHANGED;
will be fired when are registered dynamically through context whose window token is not null.(like Activity or Dialog).
similar to this, some of the Intent actions like
Intent.ACTION_BOOT_COMPLETED
will work only when they are registered statically using manifest

Register receiver in code
When we register a receiver in code, we must unregister it when the app gets destroy (actually, when the Activity or Service that register it, gets destroy).
Register receiver in manifest
When we declare it in the manifest, you make it available even if you app is not running.
When to use which method to register
Which method to use for registering your BroadcastReceiver depends on what your app does with the system event. I think there are basically two reasons why your app wants to know about system-wide events:
Your app offers some kind of service around these events
Your app wants to react graciously to state changes
Examples for the first category are apps that need to work as soon as the device is booted or that must start some kind of work whenever an app is installed. Battery Widget Pro or App2SD are good examples for these kinds of apps. For this type you must register the BroadcastReceiver in the Manifest file.
Examples for the second category are events that signal a change to circumstances your app might rely on. Say your app depends on an established Bluetooth connection. You have to react to a state change – but only when your app is active. In this case there is no need for a statically registered broadcast receiver. A dynamically registered one would be more reasonable.
There are also a few events that you are not even allowed to statically register for. An example for this is the Intent.ACTION_TIME_TICK event which is broadcast every minute. Which is a wise decision because a static receiver would unnecessarily drain the battery.