I have implemented GCM in 5 of my apps still I have a doubt about the running of GCM in background cause of apps behavior, may be am little confused about apps foreground and background running styles. I see my apps listed under "Downloaded" section of the Application in Settings when they get installed and registered the device id and I press the back key in my app.
They don't get listed under "Running" section. They come to "Running" section when there is a message (notification) and when the notification is generated and shown in notification bar they get cleared off from "Running". However if I click on "Downloaded" section, I see a "Force Stop" button activated (which I see for most of the apps) that means something is running.
My question is that is my app running and taking resource of cell phone while there are no activity open if I am using GCM in my app? Is there a service running in background if yes they why it is not listed with all other apps in "Running"?
Force Stopping an app doesn't mean that it was running before you force stopped it. It's just a way to let the user tell Android they don't want the app to be started again, until the user launches it again manually.
If you force stop an application, it won't be able to receive GCM messages until the user manually launches it again, because the GCM background service won't be able to launch it automatically.
This behavior was introduced in Android 3.1 with Launch Controls:
Launch controls on stopped applications
Starting from Android 3.1, the system's package manager keeps track of applications that are in a stopped state and provides a means of controlling their launch from background processes and other applications.
Note that an application's stopped state is not the same as an Activity's stopped state. The system manages those two stopped states separately.
The platform defines two new intent flags that let a sender specify whether the Intent should be allowed to activate components in stopped application.
FLAG_INCLUDE_STOPPED_PACKAGES — Include intent filters of stopped applications in the list of potential targets to resolve against.
FLAG_EXCLUDE_STOPPED_PACKAGES — Exclude intent filters of stopped applications from the list >of potential targets.
When neither or both of these flags is defined in an intent, the default behavior is to include filters of stopped applications in the list of potential targets.
Note that the system adds FLAG_EXCLUDE_STOPPED_PACKAGES to all broadcast intents. It does this to prevent broadcasts from background services from inadvertently or unnecessarily launching components of stoppped applications. A background service or application can override this behavior by adding the FLAG_INCLUDE_STOPPED_PACKAGES flag to broadcast intents that should be allowed to activate stopped applications.
Applications are in a stopped state when they are first installed but are not yet launched and when they are manually stopped by the user (in Manage Applications).
GCM has a process running in the background, but it's a process that serves all the applkication on the device, so installing additional apps that use GCM has no effect on the number of background processes running.
Its like asking if the Calling App or the Message app always keep running, waiting for a phone or an SMS. Well, there are Android Framework Components called BroadCastReceivers. The OS Broadcasts an Intent message whenever a call is received, message is received, Low Battrey is detected, An Alarm is Fired and even when an Notification is received.
Then we have various applications which are registered to receive some Broadcast messages that the OS fires. This is done in the apps Manifest (generally). So if your app is registered to receive a Broadcast message for GCM message, your app will receive it.
Just remove the broadcast receiver for GCM in your Manifest. Your app will no longer respond to a GCM. Next how does the app distinguish between multiple GCM receivers on a single Device?
I mean how to distinguish if the notification GCM is for app A or app B?
This has to do with the APP_ID with which you register with GCM. That can be mapped to your App's Package name. We provide package name when we register for GCM
Related
I hope that we cannot receive any messages ,when we force stop the default messenger app in our android device.I force stop default messenger app and sent message to that android device. I get message to that device.why this device receive message?
On Android 3.1+, a BroadcastReceiver will only work after its app was force-stopped if an explicit Intent is used to send it a broadcast. Here, by "explicit Intent", I mean one that contains the ComponentName of the receiver, in addition to possibly other data like an action string.
It is unclear what you mean by "the default messenger app" and "messages". If you mean SMS, I would expect that on Android 4.4+, if the user's default SMS client is force-stopped, it would still get SMS messages, as Android probably uses an explicit Intent to talk to it. However, on Android 4.3 and below, I would not expect a force-stopped SMS client to receive messages, as SMS_RECEIVED was just an ordinary ordered broadcast then.
This happens often because there is a service that is listening. The app uses the service to connect with Google Cloud Messaging and receive the messages. You'll need to disable the service. You can view Settings -> Apps, then swipe left to view All or Running and view the services.
Extending a bit further Steve's answer, this is probably an exemplary case that describes why programmers must control any Services in their applications. Many people just declare and run them, and then they forget about them. Services run in a different component than the foreground app, so if you 'close' your app but you don't stop the Service, it will be still running and that's probably what you're experiencing. However, many people tend to misunderstand this concept. This is a different component, but not a different thread nor a different process.
As per the official Android Developer Guide:
A service runs in the main thread of its hosting process—the service does not create its own thread and does not run in a separate process (unless you specify otherwise). This means that, if your service is going to do any CPU intensive work or blocking operations (such as MP3 playback or networking), you should create a new thread within the service to do that work. [...]
You don't specify what kind of message system uses your app, but if it is GCM (Google Cloud Messaging) or some alike system, it indeed uses a background Service to receive notifications from the central server and you're getting them because your foreground app is closed but your Service is still running.
To stop a Service, you'll need to call Context's stopService() method, as defined in the documentation prior to stopping your foreground application.
Well, there are lot of threads on this topic but all are before the release of android 3.1.
Now broadcast receivers will not work until user manually launches the application, i.e for broadcast receivers to work, the application should be in running state not stopped. There are certain questions in my mind right now, specially about BOOT_COMPLETED receiver.
Why would they still want to have BOOT_COMPLETED and won't let application use it? I mean there seem to be no point in having it. When system boots, apps are in stopped state and no app will receive this event if I'm not mistaking.
And on the developer page I read this:
"The platform defines two new intent flags that let a sender specify whether the Intent should be allowed to activate components in stopped application.
1:FLAG_INCLUDE_STOPPED_PACKAGES — Include intent filters of stopped applications in the list of potential targets to resolve against.
2:FLAG_EXCLUDE_STOPPED_PACKAGES — Exclude intent filters of stopped applications from the list of potential targets"
Can someone please explain the meaning of it. Can I still receive broadcasts when my app is in stopped state? And how can I register such receivers in manifest.xml ? I know these flags are added in the code but can I do similar in the manifest.xml?
Apps are in the stopped state if and only if they have never been manually launched by the user. It the user has launched the app at least once, the app can register for an receive BOOT_COMPLETE messages at startup.
I have used GCM to get push notifications, now if I Force stop the app from the settings on the Android device, will it be able to get push notifications?
I have read many posts that say in this case an app cannot receive notifications.
Is there any possibility to get notifications?
Once you force-stop your app from Settings, your code will not run until something manually runs one of your components (ie the user manually launches an activity).
Therefore after force-stopping your app from Settings, you will not receive GCM messages.
If you want to get notifications you have to manually restart your app.
This is by design since Android 3.1.
Apps that are in the stopped state do not receive broadcast Intents.
Stopped state is:
when the app is initially installed (before the user runs something in
the app) or
after a Force Stop.
You can find more about this here: http://developer.android.com/about/versions/android-3.1.html#launchcontrols
The app has a BroadcastReceiver that listens for a boot-complete event and starts a background service to send some data to my HTTP server.
My question is, if the app is never run by the user (only installed), will the BroadcastReceiver receive the boot event?
Starting with android 3.1 user has to launch the application once for it to receive the boot_complete broadcast..
Following is from the official javadoc:
Starting from Android 3.1, the system's package manager keeps track of
applications that are in a stopped state and provides a means of
controlling their launch from background processes and other
applications.
Note that an application's stopped state is not the same as an
Activity's stopped state. The system manages those two stopped states
separately.
The platform defines two new intent flags that let a sender specify
whether the Intent should be allowed to activate components in stopped
application.
FLAG_INCLUDE_STOPPED_PACKAGES — Include intent filters of stopped
applications in the list of potential targets to resolve against.
FLAG_EXCLUDE_STOPPED_PACKAGES — Exclude intent filters of stopped
applications from the list of potential targets. When neither or both
of these flags is defined in an intent, the default behavior is to
include filters of stopped applications in the list of potential
targets.
Note that the system adds FLAG_EXCLUDE_STOPPED_PACKAGES to all
broadcast intents. It does this to prevent broadcasts from background
services from inadvertently or unnecessarily launching components of
stoppped applications. A background service or application can
override this behavior by adding the FLAG_INCLUDE_STOPPED_PACKAGES
flag to broadcast intents that should be allowed to activate stopped
applications.
Applications are in a stopped state when they are first installed but
are not yet launched and when they are manually stopped by the user
(in Manage Applications).
javadoc link
Check out this blog for more detail
Yes, the Boot receiver is registered to listen to the boot so if you reboot your device it will fire, regardless of whether you started the app or not. Similarly, if you add NFC listeners to your manifest, then if someone swipes an NFC card the app will react. The Manifest is used by Android to react to whatever you've specified in it. It's not contingent on whether the app is running (or has ever run).
Excellent question though! :)
EDIT as per the other answers and the documentation. This is not true anymore. Sorry for the confusion.
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.