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.
Related
I have an Android Service running in Foreground mode.
This service is running using the sharedUserId="android.uid.system" and all is good...this runs fine.
I also have several other user space applications that I want to send custom broadcasts to. These other applications register their own "broadcast action" with my Service that they wish to receive back in their own BrodcastReceivers when something happens. My Android system Service doesn't know these broadcast actions yet, the applications choose these themselves.
My problem is, whenever this Service sends a message, I get something like:
Sending non-protected broadcast CUSTOMER_CHAT_MESSAGE from system
How can my service "sendBroadcast()" and indicate that I know the CUSTOMER_CHAT_MESSAGE is Unprotected, and that I don't care!
I've read all the "fixes" here, which are some variation on adding:
<protected-broadcast android:name="CUSTOMER_CHAT_MESSAGE" />
I've also read some docs explaining why protected broadcasts are implemented...this feature blocks other user apps from sending messages that spoof a system broadcast. The "protected-broadcast" flag in the client app specifies that it should only trust real system broadcasts.
How can I tell the system, either on the sending side (in my Service's 'sendBroadcast()') or on the receiving side (the non-system applications) that I don't care about the security and the source of the message doesn't matter!
I'm looking for a way to have a Service running with "android.uid.system" send broadcasts that are not protected.
I am trying to implement an Android chat application using web-socket.
I am using an Android service to connect to the web socket server. It is working fine, but when I force stop the service (Not the application) manually in task manager
(Settings -> Apps -> Running)
Then my application is not receiving any messages from server. What I observe from other chat applications is even if I stop the background services of those applications, they are receiving messages and after some time the services also automatically started. How is it possible? Is there any other hidden service that wakes up the main application thread?
You can force start the service every time it is force stopped
Take a look at this (How to automatically restart a service even if user force close it?)
Most of those apps are using a push service such as Google Cloud Messaging.
Continually polling servers or maintaining a persistent web socket is not a resource-friendly method of receiving messages from a server over an extended period of time.
To my knowledge, they do not have a special way of doing this. They may have "work arounds" that are convenient (for example, Facebook Messenger can wake the FB app, if you have both installed and stop only 1 of them).
As of Android 3.1, an app cannot wake itself and GCM also will not wake it. See here: GCM push notifications on android 3.1 : disable broadcast receiver
CommonsWare usually knows what he's talking about. Also, I have tested it and it doesn't work for me on the 3.1+ APIs.
I have an intent service which is continously polling to check if data has been modified in the server. The problem is if the app remains idle for some time , it stops receiving notification. We are suspecting the service has been killed by android.
I think even GCMINTENTSERVICE is also killed by android in some time.
My question is how come gmail / what's app/yahoo mail always sync without foreground notification. Which sync mechanism they are using.
Are you aware of any other app which is always receiving notification even when in background, so that I can check in Google why it is not killed in some time.
Does Google kill gcmintentservice if it has been running for some time in the backgroud.
EDIT: GCMBASEINTENTSERVICE is the service we are planning to implement for push notifications, because with the older polling service the app did not receive notification after some time. This is may be because it was getting killed by android in some time. So with push notifications, the app will always receive notification? Isn't Gcmbaseintentservice an intent service and that will also be killed by android in some time.
Android will kill services after some time, to resolve memory issues. It's not a good thing to always run your application in background, since it will consume memory and processing power.
You have got the wrong idea. GMail and Yahoo are not polling for new mail, they are using Push Notification mechanism, more precisely Google Cloud Messaging or GCM. Push Notifications can be received in the background, and once they receive a push notification, they sync the app.
BBM (BlackBerry messenger) didn't use GCM, as they relied on BlackBerry servers. So they ran the application in the background without getting killed. This is done by always showing non swipeable notification. Someway with notification, you could run a service in background without getting it killed.
According to AndroidHeadlines
You may want to leave it persistent if you want to use BBM. In Android
4.3, Google has begun fighting apps that suck down battery and stay alive without you knowing. It now requires any app that wants to run
in the background to place a persistent icon in your notification.
Hence the BBM icon. Doing this allows that particular app to never be
closed.
Surely google will kill any service if the device runs out of memory or new services are running in background.
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 a requirement that my app, can receive events (e.g. messages) from server any time (even if app is not running). So do I need to create an infinitely running service to listen for these events?
This to me seems similar to Email apps in Smartphones, like whenever you receive a new email(event in my case), its able to show notifications and also able to update my list adapter whenever I receive an event.
But I dun know how will I implement this?
You should take a look at C2DM (push-messages):
http://code.google.com/intl/sv-SE/android/c2dm/index.html#intro
it allows a server to send messages to devices at any time.
From the link:
Here are the primary characteristics of Android Cloud to Device
Messaging (C2DM):
It allows third-party application servers to send lightweight messages to their Android applications. The messaging service is not
designed for sending a lot of user content via the messages. Rather,
it should be used to tell the application that there is new data on
the server, so that the application can fetch it.
[...]
An application on an Android device doesn’t need to be running to
receive messages. The system will wake up the application via Intent
broadcast when the the message arrives, as long as the application is
set up with the proper broadcast receiver and permissions.
[...]
Events from server are called "push notifications" and are implemented via "Cloud 2 device messaging" (C2DM). On the mobile side these messages are submitted as broadcast events (see BroadcastReceiver). For a complete example see some tutorials: Google, Vogella or here on Stackoverflow
I think you have to start a Service as soon as the device booted. There is a good tutorial here how to achieve this.