we have developed geofencing for capturing entry and exit times at specific locations in background. In some mobile phones, entry and exit are captured with a delay of 2-4 minutes.
We would appreciate your help in fixing this
I have used Broadcast Receiver to receive the Geofence alerts, I register the receiver in android manifest file. But in android document it said that alerts will be late from android O and above if Background Location Limits exists.
Question :
If I register the receiver dynamically using mContext.reigsterReceiver() programatically. The delay in receiving geo fence alert will not be their ?
If we register the receiver in Android Manifest or via programtically (mContext.registerReceiver()). Their will be delay in receiving geo fence alerts ?
My application need Geo fence alerts immediately with out any delay in both the cases Either Application in Foreground or Background, What should I do for that?
Mainly samsung and moto mobiles it is not working.
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/.
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 am trying to collect GPS location every 5 seconds from a smart phone by using socket.io.
I notice that when users pick up a phone call, socket.io will stop emitting messages. When users switching tabs in the browser, socket.io will stop emitting messages too.
Does anyone know how to solve this problem?
Thanks very much!
Your best bet would be to package the website in a native app. Use a service such as http://build.phonegap.com or Intel XDK. There are configuration options to keep your app alive in the background. As for it disconnecting during phone calls, this is a carrier limitation. If the user was connected to WIFI, most phones will that for data while simultaneously on a call.
Some networks (such as Verizon) do not have the capability to do voice and data at the same time. Thus, when a call is made, data is suspended until the call is finished. AT&T does not have this limitation.
The operation of background tabs will vary by mobile browser and is likely done for battery conservation reasons. It is unlikely there is a work-around to keep the background tab running (because that would defeat the whole battery management purpose).
I'm using BackgroundAudioPlayer agent in my Windows Phone 7 application. When the track end, the agent side receives TrackEnded event, but UI side doesnot receive any events.
Also, when I intentionally set audio track 's position to its end, then call Play(), the agent side receives TrackEnded event (because the track has come to an end), but the UI side does receive Stopped in its PlayStateChanged handler. So weird !
How to let UI know that an track has come to an end ? Communicating through isolated storage is not my favorite !
From research and a little testing, using Isolated Storage as a middle-man between Background and Foreground instances of the BackgroundAudioPlayer is still the only route for Windows Phone 7. The options are mentioned here (which I know you're aware of)...
http://blogs.msdn.com/b/wpukcoe/archive/2012/02/10/background-audio-in-windows-phone-7-5-part-2.aspx
http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh202944(v=vs.105).aspx
https://stackoverflow.com/a/11419680/247257
This was also confirmed by Peter Torr who said:
For example, the agent may need to tell the foreground “I just started pre-downloading the next track,” or “I updated a database table and you should refresh your state”. Such notifications are impossible to create with Windows Phone OS 7.1; at best you can model them by using polling techniques, but this approach is inefficient and prone to errors.
The only good news is that in the same post, he gives a solution (using named events for IPC) for Windows Phone 8 which is a lot more reliable...
http://blogs.windows.com/windows_phone/b/wpdev/archive/2013/03/27/using-named-events-to-coordinate-foreground-apps-and-background-agents.aspx
I read the instructions here about WP7 background audio player agent. I thought there is only 1 Unknown event and 1 Playing event in agent side
However, when I log the event in OnPlayStateChanged of the agent, using
System.Diagnostics.Debug.WriteLine(player.PlayerState.ToString();
I receive 2 Unknown and 3 Playing events when a new track is play
It's weird, why is that?
P/S: I use the code sample on MSDN How to: Play Background Audio for Windows Phone
Thanks to Peter Torr, I found the reason
Due to the asynchronous nature of media playback, you should use the
arguments to the OnPlayStateChanged callback to drive your logic. You
shouldn’t need to query the player (that is mostly for the foreground
app to display UI).