I'm currently working on an application that causes devices connected to firestore to vibrate on cue. Currently it works fine, but after ~5+ minutes of a connected device/app being put to sleep, there is no response. Currently I have it so connected devices are given a bool field which has a listener to vibrate the device when the bool is true. I was thinking of sending a push notification to try and force the device to vibrate, but that's if there's no solution. Is there anyway to force the device to remain listening for firestore changes for an extended period of time? (listening in the background)?
This is expected behavior and not anything Firebase/Firestore controls. To conserve battery life, Android closes connections from applications if they haven't been actively used in a while.
For this reason you can't expect to keep receiving updates from Firestore (or any other such mechanism) if the app is backgrounded or if the phone is put to sleep.
The common solution for this is indeed to (also) send updates through FCM, which is treated differently by Android's power management feature.
Related
We have a medical watch which continuously produces measurements. The measurements need to be analyzed offline in the cloud, and are uploaded from an application which communicates with the watch using BLE.
What we do today is we run a service as a short foreground job every few minutes, extract as much data from the watch and then go back to sleep.
We’d like to speed up the process, and also receive alerts from the watch in real time. Is using Android’s CompanionDeviceManager the solution to this? Will it allow the application to receive notification while it’s in the background?
CompanionDeviceManager does not directly affect GATT notifications in any way.
Whenever any device has been paired through the CompanionDeviceManager by the app however, the app gains these permissions:
The app can start activities, turning on the screen, while the screen is turned off. See https://developer.android.com/guide/components/activities/background-starts. This was always allowed up to Android 9, but for Android 10 and later this is now restricted and having a paired device this way is one way to lift this restriction.
https://developer.android.com/reference/android/Manifest.permission#REQUEST_COMPANION_USE_DATA_IN_BACKGROUND. I guess this relates to the use of mobile data traffic in the background.
https://developer.android.com/reference/android/Manifest.permission#REQUEST_COMPANION_RUN_IN_BACKGROUND. It's a bit unclear to me exactly what this permission does, but at least this can help you start a foreground service while in background.
The CompanionDeviceManager doesn't really affect the Bluetooth API or Bluetooth communication in any way. The important thing in order to have working GATT notifications is to not get the app process killed, which can example be done by making sure a Foreground Service is running in the app process.
I 've tried background_fetch: '^0.1.0'
and alarm_manager package, but when the app is closed, it removed from the recent apps, and it does not work.
I need to hit API every 15 min n show Notification if data is there
when App is closed
any solution without writing Native code.
I don't know iOS development, I know Android
I don't need Firebase Push Notification
Background fetch is not controllable on iOS by the app developer. It is controlled by the OS. You sign up for "Background App refresh".
Once your app has registered for Background App refresh. The OS will awaken your app periodically at it's discretion to let you do some work. Then your app is put right back into sleep again. Depending on how long it's been scene the user opened your app it may have been purged from ram. If you are purged from ram it's very likely you won't be awakened again until the user opens your app or is plugged into power and charging the phone.
From https://pub.dev/packages/background_fetch
iOS can take some hours or even days to start a consistently scheduling background-fetch events since iOS schedules fetch events based upon the user's patterns of activity.
iOS favors Push notifications to save battery life. All push notifications run though apples APN service.
https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server
This saves on battery life as only one constant connection has to remain open on the device to Apple. Instead of multiple connections from many servers.
Context
We are developing an android app that is supposed to do the following:
the user installs the app, registers and closes the app
once or twice a year an admin sends a Firebase data message with priority high to the user containing a geo fence
the FCM message starts a JobService that locates where the phone is
if the phone is inside the given area an Activity is started and user interaction starts
if the phone is outside the area the service is stopped and the user is never disturbed
I developed the app based on the Firebase push example found here
The problem
The application works fine on my older phones but on my new test phone (android 8.1.0, LineageOS 15.1) we have a problem when the phone is in sleep mode. In this case the FCM message arrives instantly but the service is first started once the phone is unlocked. So the message is stuck between 2. and 3.
We need the app to respond at once - not when the user decides to use his phone 2 hours later.
I assume the problem is due to the Doze mode introduced with android 6. I tried to solve it by adding the app to the whitelist in settings->battery->battery optimization but this did not solve the problem.
Questions
Is it Doze mode that delays my app between 2. and 3.? If so why is it not solved when the app is in the whitelist?
Is there any other way to start the location service at once? This post suggests that a foreground service can do it but this requires that a notification is shown which breaks with 5.
Is there another way to start my service at once besides whitelist and foreground service?
Yes! you are right this may be due to the Doze and App Standby features introduced in API 23 Marshmallow.
As mentioned in the documentation, the system do ignore wakelocks and system doesn't allow JobScheduler to run, which effectively prevents your app from running the Job.
An easy and effective workaround would be to run Location detecting routine inside a normal background service and start it using startService() when you receive FCM push.
Note that you might still need to white-list your app because as mentioned in another post here, only a whitelisted app can use the network and hold partial wake locks.
Is it Doze mode that delays my app between 2. and 3.?
From the documentation Doze mode affect Network access and blocks JobScheduler.
If so why is it not solved when the app is in the whitelist?
Also from the documentation: An app that is whitelisted can use the network and hold partial wake locks during Doze and App Standby. However, other restrictions still apply to the whitelisted app, just as they do to other apps.
So the blocking of JobScheduler still applies.
Is there any other way to start the location service at once? This
post suggests that a foreground service can do it but this requires
that a notification is shown which breaks with 5.
Ignore Battery Optimizations (for Internet access) in combination with an AlarmManager with setAndAllowWhileIdle() or setExactAndAllowWhileIdle() should work.
Be careful with Ignore Battery Optimizations
Google Play policies prohibit apps from requesting direct exemption from Power Management features in Android 6.0+ (Doze and App Standby) unless the core function of the app is adversely affected.
I think an important question here is: Do you really need to execute the JobScheduler immediately.
If a user leaves a device unplugged and stationary for a period of time, with the screen off, the device enters Doze mode.
If the device is in Doze mode, it means the user is not using it.
if the phone is inside the given area an Activity is started and user interaction starts
This is the step Doze blocks
We need the app to respond at once - not when the user decides to use his phone 2 hours later.
If the device is in Doze it means the user is not interacting with it. Even if you show the Activity the user is not using the phone, he will see it when he starts using it 2 hours later :)
I still didn't try that,
but you might use a WakefulBroadcastReceiver:
https://developer.android.com/training/scheduling/wakelock.html
https://developer.android.com/reference/android/support/v4/content/WakefulBroadcastReceiver.html
According with this links, you should declare your receiver as:
public class YourReceiver extends WakefulBroadcastReceiver {
Probably your receiver is already a WakefulBroadcastReceiver because notifications are showing..
In the receiver, you start the service (your service has to be an IntentService) using:
startWakefulService(context, your service);
Finally, remember to release the wake lock in the service:
#Override
protected void onHandleIntent(Intent intent) {
<Your_broadcast_receiver_class>.completeWakefulIntent(intent);
}
I hope it helped
I made the device which monitors person's health in sleep time and it connects to a smartphone via BLE.
It's working great with the iOS app.
But since Doze mode came on Android world.
It's really hard to deal with it because my device is working in his sleep time.
The main feature is that it detects particular danger and notify to the user while he is sleeping with the device. I need a network connection when it occurs.
Many articles tell me that I can use a network even in the doze mode if my app is in the whitelist. But it does not seem true after I tested Doze mode.
Am I right?
I can ensure that I can find my app in the lists, when I fire
adb shell dumpsys deviceidle
What is the best approach that I can take to make my app working correctly?
foreground services
alarm manager with SetExactAndAllowWhileIdle.
GCM (it means push, right?)
anything else
Any tips will help me.
Thanks.
Edit
Unfortunately, I tested with using GCM but it only wakes my app in short time. It means I have to send GCM as many as I want to keep it awake. I don't think I can use it.
Many articles tell me that I can use a network even in the doze mode if my app is in the whitelist. But it does not seem true after I tested Doze mode. Am I right?
You are not right. One of the restrictions of doze that are lifted when your app is on the whitelist, is the ability to use the network when doze is active.
An app that is whitelisted can use the network and hold partial wake locks during Doze and App Standby. However, other restrictions still apply to the whitelisted app, just as they do to other apps. For example, the whitelisted app’s jobs and syncs are deferred (on API level 23 and below), and its regular AlarmManager alarms do not fire.
From here.
In other words: you should be able to use the network in doze if you are on the whitelist.
What is the best approach that I can take to make my app working correctly?
Considering your app is a health monitor and thus should be able to do its work constantly or at least very regularly, you could put the functionality in a foreground service. Foreground services are not effected by doze.
You should be aware that you should have a good reason to use a foreground service since the user is aware of them, but I think you have one with the health monitoring etc.
Note: You should only use a foreground service for tasks the user expects the system to execute immediately or without interruption. Such cases include uploading a photo to social media, or playing music even while the music-player app is not in the foreground. You should not start a foreground service simply to prevent the system from determining that your app is idle.
From here.
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).