This issue I have may be only present on devices running Oreo or later as I have only a OnePlus 3T with me for development.
I have a foreground Service that is started using ContextCompat#startForegroundService() and in the service's startCommand method I make sure to create / enable my notification channel so that I can call startForeground with the associated on-going notification.
So I believe, in terms of requirements I get everything right here.
What does my Foreground Service do:
It acts as a Bluetooth Server using the Bluetooth Class RFCOMM BSPP to listen for client to connect ;
When a client connects, it listens for incoming requests ;
It performs the requests and send data accordingly.
My problem lies with the last point. When I connect and ask to send data, two things happen on the phone :
The relevant data is being loaded from the phone and
Once fully loaded, the data is sent to the client.
Each of these operations have their own notifications to display progress to the end-user.
While the first operation is not delayed, the second one may take many minutes (up to 6 in one of my tests).
After further tests, the cause is the notifications because I cancel the first operation notification then I call the second operation, which in turns will display and update its own notification.
So in the end, because I call NotificationManagerCompat.cancel on the first operation notification right before calling the second operation, that call can be delayed for a lot of time. If I don't cancel the notification first, then the second operation is immediately started.
As a solution, I believed that the Doze mode is responsible for that behavior, so I manually white-listed my app the battery optimisation settings of my phone. That did not change a single thing.
Finally, if, at any point, I unlock my phone / turn the screen on, the blocking / delaying notifications get's unlocked immediately and the second process starts right on the bat. So, of course, this behavior does not occur when my phone is plugged into my computer even with screen off.
Is this a bug ? Is this related to doze mode ? I do not know.
[Edit 1]
For better clarity, here is a code snippet that represents the sequence of operations:
loadData() {
... // defer heavy work on a worker thread and updates notification of progress from time to time (every 10%)
notifyDataLoadingStarted(); // on main thread. Displays its notification with progress bar
}
// once the data is fully loaded
onDataLoaded() { // called on the main thread
cancelDataLoadNotification(); // asks the notification manager compat to cancel notification
initiateDataSendingOperation(); // will also defer heavy work on a worker thread and update its notification accordingly
}
What happens is that onDataLoaded is called once the first operation is over. But the problem is that cancelDataLoadNotification is blocking. I am on the main thread and this methods returns very very lately. Hence, this is the reason why initiateDataSendingOperation is greatly delayed.
When I unlock my phone, I could see that the notification of the loading operation is stuck in the middle, as though the loading operation is halted, around 50%. However, this only lasts a fraction of a second because before I know it, the first notification pops out while the the second notification pops in. All in the blink of an eye. Which clearly means that yes, the first operation was indeed over since a long time ago, but its notification was definitely obsolete. And since the second operation would only be initiated when the first notification is cancelled, they you can clearly understand that the second operation is greatly delayed.
That's why my first workaround works if I first start the second operation before canceling the first operation notification.
Nevertheless, in any case, the notifications are still out of date while screen is off.
Related
The PeriodicTimeRequest has a minimum periodic time of 15 minutes. But I see, that for example Google Maps location sharing can update more frequently than that, and facebook messenger can also receive messages almost instantly.
I would like to send a notification to the user, when it got a new message. My application has to work on local network, so Firebase is not an option. I have to send a json request to the server, and if there is a new message, I show a notification to the user.
Regarding FCM:
FCM, which is available in all devices with Google Play takes the weight of subscribing to and receiving push events, under all the resource constraints Android has been ever introducing.
It's tightly coupled with the OS and is unified (one entity, one persistent connection for all apps in your device), which is why it works :)
Regarding Frequency of your Work:
Given your requirement of more frequent pings to the server, you'd need to have a service which runs all the time, i.e. A Foreground Service.
It is resource consuming though, so good luck convincing the user with a good reason why it should stay alive all the time.
I think you've managed to make the client-server interaction possible, since identifying a server in a local network is a huge task in itself.
use this in your service.
#Override
public int onStartCommand(Intent intent, int flags, int startId) {
CountDownTimer timer = new CountDownTimer(15 * 60 * 1000, 1000) {
#Override
public void onTick(long millisUntilFinished) {
// execute your task here, every sec
//if you want increase the count down interval from 1000 to what you want
}
#Override
public void onFinish() {
this.start();
// it will start again.
}
};
timer.start();
return START_STICKY;
}
I am afraid it is not going to be possible without using a set of workarounds. Which means you might not get a consistent behavior.
#Arvind has done a very good job explaining the benefits of a Firebase Service and it is the recommended approach for achieving such task.
First I'd like to point out that such restrictions on the WorkManager exist because Android has been suffering (between other things) of developers trying to abuse some mechanisms to get their software working and at the end of the day, the battery of the users had been suffering from such abuses and since Android 6 Google has started trying to address these issues. There's a good read for you over here about Doze mode and how to work with it
I am pointing this stuff out because I've been trying to build a chat service that wouldn't rely on Firebase and I really don't want you to waste as much time as me banging your head against a wall. There are things that you simply can't fight. That means that if the device enters in a "deep-sleep" mode sometimes you can only accept it.
My approach
Please
keep in mind the user interests and the life of their batteries and try to be as smooth as you can with their devices and this is just a workaround over the restrictions that have been imposed upon us. And that I discourage this approach due to the amount of work that it takes to pull off and for how misused it can be.
My solution
Essentially, to get notified (ie getting your code running) in an Android App you're going to be wanting to receive system events or Broadcasts. This is where you set up a BroadcastReceiver and you get Intents delivered to it and you can act upon them accordingly. BUT YOU HAVE TO BE QUICK BECAUSE YOU HAVE ONLY 10 SECONDS OF RUNTIME BEFORE THE OS KILLS THE PROCESS AGAIN. Ideally you would have a really quick server so you can have very little IO times to ensure you can be within 10 second restriction as frequently as possible.
So essentially you would be using a combination various of services that you would like to be monitoring in order to get notifications (aka Broadcasts) whenever the state of those changes. Here are a few ideas:
WiFi state (which will also be useful to see if you can reach your local server)
Bluetooth Low Energy packets (or Nearby which may solve the entirety of your problem depending on Nearby's capabilities)
WorkManager as you already pointed out.
AlarmManager to schedule a broadcast of intents every so often.
Geofencing (although it involves reading the user's location; you can set really small geofences around the office building and get notified by a Broadacast when users go through that geofence)
So whenever you receive a Broadcast of these sources you would handle such notifications from within the same BroadcastReceiver
From the implementation body of this Broadcast receiver you would poll the local network's server to check whether if your user has new messages or not and lift up a notification. And it's important to keep the amount of work and IO times the app has to do at a minimum since those add up and you've got only 10 seconds.
You can get around the 10 second mark if you launch a ForegroundService. Then, that period of time is going to be extended until a 10 minute mark and you will need a visible notification for the user stating something that you're checking if it's got any new messages.
Keep in mind
Don't stress the user's battery too much. Or Android will penalise your app and you'll end up notified less often or even completely not notified.
Be gentle with the user. If the user has to force-kill your app at some point it will stop receiving any sort of Broadcasts or running any sort of WorkTasks.
This solution can behave differently accross devices. Since the decisions of notifying your app are made by the OS, different OS (redmi, samsung, meizu...) you are likely to not end up with a consistent behavior across all devices
You don't have control over things, the OS does
Within measure, try to time your Broadcasts to your BroadcastReceiver within spans of 3 minutes or so; so you are always receiving a Broadcast below the 15 minute mark.
I have a service that runs periodically using a timer to invoke itself, but should not run when the screen is off. When the screen on event is fired, the service should run, but only if it's past when the timer would have fired.
Right now I still run the timer continually, but have the service do nothing if the screen is off. I can also run the service via a broadcast receiver when the screen turns on - but this runs the service every time the screen is turned on, instead of only when it's past when the timer should have run. Recording this state in the service doesn't seem to work as Android will kill the JVM for the app in between executions.
What would be the cleanest/correct way to implement this type of behavior?
So there are a couple of intents that you can listen for, Intent.ACTION_SCREEN_OFF and Intent.ACTION_SCREEN_ON. However, these don't work as manifest receivers, they need to be explicitly registered.
See this answer: https://stackoverflow.com/a/9478013/1306452
In all scenarios, it's going to involve a long running service in order to listen for those events.
One thing to keep in mind is that these intents only listen for when the device becomes non-interactive and vice versa, not specifically when the screen goes off (see the description on the Intents).
The best way for you to achieve this behaviour would be to listen for when these intents with a long lived service, started with START_STICKY to help guarantee that the service is running. The service can register a receiver for the SCREEN_ON and OFF events, and when it gets these events either do nothing if the timer has not elapsed, or continue if it has.
This won't be nice on your battery life, and what ever you are doing it doesn't sound like it's going to be a pleasent user experience. You might also want to step back and see if there's another way around this obstacle (my 2 cents).
I need my android application to stay alive for a short specific duration.
I have a long series of updates, during which I keep the screen alive with wake looks. After that is done, there is an dialog informing of the success. Before this one is posted however I've released the wake look. Here I want the application to have a wakelock for 30s and then release it even if the user dos not click ok on the dialog. This is because I dont want to drain the mobile.
Is there an easy way to do this? That is, once I've reached a certain stage in my code I want to have a wakelock for a short duration?
For any long running tasks you should use a service, and for your purpose a ForegroundService.
This comes with the requirement to have a notification visible while your service is running. You can then post a different notification once the process is complete.
This will make your processing resilient to the user stand-by'ing the phone, rotating the phone or going to another app, all of which would interrupt processing if originating in an activity.
http://developer.android.com/reference/android/app/Service.html#startForeground(int, android.app.Notification)
For ease of use, I usually override IntentService which has the least amount of boiler code required to get going.
I have created an Android service which basically does the following:
schedule a task, using the ScheduledThreadPoolExecutor.schedule() method
when the schedule time is reached, the task is executed and a new schedule is started
Thus, the service continuously has a timer in place (except during execution of the task); sometimes 2 (independent) timers are in place, depending on the result of the task. The service should be running all the time and executes different tasks from time to time.
All seems to work ok (at least when running with DDMS), but after a while (something like an hour without connecting the device via DDMS) the timer tasks are not executed anymore. The only way to get it working again is either stopping and starting the service again or by connecting the device with DDMS (using Eclipse); waking up the device only does not trigger this.
It looks like, Android sets the service in a kind of sleep mode (service is still running when looking at the Active Services on the device).
My question is: how do I prevent this behavior and keep the service working all the time?
I did some research and I found something which theoretically could give a solution, by acquiring a (PARTIAL_WAKE_LOCK) WakeLock in the service, but as far as I understand, using this solution, I have to acquire the lock at the onStartService() method and release it at onDestroy(), meaning that I keep the lock during the lifetime of the service (which is forever); I suspect a battery drainage using this method.
Is there another way to accomplish the same?
I have solved the problem, thanks to the replies above.
I switched from the ScheduledPoolThreaExecutor() to the AlarmManager. Together with the RTC_WAKEUP type all triggers are handled now.
I did not use the IntentService, because my service has to do things in parallel based on alarms (and IntentService implements a queued solution). The original service, which was staying alive all the time in the original implementation, is now only created whenever an alarm is triggered.
I also have the impression (but that is only a gut feeling, not based on real measurements, that this new implementation (where the service is created when needed and is not alive all the time (waiting on timer evens), is even better for battery life of the device.
How often to you need to execute, and what do you mean by running all the time? I guess that you don't mean be executing all the time?
I have a service that does this, and it works quite well:
It schedules an alarm with the alarm manager. Acquires a wakelock when the alarm is triggered, performs some work, and then schedules a new alarm before releasing the wake lock.
Use IntentService for your service implementation and register pending intents with AlarmManager to trigger those intents on the time basis you need.
I have used wake locks in an app before and I did not need to release them in the onDestroy(),
I literally had the following and it worked perfectly:
onClockListener{
acquire wakelock
method call
}
otherOnClickListener{
release wakelock
other method call
}
Not sure if it will help much but it definitely wont help if I don't post anything :)
I'm trying to write a simple app that should mute my mobile phone for a given time. It's my first Android app, but after many hours of reading I think it is nearly completed. But it still has one problem that I can not fix.
I'm using a activity to display the GUI. It has Buttons to set the start and end time, and everything else needed. When the user has entered all the parameters, they are passed to a service. This service uses a handler object, to register 2 callbacks (with Handler.postDelayed). One for start Mute and one for End Mute (in SetMuteIntervall).
The first tests seemed to work, but if I try to mute it for like 30 minutes, it never unmutes. I think it has something to do with the fact, that the mobilephone is or was in standby mode. I also tried to use Handler.postAt() but that didn't work either (and time relative to uptime was somewhat confusing).
So, what should I do to guarantee, that my callbacks are called, regardless whether the phone is in standby or not?
Here's the source of my program:
http://pastebin.com/XAgCeAq9
http://pastebin.com/33nepFV5
Try to use AlarmManager for planning some actions in future. AlarmManager is not standby-mode-dependend and will fire even if device is sleeping.
Your thread are actually stopped then the phone is in stand by mode. If you still want to use thread you can use WakeLock to prevent CPU from going to stand by mode (but still to switch screen off) but this is not the best way in your case.