I am creating application that has endless ForegroundService for new android versions.
Problem is that ForegroundService always dies after some time no matter what.
Tried to do Battery optimization, Wake lock, creating new process for service, even creating JobScheduler that checks if Service still working, but that one also stops working after some time.
Tried to follow Google samples, Stackoverflow solutions and many others, nothing seems to work.
I also made some research on my banking app and some other apps that relies on services for notifying the user or tracking some activities, they also not working flawlessly like old times.
At the end I figure out that for some Vendor phones doing some extra setting Vendor specific setting helps, this link one of many examples to understand Slack Known issues with Android .
After this reading, I don't think that simple user should go somewhere in to deep phone setting to make app that he likes to work... In fact I think it is the worst practice....
Made some conclusion after researching that because of saving few battery percents Google and poorly made Vendors battery saving strategies on top making phones dump and not reliable....
Also these background restrictions making not possible to develop awesome pocket portable device features...
I mean I agree with ForegroundService idea for long running task instead of simple Service in background that might be malware, spying or whatever that user does know nothing about it. Also agree that User is notified about high power usage, but randomly killing everything is same as killing the idea of smart device.
Please tell me that I am wrong about everything and give me a solution :)
I'm currently working on an app for this kind of device:
link. I want the user to be able to set a timer to shutdown and boot (NOT reboot) at a specific time during the week.
I did a lot of researches but I have't found the answer to my question. Everybody says that's impossible to boot using a timer since the device is supposed to be off. However, in the settings of the device, there is an option "Timer Switch Machine" which allow to do that (as describe in the link above). So I think there is a way to hack this functionality throw my app, if the device is rooted. But I don't know how to do that.
Does anyone have an idea?
This functionality is not part of the AOSP. That means first you have to gain access to the source code (or alternatively talk to someone who has access to it).
You might be able to find the corresponding code by decompiling System apps (especially the app which contains the option).
Otherwise you'd have to find a contact to the developer (probably via the manufacturer).
If you have the sources, the easiest way to hook into it is normally using xposed.
But depending on the actual implementation (e.g. if it's a shell call) there might be a better way.
I'm planning to deploy an app on my android smartphone which is supposed to be used by multiple other persons. Now of course I do not want them to do things with the device they are not supposed to do so I informed myself about several different ways to make it as safe as possible (Lock-down apps, Kiosk mode, Mobile-device-management, Code-tweaks and so on).
I found some solutions that look really promising but they all share the same problem that a user could just restart the device and boot it in safe-mode where those helpful apps won't be started. However, there is one exception: I've installed a MDM app called maas360 which somehow manages to apply the restrictions that I defined even in safe-mode, for example by blocking access to the menu settings. How is that even possible? The thing is just that this is not a free app and it offers a huge variety of functions - overall it seems to be a bit excessive for my goals.
So my general question would be: is it somehow possible to restrict access to the safe-mode somehow? Maybe like a password? From what I understand it is not even possible to set a system password for Android devices that you'd have to enter once it boots (except if you set up a password for unlocking the screen first which would then be the same one... very redundant).
Disabling physical switch of volume down (in case of samsung devices) will stop access to safe mode on device. I dont find any other way to do so.
why cant android os be more like apple os on the the ituch/iphone? where the app doesn't run until it is selected. it is also closed; stays closed until it is opened again.
i think this would make the android phones run faster and more efficiently(battery would last longer).
A lot of Android apps (I think most of them) run exactly as you describe it - they have an activity that is closed or suspended as soon as you leave it - a suspended Activity only consumes memory and can be discarded in an instant. (iOS does nearly the same)
Even on the iPhone there are applications that run in the background, the most prominent example being Mobile Safari. The difference is that only Apple can write applications that run in the background without restriction, and that a regular user has no way of monitoring these background apps. (this has led to massive overcharging issues in the case of users leaving Mobile Safari on a page where streaming content was loaded.)
There are legitimate use cases where you need an app to continue running in the background (downloading, uploading, playing music, waiting for a VoIP call) - none of it was possible for a third-party to do it on the iPhone until iOS4, making applications such as Pandora or Skype nearly useless.
For good or ill, Apple consistently restricts what third-party developers are allowed to do on iOS devices (App Store policy, private APIs, specialized APIs for background tasks mentioned in point 3). On the other hand, Google seems to prefer that third-party Android developers have access to the same APIs as Google's Android app developers.
The biggest Android performance problem IMO is responsiveness, the fixing of which is a lot more involved than saying "no Apps in Background thx". (See http://android-developers.blogspot.com/2010/12/new-gingerbread-api-strictmode.html for more information)
An Android developer's blog explains the reasoning behind Android multitasking.
We did not want to require that users close applications when "done" with them.
Mobile devices … have fairly hard limits on memory use.
These competing constraints were a key motivation for Android's design.
The fact that you can see an application's process "running" does not mean the application is running or doing anything.
The articles linked from there also have interesting things to say on the subject
The RadioActive Yak:
When should your app include an exit button? The Short Answer: Never.
Wickenden:
One of the first things the naive but technically inquisitive new android user does is begin to wonder how all the things they are running should be “shut down”.
Google’s android system has been designed for multi-tasking in ways that allow programs to be ready to respond to a changed environmental condition instantly (an alarm to wake you, a notification that you have arrived at your destination and so forth) as well as actually “running” and consuming resources when needed. Additionally the android system itself is smart about how it deals with low memory conditions and is capable of completely blowing away applications in such a way that their state is remembered and can be restored when there is more memory.
Task Killers (whose behavior is radically clipped in Android 2.2 “Froyo”) actually can cause harm by destroying a process that other apps need to function correctly.
We are currently developing an Android app that is a fitness-tracker application. It runs constantly in the background, and it works fine on most devices, but we've been having issues with the application dying completely on some Samsung devices. After some investigation, it seems like some Samsung devices has a completely custom "App Optimisation" feature (http://forums.androidcentral.com/samsung-galaxy-s6/599408-app-optimisation-after-updating.html), which is basically a (very) primitive version of the Doze feature that exists in later versions of Android which basically just murders apps if they haven't been used for three days.
As this app is more or less only doing logging, and doesn't open the activity, it presents a big problem for us, because this feature is pre-enabled on many Samsung devices. The problem is solved by using a foreground service, but that is a sledgehammer of a solution that requires disturbing the user with a constant notification, and we really don't need the app to be in the foreground - we are fine with the normal power management of Android.
The Samsung App Optimisation feature clearly states that it will "optimise" apps if they have not been used for three days. Does anyone have insight in what Samsung considers to be "used" and can I somehow trigger that?
Side-rant: In my opinion, this is a badly implemented feature that makes development on Android more hostile. Besides our use case, it will any messenger applications break. If it were not for the fact that Facebook Messenger and Whatsapp are hard-wired to be exempt for the app, users would be going crazy because it would be breaking their experiences.
I've owned (and currently own) Samsung devices, so I know a little as to how it works from the user's point of view. The technical specifications and how it works on the inside is an entirely separate issue, and one I can't answer.
The system can detect if you open an app. Samsung uses that in their app optimization, and will save power on apps that haven't been used in over three days. It is a terrible system though.
It ignores background-processes that may be critical to apps, and even if it is an app you actively use, like a fitness tracker, it will have issues. To quote what it says inside the app optimization-list:
"To save battery power, apps that haven't been used for more than 3 days will be designated to save power. Apps designated to save power may not show notifications"
(Rough translation from Norwegian, originally taken from an S6 running Android 6)
Therefore, apps that have been manually, or automatically set (3 days of no use) may give various issues with background processes. But remember that the user can set any app to never save battery, and ignoring the automatic setting. So with this in mind, let's consider possible solutions.
There is one scenario where you do not need to worry about the app and app optimization: When app optimization is disabled entirely.
Looking aside that, there is really only two things you can do:
Ask users on Samsung to disable battery optimization for your app to prevent issues
As #MinaSamy suggested (in their now deleted answer), SyncAdapter and having a periodic synchronization. Note that I haven't tested this, so I don't know whether it works or not.
And there's also a third option, which really isn't a solution, but you can ignore it and gamble on app optimization being disabled, or just not care about it at all.
Does anyone have insight in what Samsung considers to be "used" and can I somehow trigger that?
As far as I know, unless Samsung added some safeguards against accidental opening or added some kind of minimum activity requirement, opening is enough. It appears to be a "stupid" feature, which runs on hard-coded rules rather than a dynamic system that actually detects app use and sets power saving relative to that. It's "easy to enable", but fortunately easy to disable as well.
Meaning you cannot trigger an event that will keep it alive (unless SyncAdapter does the trick)
And to make the facts clear, from #Neil's answer:
It does seem like the user can do this, so there must be some database or setting somewhere that controls it.
There kinda is. There are a total of four settings, three of which are app-specific, and it is stored in a database (or some other form of data storage). These four settings can be used, although extremely shallow, to alter the behavior of the app optimization:
Always optimize
Automatic optimization
Never optimize
Disable app optimization
The first three options are on a per-app basis, which means each app can have separate settings. Disabling app optimization is exactly what you'd expect: it disables the entire feature for all apps. If it's disabled entirely, nothing is optimized.
There's also a website listing ways of bypassing optimizations on a per-brand basis. The entry for Samsung is more or less what I've said: tell the user to manually disable optimization. There are no developer solutions.
In settings>device health>battery there's an option to "put unused apps to sleep". You can turn it off, or change the amount of time it takes, which is 3 days by default.
Sounds like that's your problem.
https://forums.androidcentral.com/samsung-galaxy-s10-s10-plus/964083-whats-disabling-some-my-apps-background.html
Is there a reason you can't add your service to the 'don't optimise' list?
It does seem like the user can do this, so there must be some database or setting somewhere that controls it.
Alternatively, if you detect you are installing on one of the devices, open the optimise activity page, and show a message saying "Don't optimise us!".
As a workaround, i implemented the SyncAdapter mechanism, using this link as a good starting point: https://github.com/bmeike/MiniSync
It doesn't work perfectly (for testing, in my app i write a log every 1h, and after 3 days, it starts not respecting this scheduling), but at least it doesn't stop after 3 days, without the need to put the app in ignored optimization mode.
UPDATE: After the update to android PIE, scheduling stopped again after 3 days.
On another device, same app with android Oreo, scheduling is working (even if not completely respected).
On Samsung phones, the culprit is this Sleep setting:
You have got to take your users to this system settings screen and ask them to turn the feature off.
In my opinion you should implement a 'Broadcast Receiver' that listens to a custom 'Intent' and this 'Intent' to be Broadcasted by the 'Service' from 'onDestroy()' method of the 'Service' because when the 'System' kill the 'Service' this method will be called definitely.
And when the 'Broadcast Receiver' receives the 'Intent' you should start the 'Service' again.
And to distinguish between you stopping the 'Service' or the 'System' stopping the 'Service' just use some 'booleans' stored in 'SharedPreferences' and then in the 'Broadcast Receiver' you decide whether to activate the 'Service' or not
we are fine with the normal power management of Android
Are you? From the Android docs
However, since the user is not directly aware of a background service, in that state it is considered a valid candidate to kill, and you should be prepared for this to happen. In particular, long-running services will be increasingly likely to kill and are guaranteed to be killed (and restarted if appropriate) if they remain started long enough.
Three days seems like it would fall under "long-running...guaranteed to be killed".
If the problem is not that your service is killed but that it isn't restarted, you could use the AlarmManager to regularly check the status of your service and restart, if necessary.