Does a running app need to poll for listening to event broadcast? If not, what is the approach used?
No, there is a 'push' approach used - app register receiver either during installation (if BroadcastReceiver is registered in Manifest), or when app is started.
Then, when broadcat is raised, Android matches IntentFilters for all registered receivers and deliver Intent to that BroadcastReceiver.
Related
I have a network change receiver class and it extends from broadcast Receiver, but I’m not pretty sure that it’s working in android Oreo, does Oreo support broadcast receiver, and if it doesn’t support, what’s the other way to do it
Oreo supports Broadcast Receivers but with some restrictions on Implicit broadcast that are declared in manifest.
Implicit vs Explicit Broadcast:
According to the documentation, an implicit broadcast is a broadcast that does not target that app specifically. For example, ACTION_PACKAGE_REPLACED is an implicit broadcast, since it is sent to all registered listeners, letting them know that some package on the device was replaced.
However, ACTION_MY_PACKAGE_REPLACED is not an implicit broadcast, since it is sent only to the app whose package was replaced, no matter how many other apps have registered listeners for that broadcast.
So any broadcast receivers that we have defined statically within our application manifest that are listening for implicit broadcasts will no longer receive those broadcasts.
The reason for this change is that implicit broadcasts would previously trigger any component that was listening for them within the manifest— this could have an adverse effect on application and device performance due to large numbers of applications registered to receive specific broadcasts all being triggered at the same time.
But there is a list of exceptions when it comes to implicit broadcasts — this means that there are still some which you can register to receive broadcasts for. They are all listed below:
So if the broadcast that you have registered receivers for is on this list, then it will still function as it did previously. However, if the broadcast that you have registered to receive is not on this list then you should use some alternative solution like:
Create the receiver at runtime by calling Context.registerReceiver(),
instead of declaring the receiver in the manifest.
Use a scheduled job to check for the condition that would have
triggered the implicit broadcast.
For more information
It's not supported in Oreo as manifest tag, you must have to register it at an Service/ Activity with context.registerReceiver(). Or you use the WorkManager to schedule something for specific network conditions.
I have a Broadcast Receiver that listens to app installation events.
What happens if multiple apps are being installed at the same time?
Will I get multiple calls or
Android might 'swallow' some of the calls and call me only once ?
Each installation should send one braodcast intent. The answer in here can help you. As said in there:
"If the BroadcastReceiver is registered in the manifest, a new
instance is created for each broadcast(...)"
I'm currently working on a project where I analyze the SMS_RECEIVED-Flow.
According to the article [1] I simulated the SMS_RECEIVED-Broadcast with an explicit call to the service: com.android.mms.transaction.SmsReceiverService.
The problem is, that the Android-Emulator and my Nexus do forward
the generated BroadcastReceiver to the default SMS-App only and I do not know why.
I tried to catch the Broadcast with an statically registered receiver in another App and with an dynamically registered receiver (all receiver registered with the highest priority and the correct intent-filter). Both methods work fine with a normal SMS, but not with my simulated one.
So the question is, does anybody know how the SMS-Receive mechanism work and why my program won't receive any broadcasts.
[1] http://blog.dev001.net/post/14085892020/android-generate-incoming-sms-from-within-your-app
SmsRecieverService is part of default messaging app, so if you explicitly call this service, the broadcast will reach only that app. Since the SMS_RECIEVED broadcast is a protected broadcast , your app cannot broadcast it.
One way is to change the name of the broadcast in both simulator and your app.
How do I make a broadcast receiver which runs always, from the very start of the device? Is this possible without starting the application where it is declared?
If not I guess I would have to start my application when the device starts. But this probably adds to much overhead and it's unwanted.
I want this always runnning broadcast receiver in order to listen always for c2dm notifications. These should notify the user that there are new messages in the application.
If you add the BroadcastReceiver to your Manifest with an Intent Filter to listen for a specific intent, the Receiver will be active upon install.
what do you mean "run always" ?
if you need something to be alive for a long time , and from the OS bootup , you need to :
let the app to be installed only on the internal storage (otherwise it won't work).
set the broadcast receiver to listen to the boot intent .
upon receiving the boot intent, start a service and there listen to the intent you wish to listen to.
I want to know the difference between services and broadcast receivers, can anyone point out an example that can be observed on android mobile devices.
Thanks
Service: If you want to do something in background , this will be running always in background even if the application closed. You can create this in separate process and also you can give your service to other app if you want. Downloading any content or Music is good example
Broadcast Reciever: Usually system will send some info which can be recieved by your app if you would wish to ,by registering. And you can do something what you want when that thing happens by using onReceive method.
Example is the system will send BroadcastReceiver when new sms arrives or Booting done
Here is good article : Service and BroadcastReceiver
Service is used when you want to do something in background, any long running process can be done using Service in Background. For example, you want to play music when your application gets close. In that case service will be running in background with music.
Example of Service
BroadcastReceiver is used when you want to fire some stuff or code during some event. For example, event can be on Boot of Device. If you want to perform something when device Boots, date and time changed etc...
Example of BroadcastReceiver
I think of it possibly a different way. A Service receives intents that were sent specifically to your application, just like an Activity. A Broadcast Receiver receives intents that were broadcast system-wide to all apps installed on the device.
(The reason I say a Service is a bit like an Activity is that: You wouldn't broadcast a message saying "start Activity MyActivity" across all apps installed on the device. It is only for your specific app.)
Of course, as others mentioned, a Service can continue running in the background, whereas a Broadcast Receiver should finish quickly (e.g. if it is running for more than 5 seconds it may be killed by the OS). The Broadcast Receiver can still run in the background (when app is closed) under certain circumstances. For this, it's worth mentioning that there are actually two types of Broadcast Receivers - Manifest-declared, and Context-registered. They have different lifespans and restrictions - the former can receive broadcasts in the background with certain restrictions, while the latter cannot receive broadcasts in the background (app must be running and active) but has no restrictions on the types of intents that can be received.
Both services and broadcast receivers must be specifically invoked (via an intent), but for services this is usually a specific call (e.g. when your app is started or when the user clicks some button) whereas for broadcast receivers they don't need to be explicitly started as they will start anyway when a relevant broadcast is made.
Here's how I would think of it:
Type
Displays UI?
Can continue running for a long time when app is closed?
Can receive intents when app is closed?
Intents must specifically target your app?
Restricted list of intents that can be specified?
Activity
Yes
No
Yes
Yes
No
Service
No
Yes
Yes
Yes
No
Manifest-declared Broadcast Receiver
No
No
Yes
No
Yes1
Context-registered Broadcast Receiver
No
No
No
No
No
1: Only if you target Android 8.0 or above. The restrictions are not applied if the intent specifically targets your app. The restricted list of intents can be found here.