I understoo from docs that
As of Android 3.1 the Android system will by default exclude all
BroadcastReceiver from receiving Intents if the corresponding
application has never been started by the user or if the user
explicitly stopped the application via the Android menu (in Manage
Application).
Thus, I wonder how could I send send Broadcast to Receiver if my app have not been started yet.
Thus, I wonder how could I send send Broadcast to Receiver if my app have not been started yet.
I am going to take you literally, meaning that you want to send a broadcast Intent to some BroadcastReceiver that you wrote.
If the sender and the BroadcastReceiver are in the same app, there is no problem: if the sender is capable of running, it is capable of sending the broadcast. That's because the user will have had to do something to run the sender, such as starting an activity.
If the sender and the BroadcastReceiver are in different apps, my understanding is that the sender can include FLAG_INCLUDE_STOPPED_PACKAGES on the Intent and that will make sure that the BroadcastReceiver in the other app can receive the broadcast.
Related
I'm having a problem about android BroadcastReceiver. It's the first time for asking questions on stack overflow, and my English is bad. So I describe the question in Chinese again in the end!
I want my app can automatic run when the android system starts.First I register a BroadcasetReceiver which can receive the BOOT_COMPLETED message in the static way (in the AndroidManifest.xml).This BroadcastReceiver works well. The BroadcastReceiver needs to start a service, the service is running all the time, and it registers another BroadcastReceiver which can receive the CONNECTIVITY_ACTION message in the dynamic way.But when the networks changes, the app can't receive the CONNECTIVITY_ACTION message in the HUAWEI pad only when the app starts the main Activity.(It can works well in the HUAWEI phone).
note：The BroadcastReceiver which receives the CONNECTIVITY_ACTION message must be register in the dynamic way. Because the app need to unregister it sometimes.
(写了一个开机自动启动的程序，开机启动一个service，这个service一启动就动态的注册一个监听网络变化的broadcastreceiver，可是在华为的pad上，这个broadcastreceiver始终不能接收到网络状态变化的广播消息，除非启动主Activity，但是华为手机没有这个问题！)
1、Your phone's Android version maybe not same to your pad's;
2、I suggest you register broadcast in static way;
3、Are you sure this service started after reboot? you can write a log .
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.
I'm using C2DM the first time and I'm looking for a general advice how I can achieve the following:
Upon receiving a C2DM messages I decide:
- if the application is upon the current activity will display an "alert popup".
- if the application is not open I'd like to send a message to the notification bar (similar to new emails, sms, twitter etc.)
We have a GlobalBroadcastReceiver extends BroadcastReceiver which implements public void onReceive(Context context, Intent intent). This is the only receiver registered in AndroidManifest.xml.
So basically all our broadcasts are piped through this receiver and the first scenario is no problem.
However I'm, wondering how to tackle the second problem. How can I make sure I receive a C2DM.RECEIVE broadcast even when my application is closed and then: how can I notify the user about the incoming data?
I'm super confident there are already a lot of solutions out there but since I couldn't find them I think I'm just missing something of the bigger picture.
How can I make sure I receive a C2DM.RECEIVE broadcast even when my application is closed
Have your receiver registered in the manifest, per the C2DM documentation.
then: how can I notify the user about the incoming data?
Raise a Notification.
Since your receiver will not necessarily know if there is an activity of yours in the foreground, the best solution is to send your own broadcast Intent, but one that is ordered. Have the activity register a high-priority BroadcastReceiver for your own broadcast, and have another manifest-registered BroadcastReceiver implement a normal-priority BroadcastReceiver for your own broadcast. If the activity gets the broadcast, it displays your popup (ick) and aborts the broadcast. If your "backstop" BroadcastReceiver gets the broadcast, it displays a Notification. Here is a blog post with a bit more detail on this pattern, and here is a sample project demonstrating this use of ordered broadcasts.
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.
I have an application with a broadcast receiver, and I'm trying to figure out how to receive the broadcast of when an app from the Market is purchased and/or installed. Is this possible?
I've tried setting a receiver for android.Intent.ACTION_PACKAGE_ADDED and com.android.vending.billing.PURCHASE_STATE etc.
There isn't a way of receiving a broadcast intent on purchase/install of the application. From what I recall reading about this in the past, is that it's a security concern.
From the API, it even states that a new application won't receive the ACTION_PACKAGE_ADDED broadcast intent. PURCHASE_STATE is also irrelevant since the app isn't installed yet at purchase time.