I have an app that uses GPS for regular updates. It used to be the case that when the device was put to sleep (screen turned off, screen timeout etc), the location updates kept on coming through. This was on an HTC Desire running 2.2.
I need that behaviour for various reasons.
However, now being tested on an HTC Desire S running 4.0.4, and what seems to happen is that updates continue (1/sec) for about 5 seconds after entering sleep mode, but then stop. However, exactly the same code running on a Google Nexus 7 running 4.4.2, and the updates keep coming through.
The activity life cycle seems to be doing all the right things (onPause when entering sleep, onResume when exiting sleep), but on the Desire S, the location updates stop.
Whilst no doubt it is more power efficient to turn them off, I need them on. The behaviour seems OS and/or device dependant. How can I achieve that?
Edit: actually I've found that location updates do keep coming, just much less frequently than requested.
First of all only the onPause() is called with 100% of probability by OS, onStop() and onDestroy() could be not called by OS. You should unregister in onPause(), in addition the design is wrong because to do it you have two options:
1) Use a pending intent with a broadcast receiver/intent service to manage the position;
2) Use a foreground service to install a location listener.
Activity it's not the good place to do this thing.
Actually the simplest way of doing this seems to be a partial wake lock.
Related
I'm trying to keep a Service alive beyond the Activity lifetime.
On two phones (Samsung Galaxy S6 and Sony Xperia Z3 Compact) starting an activity in a different process than the Activity then swipe remove the app while Service is visible and notification is shown keeps the service alive.
On a third phone, Huawei Honor 8 the exact same code destroys the Service and cancels any alarms scheduled immediately.
I've had alarms scheduled every 10 seconds (they get cancelled at once on Huawei and works on Samsung/Sony). And having a LocationListener active while running the service in the background.
Another difference is that priority MAX and ongoing notifications on working phones are not cancellable by swiping them away or clearing, but that too is possible on Huawei.
I've requested ignore battery optimization and other settings without any difference. I've also tried looking for an option to not kill the app while the screen is off, which Huawei seem to do at once too.
What can be done about this scenario to keep the service running after the activity is killed or just not actively running. If on low memory, the activity goes but never the service since it hardly consumes any memory. But with this settings, the service gets killed instantly.
Am I looking at specific manufacture settings that I possible can't predict or control from code?
The only possible solution I can see for this type of problem is to send silent pushes to the system checking if the service is alive very frequently and then restarting it when it should be active (due to user choosing to do so but system killing it anyhow).
For Huawei Devices there is an issue that you can swipe away the ongoing notifications from the Notification panel. This is registered as an issue as it should not behave like that and has been fixed and would be working fine on the new updates .
Regarding the Service getting killed when you close the task from RecentsActivity, its because Huawei has a System app called HwSystemManager(PhoneManager) which does this task. If you go in PhoneManager and under protected Apps, enable your APP as Protected APP, then it will not kill your services and your App may be alive in the background for a long period of time until and unless there is a Low memory situation.
My application have a realtime module that should ping the server every 60 seconds. Without this, the connection will be dropped and the device will need to reconnect again.
The first attempt was to use a Thread.Sleep to make the pinging thread runs at the desired frequency. The second attempt was to use the ScheduleExecutorService. Both worked very well, but only when the device was charging or with the screen turned on.
After reading a bit, I realized that this behavior happens because the device's processor sleeps and this interferes on the timers. So, the recommendation is to use the AlarmManager...
After start using it, I noticed the my device's screen started to be turned on frequently and I think that this is caused by the alarmmanager that 'wakes the device up'. I searched o bit to see how to use AlarmManager to execute some background actions even if the device is sleeping, without turning the screen on, but nothing was found.
So, there is anyway to use AlarmManager or other approach to accomplish this? Execute a background task even if the device is sleeping, without turning the screen on?
PS1: I know the battery consumption implications due this approach and the request about not turning the screen on is to minimize it's impact.
PS2: The AlarmManager's intent is being consumed by a background service.
Alarm Manager does not turn the screen on. From the docs,
When an alarm goes off, the Intent that had been registered for it is broadcast by the system, automatically starting the target application if it is not already running.
I am using it in my code and it does not turn the screen on unless I explicitly set a wake lock policy that turns it on. Take a look at WakeLock
The last 3 are deprecated as of API level 17.
I recommend you to use a PARTIAL_WAKE_LOCK for your task. or you can take a look at WakefulBroadcastReceiver
If you are using onReceive() method, that may be acquiring your wakelock. Remove the WakeLock parameter in onReceive().
Hello I've a basically simple question to ask, what happens to the android OS when my smartphone's screen goes off ? I've noticed a couple of misleading behaviours into my application like :
When screen is off I cannot anymore get results from bluetooth scan, it's like there are no more active devices around me while actually there are like 3-4.
When screen is off most of the times I cannot send or receive messages from other devices via bluetooth.
As soon as I turn the screen on everything start to work fine again, then I turn off the screen again and after like 5-10 my phone stops working properly. I don't have anything inside the onPause method.
Is there somekind of trigger that get fired every X minutes that leads the devices into sleep/hibernate mode?
EDIT :
I decided to call every X min a full wake lock but for some reason my application started to behave weirdly. Yesterday I noticed that the system killed on purpose my application calling the onDestroy() method. Is this even possible? I mean my application uses like 32 MB of RAM and on my test phones I have like hundreds MB of free memory.
In another case the system closed my app and restarted it, how can this happen?
Sometime after the screen turns off, based on user settings for inactivity.
CPU might sleep and threads might suspend..
so you WAKE_LOCK or AlarmManager ...
AlarmManager has a method to setRepeating Alarm every X seconds
My application needs to collect data from both sensors and GPS, but it seems that after I turn the screen off, the update rate slows down considerably (to 500ms, down from 20ms, or stops completely, in another phone).
I've read several workarounds: one of them involved using a wake-lock, to keep the process running, and another that says to register a broadcast receiver to re-register the event listeners after a screen-off event.
Both don't return errors while executing, but somehow the sensors stop behaving exactly after the screen turns off (and coincidentally, they start behaving right after I press the power button, nevermind unlocking the screen).
I'm registering the BroadcastReceiver from within an activity, to the "ACTION_SCREEN_OFF" event, an acquiring the wake lock from there aswell, on the 'onCreate'method.
I'm using a Lenovo A60 with Android 2.3.5, and an LG Optimus Pro with Android 2.3.4.
At this time, there are two possible answers to this question:
If your cellphone is a part of this list (or one that still isn't, but has a similar underlying sensor implementation), then you can use the method described here to implement a workaround using BroadcastReceivers to restart sensor listening after the screen turns off;
You can use a wake-lock or another method to keep the screen on and
use a "press back twice to exit" schemes in order to safeguard the
user from closing the activity
I’m doing an application that listens to the android.intent.action.SCREEN_OFF in a Service (if that matter) and then it is supposed to wait a few seconds and launch an action, I’ve tried a timer schedule method, thread and handler postDelay method but all of them seems to fail, they are never executed on a device, it seems like it’s being freezed/killed after phone is locked. It works on emulator and on device attached to USB, but never with device working on battery only, which actually is a main scenario.
Do you know any solutions to this?
I cannot test this now (not near my Android device at the moment), but...
Does the broadcast receiver fire at all?
If so, right as you get called, you will need to grab a partial Wake Lock so the CPU stays awake until the timer fires.
chances are you have your phone set so that when it is plugged in, it never actually locks or sleeps (its one of the developer settings) and imagine the emulator behaves the same way. so you will either have to override the phone's lock settings or change your method. the general rule is that when the screen shuts off, your activity ends.
A partial wake lock keeps the CPU running, so you should acquire it inside your broadcast receiver for screen_off, and release it after you're done with whatever you're doing. When you're plugged into the USB, the CPU stays on to service the USB connection (in fact, the usb stuff in the kernel holds its own wake lock).
And to answer your other question, yes, even background threads. As soon as everyone is done handling the screen_off broadcast, the CPU is turned off, and you won't run again until someone turns the CPU back on.