When an Android device receives mail, does it do this by periodically connecting to the mail server? When the device is in standby mode where the screen is off, I assume that the standard mail app also is shut down but possibly uses the AlarmManager to awake and then check the mail. I can't imagine that the mail app is always running with a full Wakelock turned on, keeping the CPU always running, as that would drain the battery.
The reason I need to know this is because my own app needs to get a notification from its own server when certain events take place. I could just as well implement a repeating alarm that activates my app periodically and checks for the notifications. But if the mail client already is waking up at a regular time interval, I probably can save on battery consumption by using e-mail to notify my app instead. For this to work though, it must be possible for the mail app to launch my app when it receives e-mail. I doubt that this is possible, or is it?
This is what you wnat to use:
Google Cloud Messaging
Related
For devices that don't have Google Play Services, there are a few options to be able to receive push notifications.
Those options can be Baidu in China, Pushy, Facebook own push notifications, etc.
But I cannot understand how is that even possible to overcome those two main problems :
Since we cannot have an "SDK" of some sort like the Google Play Service on a device-level, our only option is to integrate it on an app-level. This means, we cannot have one socket connection to the push server that would be mutual for all apps, like the GCM does. Instead, we need to have as many socket connections alive as the number of apps installed.
Even if we close an eye on problem number 1, to make that connection survive Doze and App Standby, we would have to handle them in a Foreground Service, which is the only way to guarantee its running even after killing the app, or when the device enters Doze state.
But how come we don't see the notification of a foreground service in the notification bar in Chinese phones, or apps that use Pushy for example?
Are they simply polling the push server periodically? with AlarmManager (marked with setAndAllowWhileIdle) and a BroadcastReceiver ? that would be too resource-heavy and inefficient.
I have developed a device Admin app that applies policies to the device eg restrictions etc.
How my system works
The webapp sends a push notification to the device via FCM. I used to use GCM and a wakelock.(The latter worked fine). When the push notification comes through to the device, the firebase class that receives the push calls an IntentService. This IntentService then processes the message eg "MOBILEDATA_ON" and any data associated with the message. Once the message has been processed eg MOBILEDATA_ON, the service executes code that turns the mobile data on and then calls a webservice relaying the state back to the webapp.
I chose IntentService as it is Async and is capable of making http calls to relay the state back with no extra async code.
All this works fine when the device is awake, even if the app is in the background.
The problem
If the device is unplugged and untouched for a while, it goes into Doze/Standby mode. (it is an Android 6 device). This is normal behaviour, however if i send a push to the device, the device does receive it and executes the correct code to apply the functionality but unfortunately the webcall that relays the new state of the device is not executed.
so for example, if Bluetooth is switched off on my device and it is in doze mode, i can send a push which switched bluetooth on successfully but the webapp never receives the updated state.
I have set the priority to high in FCM when sending the push, and this why i do receive the push when the device is in Doze.
My app is a Device Admin app, the docs says
The app is an active device admin app (for example, a device policy
controller). Although they generally run in the background, device
admin apps never enter App Standby because they must remain available
to receive policy from a server at any time.
Optimizing for doze
Can anyone tell me why the webcalls are not executing sending the state back to server when in Doze/Standby mode?
[EDIT1]
I used the following code to create a wakelock. At first i acquired the lock in the IntentService, executed the functionality then released it all in the same service. This was good for most cases but some of my functionality includes finding device location via another IntentService called Tracking service.
The problem is that GPS could take say 20 seconds to find a lock by which time the original Intentservice has finished and the device went back to sleep.
To get around this i created 2 methods in the application Object to acquire and release the lock. this way, if the push is one for location i can do a check in the initial service(which normally releases it) to see if the push is a location one and not release it there. Instead the tracking service can make a call to the Application Object to release when GPS is found.
A partial wakelock didn't seem to work as intended so i found the following code that uses a full wakelock. This is depreated though. Is the an alternative to using FULL_WAKE_LOCK?
public void acquireWakeLock(){
wakeLock = powerManager.newWakeLock(PowerManager.FULL_WAKE_LOCK | PowerManager.ACQUIRE_CAUSES_WAKEUP,
"MyWakelockTag");
wakeLock.acquire();
Log.e(TAG, "just acquired wakelock");
}
public void releaseWakeLock(){
wakeLock.release();
Log.e(TAG, "just released wakelock");
}
thanks
Matt
I am struggling with android services. The purpose of app is to send text message using native system text application. The phone recieves phone numbers from Firebase and sends a message to all the numbers from the list via smsManager.sendTextMessage. I realized that few minutes after screen is locked the app stops running for no reason..
As I already said I tried to keep my app running in background with android services but it is not working. Is there any simple way to achieve this?
There are a number of way to make a Service work even when the device is in sleep mode. This depends on the feature you want to implement. As far as I have understood, mobile numbers will come from server and app will send messages to these numbers.
If you want to do it in a repeating manner, You can use AlarmManager to start the service from time to time, and fetch the numbers and send messages.
You can also use wacklock to keep the service running all the time, but this will be more battery draining.
I know that we can't set repeating alarms of short intervals in Android because it drains battery and has other such effects. Well, technically you can, but android will automatically push it up to a minute citing "suspiciously short duration".
So how exactly does an app like WhatsApp or Facebook constantly update our messages or newsfeed? I thought they fire an Alarm each second, but clearly that is impossible because the OS will push it up to a minute anyway. Using Handlers/Threads is off the question anyway because they don't fire when the app is closed, but WhatsApp updates your messages even when the app is closed.
So what exactly do these apps use if not AlarmManager to do the aforementioned task, and if they use AlarmManager, how do they set the short duration?
They have a service that uses push messaging. So basically they open a socket connection to a server and sleep until the server sends data to them. Its an interrupt mechanism, not a poll.
Not specific to any service like WhatsApp or Facebook, the idea behind this whole system works like this.
For Android in particular (or in general),
Your device registers with the Google Cloud Messaging (GCM) service
It allows GCM to create a HTTP persistent connection with your device
This connection is lightweight and persistent (stay alive for a long time)
With this, you will be able to consume these services, sending messages in this fashion.
Your Server ---> Google GCM Service ---> Target Device
When you send your messages, do not include the whole message itself. You should keep it lightweight by just sending simple messages to notify the targeted device that it has new information to be downloaded.
At your device application, you set up permissions and intent to listen for these push notifications. Whenever, there is new messages, you will make a request to your server to receive the corresponding messages.
Here's a guide to explain in depth: https://github.com/codepath/android_guides/wiki/Google-Cloud-Messaging
Cheers! Happy Programming!
Can Pusher messages be received on Android/iOS app when the app is closed or the phone is turned off?
What i expect to happen...
When phone is on & app is on, it's pretty straight forward from the Pusher docs on how to react to pusher messages sent to the app.
When phone is on & app is closed, the phone should receive a notification that something has been sent to the app.
When phone is turned off, a notification should be received by the phone when it's turned back on to notify that something has been sent to the app.
Are these even possible? If yes, what are some suggestions to lookout for? If no, what can be some workaround?
When an application using Pusher moves into the background on iOS and Android the connection to Pusher will likely stay active for a few minutes. But eventually that connection will be closed. You can't stop that happening within your application (although there may be a "hack" around stating your app is a Voice app when submitting to the Apps store).
Therefore, you should monitor your application moving to the background and put a fallback in place to delivery messages to the phone when it's not connected.
Please see How get pusher events when the iOS app go to the background? for libPusher (the Pusher iOS library).
Here's an extract from the Android Processes & Threads Lifecycle docs on a "Service Process":
A process that is running a service that has been started with the startService() method and does not fall into either of the two higher categories. Although service processes are not directly tied to anything the user sees, they are generally doing things that the user cares about (such as playing music in the background or downloading data on the network), so the system keeps them running unless there's not enough memory to retain them along with all foreground and visible processes.
So, running a Pusher instance in such a thread is a viable option.
However, there will still be occasions where the user goes offline. In that situation your server you can detect if a user is online by querying the Pusher HTTP API or by using WebHooks where your server can be instantly informed if the user has gone offline or come back online.
Using the mechanisms above you can facilitate smart notifications; if the user is online (the app is in the foreground) then send the message to them by Pusher, if they are offline (the app is in the background) then use an alternative mechanism for delivery (native Push Notification, SMS or email).