In my android application i am using android push notification everything works fine until the user forces the application close(It happens always nowadays especially with the task monitoring application available in the play store).No more notifications are visible or possible.After some googling i found that From android 3.1, if the user force closes an app, it will stop to be notified of any broadcast until the user does not start your the again.
Is there any solution to prevent the broadcast receiver killing or any other possible (like making a Que of messages that aren't received by the device and send them later)?
if the user force closes an app, it will stop to be notified of any broadcast until the user does not start your the again.
sorry, that's not true. for sure.
I think you are confusing with something else: from android 3.x - broadcast receivers would never react to a broadcast until the app is launched for the first time.
if you implemented properly your GCM client side - it should work even if user force close the application. that's because the operating system waking up your application if it has the right broadcast intent filter and receiver, what mean that your application don't have to be running in order to receive this broadcast.
No more notifications are visible or possible
If your indication that the GCM not received is the fact that you don't see any Notification, then it's not necessarily true - there is no direct connection between GCM message to the system bar notifications. that's true that usually you'll show notification when push received, but it's deferentially not must.
what I'm saying basically - maybe you have a bug that takes affect after the user force close your app that causing the notifications not to be shown.
Related
I would like to know if an Application such as whatsapp or youtube is opened by the user. Looking at the logcat, I can see that when the activity of the whatspp is opened - following
com.whatsapp.intent.action.CHATS
intent actions is opened. Am looking for a way to log this - so I can run an algorithm to suggest which page of the application will be opened at a given point of time
There are some broadcasts that require explicit registering in the system (Annotated with You can not receive this through components declared in manifests, only by explicitly registering for it with Context.registerReceiver().).
The most important ones for apps that run code after installing are:
ACTION_USER_PRESENT: Sent when the user is present after device wakes up (e.g when the keyguard is gone).
ACTION_SCREEN_ON: Broadcast Action: Sent when the device wakes up and becomes interactive.
ACTION_SCREEN_OFF: Broadcast Action: Sent when the device goes to sleep and becomes non-interactive.
ACTION_MY_PACKAGE_REPLACED: A new version of your application has been installed over an existing one. This is only sent to the application that was replaced. It does not contain any additional data; to receive it, just use an intent filter for this action.
ACTION_HEADSET_PLUG: Wired Headset plugged in or unplugged. Same as ACTION_HEADSET_PLUG, to be consulted for value and documentation.
ACTION_DATE_CHANGED: The date has changed.
What I have studied on stackoverflow and Android documentation.
Finally I've concluded this:
There is no way to create a background service for continuous tasks. If I really want a service I should start a foreground service and user continuously sees a persistent notification "App is running". There is no way to hide this notification. It is intentionally added by Google.
Yes there are other options like WorkManager and JobScheduler but they do work periodically not continuously.
What I do want is to build an instant messaging app which continuously connects to the server using xmpp or sockets. But it requires a continuous connection but I don’t want to use a foreground service because it shows an irritating notification to the user "App is running".
Question 1: How does Whatsapp and other instant messaging app continuously connect to the server but not show a persistent notification ? How do they achieve this ?
Question 2: If Whatsapp use FCM for notifications then it will also work in those mobile which do not have playservices installed, so how does Whatsapp notification mechanism works ?
Starting with Android 6.0 (API level 23), Android introduces two power-saving features that extend battery life for users: DOZE and APP STANDBY. These two features enforce many restrictions on your background processing while the phone is in Doze mode. You should read about Doze and app standby in the following link
https://developer.android.com/training/monitoring-device-state/doze-standby
Now, about your use case is that you want to receive the messages and incoming calls even when the app is not running. For this use case, Android announced High Priority FCM messages in GoogleIO2016. They are high priority Push message which grant the application temporary wakelock and network access, independent of Device's Doze state or if the app happens to be in the app standby. This allows the application to react to the message and notify the user in whatever way it wants about the instant message or incoming call.
I don't know exactly how WhatsApp does that unless I look at their code but you can handle your use case using FCM High Priority Messages.
For more about your use case, follow the below link ofGoogleIO2016 Video from 08:30m to 10:30m
https://www.youtube.com/watch?v=VC2Hlb22mZM&t=505s
and read about this use case on the first link in this answer.
I have an Android application that has a chat client as one of its features. The chat client uses XMPP based on the Smack library for Android and running Openfire as XMPP server in the background. The connection is established using BOSH The whole XMPP connection handling is implemented as a service to run and listen in the background for incoming messages even if not activity of the app is in the foreground. So far, everything works perfectly fine.
The only problem seems to be the sleep mode. In the emulator (when set to "Stay Awake") or with the phone in use, the XMPP connections is holding and the app can send and receive messages. However, once the phone goes into sleep mode, the XMPP connection breaks down -- I can see it in the Admin Console of the Openfire server that the user is offline. Intuitively, I want to receive messages all the time like, e.g., WhatsApp.
Of course, I've searched online including Stackoverflow, but I couldn't get a definitive answer. Often the use case seems to be that a task has to be performed periodically, say, once every hour. But this doesn't seem to fir in case of a chat client. Since I assume this is a common use case -- after all, there a so many chat apps or apps with chat features out there -- these are my question:
How to I have to change / extend the app that I can receive chat message while the phone is sleeping?
I've stumbled upon WakeLock. Is this the way to go or are these not suitable for my use case?
Since Lollipop, there's also the JobScheduler API which itself uses WakeLock. Any better?
How does, for example, WhatsApp handles this case?
On a side note: I have problems with the sleep mode using the emulator for debugging. When I switch off "Stay Awake" in the emulator, the screen goes black after 1+ min and the XMPP connection breaks. But I somehow have no idea how to wake up / switch the emulator back on once it went black. Android Studio actually tells me at some point that the device or something is gone, and I have to restart the emulator again.
The exact way to resolve this issue is by using push notification.
It is the natural behavior of XMPP connection to get disconnected after the specified idle interval i.e when the device goes to sleep.
Coming to the case of WhatsApp, it also uses the same XMPP and maintains a server which acts as a wrapper class on the messages exchanged. This server checks the message status whether it is delivered or not. If not delivered, it sends a push notification, now at the device end in the push service when a message is received, it checks if the connection is active and is authenticated or not.
If not authenticated, it re-establishes the connection. In this way, the most chat apps manage this timeout exception.
Hope this helps :)
You don't need push notifications, you don't need WakeLocks. Instead simply
Whitelist your app from doze mode
Use a sticky (START_STICKY) background service
Use Smack's ServerPingWithAlarmManager
Act on CONNECTIVY_CHANGED intents send by Android, and use XMPPTCPConnection's instantShutdown() in that case.
I'm working on an application that handles text messages. This is a personal application and I do not plan to release it, however it's basically going to allow me to share my text messages (and phone number) between numerous devices through the internet. It's a fun learning project too as a first application, and I've done quite a lot.
However the annoying part is the text-message popup that my device gets when receiving a message. I love it when I'm using the device, and I could always just go into the options and disable the popup when I'm not planning on using the device, but I'm a very, very forgetful person and turning it back on wont always happen. Then I'll never reply to messages.
Basically I want to programmatically interrupt (or not even notify) my default messaging application of the text message, however I still want it to be logged in my messaging history. So the message can't just be "discarded". This should only happen of-course while my applications service is running.
I've been searching through the android API for quite some time and I just can't seem to figure this out, is it possible and if so can you link me to the proper place in the API to begin?
Basically I want to programmatically interrupt (or not even notify) my default messaging application of the text message...
This isn't possible.
Assuming by "interrupt" you mean to prevent the default SMS app from issuing its Notification, you can no more do this with the default app than you could with any other app that you don't control.
Additionally, as the default SMS app responds to the SMS_DELIVER_ACTION broadcast, and it is the only app to receive this broadcast, it wouldn't be possible to "not...notify" the default app of an incoming message. Your app wouldn't even have a chance to abort the broadcast, even if it were possible to do so.
(In versions prior to KitKat, it was oftentimes possible to register a Receiver with a high priority for the SMS_RECEIVED_ACTION broadcast, and then abort the broadcast before the native SMS app received it. This is what rajan ks's answer refers to.)
...however I still want it to be logged in my messaging history.
The default SMS app is responsible for writing all incoming messages to the Provider. Even if you were able to prevent the default app from receiving the incoming message, your app would then have to write the message itself. This isn't really possible, either, as the default app is the only one with standard write access to the Provider.
I am working on Push Notifications in Android. Now the issue is that I want to keep running my Push Notifications on the back ground as soon as the app start because I have no idea when the server will push the data to the devices.
The main requirement is that our corporate app is having more than 10 activities and based on the notification received, I have to bring the related activity on the foreground so that user can preform action on that or do some silent action in the background regardless the activity is in foreground.
Can somebody suggest how can I implement this type of requirement. Do I need to do it in a Service.
Thanks
An Android application on an Android device doesn't need to be running to receive messages. The system will wake up the Android application via Intent broadcast when the message arrives, as long as the application is set up with the proper broadcast receiver and permissions.
take look at this;
http://developer.android.com/guide/google/gcm/gcm.html
when message received from gcm server
onMessage(Context context, Intent intent): method of GCMIntentService gets fire,
so you write your code there
take sample example from here
https://github.com/ketanpatel25/GCM-Demo/tree/master/gcm
What you're trying to do defeats the purpose of push notifications. In push notifications, the server sends the message through Google APIs. These APIs then send a broadcast message to your app, which you listen for. Continuously keeping the app open in the background and asking the server for new messages is called polling.
Read up on the GCM documentation. Whenever you receive a message, Android will ca the onMessage(); method of your GCMIntentService.