I'm guessing this is a really rookie question, so I'm hoping someone can steer me in the right direction quickly & easily.
I have an app that receives GCM messages. The code that contains the GcmListenerService-derived class is located within my app. Because of this, the user MUST run my app after starting their phone in order for my listener to start listening (verified by restarting my phone, sending a test from Postman, and NOT getting the message / notification until I launch my app).
Do I need to create some type of service or something that will allow my app to get new GCM messages, even after restarting the phone (and not launching the app)?
Thanks!
Yes. You will need a broadcast receiver which listens on the BOOT_COMPLETED broadcast message and launches the push notification service. However, you still have to start the app once to register the receiver. It will also not work if the user force quit the app. There are some approaches, which also will restart the app automatically if the user killed the app, but I think it is a bad practice. In some circumstances the user wants to stop the app and keep it closed.
Related
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.
When none of the activity is launched even once,i want to send a push notification to the user.
For example, once user installs application but doesnt open then a notification is pushed that please use the application.
Please help me with the code.
You can't. How would the user call the registration process for the push messages if he never ran the app itself? Until he does, the app is considered to be in a stopped state and you can't interact with it unless you have another app installed that would "start" it.
You can start a background service on application level and registering on gcm server and other process so even if app is not used you can send notification as your service has registered your device with gcm id on your server.Call api for registering device to your server from your GCMIntentService class.
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
I am currently developing an Android telephony application that includes a service to handle all the SIP signaling for making and receiving calls.
I want this service to start exclusively when the user has correctly logged into the application. However, I am observing an undesired behavior: if the device is shut down while the app is running, the service is automatically started after the phone boots. This does not happen if the application is closed at the moment of shutting down the phone.
I have been reading about it but no answer comes up. Could anybody explain why this happens and how to prevent it?
Thank you in advance.
Thanks to CommonsWare comment I have quickly found the answer:
[...] The only way a service starts up is if somebody starts it, and the OS will not do that on its own.
I was so blinded thinking the OS was responsible for it that I didn't notice it was being done on purpose, as an undocumented feature inherited from a former version of the app.
There was a BroadcastReceiver listening to the android.intent.action.BOOT_COMPLETED action. This receiver was, among other things, restarting the service on start up when the app had not been properly shut down.
Thank you CommonsWare for your help.
Update
After preventing the BroadcastReceiver from listening to the BOOT_COMPLETE action, I still experience the same behavior.
The reason is that this BroadcastReceiver is also listening to connectivity changes to restart the SIP service when the WIFI or a data connection becomes active, only when the app is running. Wether the application was closed or not is stored in the app preferences, but this value was not properly set when the phone was shut down while the app was running.
That is why the service was still unwantedly starting on boot: because the BroadcastReceiver detected an android.net.conn.CONNECTIVITY_CHANGE at start up and the preference telling wether the app was still running or had been quit was not properly updated.
I am running whatsapp (we could call it appX from now on) in device A. I go to manage applications -> force close so appX gets closed and i no longer see appX as running services.
Now, after 5 minutes, I send a message from another device 's appX (device B) to device A appX (the one we killed it).
Here are the 2 scenarios i tested :
device A with android 2.1 : it never receives the message, therefore we could say that none of appX services got restarted. It ONLY receives the message if manually the user restarts the app.
device A with android 2.3.6 : for SOME magic reason, no matter how long it's been since appX got killed, as soon as we send the message from device B -> device A gets the message, therefore, appX's service gets restarted. Note : all the time that appX was closed and WITHOUT receiving any notification, i wasn't able to see any running services of appX in manage applications, so this means that this magic service gets restarted as soon as it receives a message/notification
I know it sounds weird, and lot of people will say this is impossible, but again, this has been tested on these 2 devices.
I am trying to accomplish this same behavior, so any help will be appreciated it.
I don't think it's some magic what happens here! It's just Android C2DM (see: https://developers.google.com/android/c2dm/), whereas the app has a registered Receiver for incoming Push Notifications and gets awaken by this message.
Android C2DM is/was available with Android 2.2, that's the reason why you can't see the same behaviour on your device with Android 2.1 up and running.
By the way: As you can see, C2DM is deprecated since June 26th, 2012. So instead of C2DM, one should use GCM (see: http://developer.android.com/guide/google/gcm/gs.html)
Useful Comment: GCM needs available internet connection. You can using any other broadcast receiver such as SMSReceiver for by passing this limitation.
Starting from Android 3.1 (API 12), if an application is force-stopped it will not restart until the user manually runs the app again.
This will happen even if the app contains a Service or an active BroadcastReceiver.
You can find the official documentation here.
i dont have idea about whatsApp service.
But it is possible that after force stop application, restart service of app.
i use START_STICKY service for my chatApp. i have to do same thing so i use START_STICKY service so when my app kill or force stop from setting, after few second my service get restart and i able to login to my xmpp server and get incoming message.
its nothing magical here appX uses push notifications via android GCM platform https://developer.android.com/google/gcm/index.html in GCM the app registers for a braodcast reciever and the broadcast receiver starts the service on getting the push notification.
Android GCM is dependent on google play services that are available on android 2.2 and beyond that therefore you didn't see the message on 2.1 device