I'm an Android developer and working on a wearable app that runs on Galaxy watch 4.
In short description, this app use a foreground service that's connected to Mqtt broker and receives real-time alerts and displays them to the user.
Up until recent system SW upgrade I used a Wifi Lock to keep the network alive for my app and the foreground service allowed my app to keep running in the back during idle mode. I also used a Wake Lock to wake the watch when an alert was received so it can be displayed to the user.
On 16.02.22 the watches were updated and after that, whenever the watch turns off the screen and goes into idle mode, my application disconnects from all OS resources (network, even CPU). It seems like the process is suspended. When I bring the watch back from idle, my application continues running but its stays in the background and not returned to the fore.
I tried different approaches to solve this, such as Ambient mode and more, all my efforts to come up with a workaround met a brick wall.
Am I missing something?
I see other apps that use body monitoring via the sensors for example, that keep working and throw notifications even when the watch is idle.
Please help, how can I keep my app alive and the service running (and using the network) during watch idle mode?
Related
So what i want to do (if posible) is to execute a function after a certain time even if the app gets closed by the user, what the function does is send a mqtt message to a server. I heard about AlarmManager and BackgroundReciver, but i dont know if that can play a whole function. Can someone tell me if it's possible?
In android, you can try to use Services to achieve this.
And from document Background Execution Limits in Android 8.0,we know that
Starting in Android 8.0 (API level 26), an Android application no longer have the ability to run freely in the background. When in the foreground, an app can start and run services without restriction. When an application moves into the background, Android will grant the app a certain amount of time to start and use services. Once that time has elapsed, the app can no longer start any services and any services that were started will be terminated. At this point it is not possible for the app to perform any work. Android considers an application to be in the foreground if one of the following conditions are met:
There is a visible activity (either started or paused).
The app has started a foreground service.
Another app is in the foreground and is using components from an app
that would be otherwise in the background. An example of this is if
Application A, which is in the foreground, is bound to a service
provided by Application B. Application B would then also be
considered in the foreground, and not terminated by Android for being
in the background.
There are some situations where, even though an app is in the background, Android will wake up the app and relax these restrictions for a few minutes, allowing the app to perform some work:
A high priority Firebase Cloud Message is received by the app.
The app receives a broadcast.
The application receives and executes a PendingIntent in response to
a Notification.
You can also refer to https://robertohuertas.com/2019/06/29/android_foreground_services/.
can any one help me with the background services with XF, i had tried following the documentation, as i am able to run the activity when my app is in background but as soon as i terminate the app the background activity also gets terminated
Example - Whatsapp running in background even if we clear the app from running stack
There are/was problem for me with background service and Google Analytics implementation (https://github.com/KSemenenko/GoogleAnalyticsForXamarinForms). Something with timers (repeaters), check your source/packages for Device.StartTimer usage, at background mode they must be stopped or background service will be terminated.
I am building an Android App to control power outlets with a smartphone. The app features an Android Wear app so people can control their lights right from their wrist.
When the user wants to control a light I send a String action via the MessageApi from the smartwatch to the smartphone, which receives this action in a WearableListenerService and sends the appropriate network signal to the power outlet/gateway in an AsyncTask.
This works fine as long as the phone has not been in idle for too long. However if the phone is still on the table for too long and doze kicks in Wear actions do execute very slow or sometimes not at all. I guess this is in part intended behavior however it is not practical in my case as the user cant wait that long for his lights to turn on if he wants to enter a dark room.
I am aware that doze completely cuts the networking for everything except FCM/GCM if you are not on the doze whitelist. But even when my app is on this whitelist and the networking part works actions can take a long time to execute on the phone.
So my specific question is:
Whats the recommended way to handle this scenario, where an action from a wearable device needs to be done via network on the connected smartphone which is in doze mode?
Is there a way to exit doze for a quick amount of time to execute calculations triggered by the wearable companion app faster?
I know the AlarmManager has a new method that works even in doze mode, but will this fix the processing delay too? Firing an alarm after receiving a MessageEvent from MessagApi seems like a workaround to me.
Or maybe is an AsyncTask just the wrong way to handle background networking and thats where the delay comes from?
Actually, there are a few options that you can do to handle Doze's effects as given in Adapting your app to Doze. You may want to consider the following options:
If your app requires a persistent connection to the network to receive messages, you should use Google Cloud Messaging (GCM) if possible.
GCM is optimized to work with Doze and App Standby idle modes by means of high-priority GCM messages. GCM high-priority messages let you reliably wake your app to access the network, even if the user’s device is in Doze or the app is in App Standby mode.
To help with scheduling alarms, Android 6.0 (API level 23) introduces two new AlarmManager methods: setAndAllowWhileIdle() and setExactAndAllowWhileIdle(). With these methods, you can set alarms that will fire even if the device is in Doze.
However, please note that with these methods, neither setAndAllowWhileIdle() nor setExactAndAllowWhileIdle() can fire alarms more than once per 9 minutes, per app.
Please try going through Optimizing for Doze and App Standby for a more detailed information or discussion.
In addition to these given documentations, the same options in handling Doze were also given and discussed in Diving into Doze Mode for Developers which might also help.
I wonder if the background time that an app receives when entering an ibeacon region can be used for opening a session with an external accessory object. Can the app then also keep on running in the background while the session remains open?
This of course assuming that the external-accessory background mode is enabled.
While I have not tried this myself, I do not see any reason why it wouldn't work. You would need to have a legitimate reason in Apple's eyes to use the external-accessory background mode in order to get your app approved.
Assuming you have this, as soon as the app sees an iBeacon in the background, the app gets about 5 seconds of run time, which should generally be sufficient to establish a connection to an external accessory. If the connection is made, and the app is exchanging data with it regularly, the external-accessory background mode should keep it going in the background indefinitely, so long as the connection to the external accessory stays open. So long as this is true, the app will probably be able to get ranging updates in the background indefinitely, too.
It doesn't take a huge leap of logic to see that you could build a device that behaves as an external accessory and an iBeacon simultaneously, and use this to get around the usual iBeacon background rules. That said, you'd need to be careful that Apple doesn't think this is illegitimate, or the app could get rejected quickly. To avoid this rejection, you probably would need to be providing some benefit to the end-user via that external accessory channel.
I am working on an application that is receiving XMPP notifications using the Matrix SDK. As well I am using async web service calls to receive an initial set of data from the server.
Now, I am aware that with Mango I can close the app or move it to the background and have a background task that is able to be run every 30 mins (or so) for 15sec max which obviosuly means the XMPP push isn't going to work in this scenario. Is there any way to get background apps to execute more frequently than this?
Failing that for the syncing process all I can do is every 30 mins use a web service call to get any updates and store into Isolated storage for my app to pick up when it's next run. But I believe I cannot use any UI from a background task so cannot tell the user of updates?
So, if I get an important message can I somehow override the slowness here and force my app to run and inform the user visibly that something has happened and he needs to look at it? Is this where push notifications come in?
You can use the ShellTile API to update the application's tile on the Start screen, or use the ShellToast API to show a toast to the user. Both of these can be configured to launch into a specific part of your application (deep-linking) when tapped.
If you need a constant monitoring/update/notification system for your application when it's not running, then using push notifications is probably the more appropriate approach.