Sorry for bringing this up again, this issue is related to pull request #43. I think that pull request might be the wrong way to go about applying a license, especially as it leaves the maintainer with little choice of what type of license to use, and this particular pull request contains little explanation of its reasons for being created. However, in response to @Artaud's comment: "isn't no license better than any license if you don't care what will happen with your software?" - a license does not dictate "what will happen to your software", it details how other people should use it and who owns the copyright to its content. By default, your software is not "free for anyone to do what they want", but it is restricted by copyright laws which can then be waived or passed on to other people through the use of a license. With no license, the copyright is owned by Urbandroid and nobody else can legally use it for their purposes.

I would like to express the importance of having a license in this repository, or at the very least a text stating how this content can be used by people who do not hold the copyright (basically, anyone except Urbandroid). If you intend for this content to be useful for the community, an appropriate license is absolutely crucial as it allows developers to use, modify, and redistribute the content for / in their own projects without worrying about the legal burden or liability that comes with it. You can define your own terms of use, such as "make your modifications available under the same license" (a.k.a. copyleft) or "provide a link to our website with the content where it is displayed" as you wish, depending on the license chosen.

For this repository's content, I would recommend a creative commons license (the same as suggested in the pull request), as it is more suited to works that should be "public knowledge" rather than particular / subjective code.

Here are a few more resources that can help explain why a license is important, and how to choose one:

• "Why Add a License to your Open Source Project?" - Gareth Wilson, Glitch
• "Open source licensing: What every technologist should know" - Heather Meeker, opensource.com
• "Choosing an open source license" - Neil Chue Hong and Tim Parkinson, Software Sustainability Institute

Currently, this repository contains no license, the effects of which are detailed here. This means that nobody can copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. Some of the legal limitations and exceptions to copyright may apply here, but due to subjectivity and differing local laws surrounding copyright, they should not be relied upon to ensure that others can freely make use of the work that you and the community have done.

Hi Together,

I appreciate your awesome work. It drives me nuts that device manufactures doing all the different battery saver implementations without any transparency for us developers. We're often dealing with problems were our app will be closed, without any chance to get it to run. This often happens with Chinese manufactures like Huawei, Oppo, Nubia or ZTE.

Nevertheless I have a Nokia 6.1 with Android 9 running and this works like a charm with our app so I can't verify your score for this particular device/manufacturer.

We've disabled the battery optimization, using a foreground service and schedule alarms via AlarmManager's setAlarmClock method. With this setup we aren't experiencing force closing after 20 minutes or stopping of scheduled alarms.

On which circumstances and devices do you experience this problems?

I'm very long time Sony user and I'm not sure if the rating for Sony is justified. Stamina mode is turned on manually (or automatically on low battery if you set up itthat way), but upon enabling it clearly describes that it will break background process.
I cannot agree with ranking in-pair with Huawei or Meizu, where you are almost not able to prevent killing apps and phone is even not informing you about such policy. With Xperia line user is in control. You want background processes - you don't use stamina. You enable stamina - phone is alerting you: "are you sure? You will get some juice, but you will break apps in background. Do it wisely.". It's rather example to follow!

Slack created a page listing the steps for each manufacturer to make their app work. They focus on notifications, but some of the recommendation for certain manufacturer is very close of the steps described by the dont-kill-my-app project.

https://get.slack.help/hc/en-us/articles/360001562747-Known-issues-with-Android-notifications

I think we can use this information to update the current project

As Android developers, we have all had to fight against these issues one time or another. Now, there’s finally some project that curates resources related to this problem. Thanks a lot for this!

The current website (dontkillmyapp.com) is already perfect for developers. But for end users, the UX could be improved quite a bit.

We have all needed to give users step-by-step advice on how to make our app work on their devices again. We all need some link that we can share with our users to guide them on what to do. But the current website is not really useful for that. Here’s what would be necessary (in my opinion) to make this an awesome resource that can be shared with users (e.g. in customer support):

1. The lead copy (“We have to fight back!”) is targeted towards developers rather than end users. If the website accepted app-name as a parameter in the query string, you could turn the lead copy into something like this (if the parameter is not empty): “Due to some modifications made to your operating system by your device vendor, background tasks don’t work well for you with {app-name}. Here are some simple steps showing how you can easily fix this.”
2. After the vendor selection (which is perfect), the vendor’s details page should not include the “Story” for end users. It’s great for developers, but end users are not interested in this. They just want their problem solved and forget about this.
3. The “Solution for developers” should not appear on the vendor’s details page for end users, obviously.
4. “Solution for users” should be the only content on the vendor’s details page. But its different device-specific and version-specific pieces of advice should be hidden behind another level of navigation, one that asks for the user’s device.
5. Users generally don’t know their Android version. We have to ask for their device name. If you care about the whole market and want your app to succeed, you need to address the 85% of non-technical users for whom their device’s name is the only thing they know about their device, or who have never heard of “Android” – just “Nokia”.
6. Instead of displaying an item for “Stock Android”, we’d have to show separate items for popular devices with stock Android, such as the Pixel devices. Yes, 85% of users don’t know their Pixel device is what we call stock Android.
7. Screenshots are something that end users will appreciate a lot. If every step is accompanied by a screenshot, which is something that can definitely be done by us in the developer community, they will easily follow all steps and be more satisfied with our apps again.
8. The /?3 version should probably be the default for the link geared towards the needs of end users. But that wouldn’t necessarily require changes in the code. Developers could generate their links as /?3&app-name=My+app.
9. After all, internationalization would help a lot as well, of course.

Naturally, I would be willing to contribute if the determination to do this and the required infrastructure was there. Happy users means more success for our apps.

Thanks!

The "Solution for developers" section is great, but even better would be if that section had two sub-sections:

• How to detect
• How to workaround

I imagine that there might be some cases where it's possible to detect, but not workaround. And in that case we could simply show the user some info, like ”This app is being choked by your phone, here's how to fix it blah blah blah”.

I've found that there's only one way to deal with doze mode in the post-6.0 world if you need real-time push notifications, and that's to disable it completely. Turning off battery optimisation does not completely disable doze mode, and there is no option in Developer Options to turn it off either in 7.0+. However, the following works perfectly in a shell (as su) or in an init.rc startup script:

dumpsys deviceidle disable

No more doze. Obviously you lose any (questionable) battery saving advantages of doze, but you will get instantaneous push email notifications again (vital when using your phone for work). Would you mind listing it as an option for root users, please?

I notice it is possible to disable the com.evenwell.powersaving.g3.xxx app in settings. The instructions on this site do not mention it, but to me it seems like an easier medium-term fix? Is there a reason the instructions don't mention this? Just want to check before I make a pull request. Thanks!

I have a Nokia 5.1 and the Nokia 3.1 solution (DuraSpeed) solved it for me. I also disabled the evenwell power saving apps as shown in the Most Nokia phones section, I don't know if this is necessary or not, but it isn't sufficient.
After restarting my phone, I need to set the setting back to 1 and then 0 again. Setting just to 0 doesn't work, it seems that DuraSpeed only responds to changes in the setting variable, but doesn't read its initial value on startup.

The recommended way to run tasks in the background is with foreground services. I'd like a clarification if doing so would protect the app from getting killed?

If it does protect the app, wouldn't it make sense to add that to the Developer workaround section?

https://bitbucket.org/copluk/acr/issues/607

On the vendor list page, there are 5 pooper icons, but when you click on the vendor, it shows 10 icons (last 5 icons are always empty).

Is this intentional?

Surely it must be easy to compare to stock Android in the sense of AOSP, but that is not easy for consumers to grasp.

I would suggest some names, for example:

• Nexus
• Pixel
• Nextbit
• Essential
• Razer
• Android One (Xiaomi? any? Nokia probably messed that up)

Just to say - well done for this website! These vendors really stink like shit.

I have an ASUS phone and I would like to add it to the list. How can I get data to see what rating to give them?

I have Huawei P9 lite (Huawei VNS-L21), android 7.0, EMUI version 5.0.3.

Since a system update a couple of months ago, the solution described on this magnificent page no longer helps, SleepAsAndroid is getting killed after some time when the phone is not plugged in the charger.

I have not modified the webpage yet, maybe it is just something weird in my particular phone - or do we have more such reports from Huawei users?

Jan

I think you should add https://dontkillmyapp.com/ to the repo :)

Add those vendors from https://baviux.com/ladypillreminder/troubleshooting/
Permission already granted.

Great website and initiative! Way to go for this!

Do you think it might be a good idea to try and send this website/relevant section for each manufacturer, and get their words on the subject?

Hi, thanks for creating this site. It become a useful resources, where we can send to our customers, during customer support.

However, is it possible to replace the poop image with something more professional? (Like a battery drained icon?) So that we can apply these valuable info in a more professional way. (For customer support purpose, including it as part of FAQ, ...)

Thank you!

Not sure if this will always help, but there is one thing developers can sometimes do against the optimization it seems:

https://seap.samsung.com/api-references/android-standard/reference/android/app/enterprise/ApplicationPolicy.html#addPackageToBatteryOptimizationWhiteList(com.sec.enterprise.AppIdentity)

Should we add it?

in the https://dontkillmyapp.com/ the OnePlus entry does not appear anymore.
Instead there is a blank item at the right of General.

Hi, thanks for your project!
Since that state of app killers is likely to change, your repo is likely to change too.
Consequently, it'd be nice to have some semantic versioning available there so we can watch it with GitHub's new watch releases feature.

A paranoid user always exits from apps using the back button thinking that if the home button is used to exit apps, it keeps running in the background, draining the phone's battery. How true is this assumption?
The back button and the home button analogy has always been very confusing for Android because a lot of apps behave like they are in memory, even if the back button is pressed, for example Google Chrome and Microsoft Word/Excel/PowerPoint. On the other hand, many apps start up afresh after they have been exited using the back button. In this situation, what would be the best method for Android users to exit apps. so that they function properly, while not draining their phone's battery running unneccesary services?

This question needs to be addressed so that users, regardless of the phone manufacturer, are well informed when to kill an app and when not to, so that it can do its function properly.

Would it be possible to include apps like Avast Cleanup (https://play.google.com/store/apps/details?id=com.avast.android.cleaner), that kill other apps?

Some users may adjust their phone but app will be still killed by such a apps.

The Lenovo P2 has a very good battery life, but it's at a cost.

For an app to work in the "background" you have to enable the padlock icon at an app in the right top corner in the overview of running apps. It's actually then running as a foreground process. If you swipe it away, its background process will be killed mercilessly.

It does not matter if in settings -> apps, the battery/power optimization is on or not.

All being said, in general I recommend the phone nevertheless.

Hi,

I want to use the API like this:

• Retrieve the JSON
• Parse the vendors array for the manufacturer that is returned from https://developer.android.com/reference/android/os/Build.html#MANUFACTURER on my device.
  This does not work for example for NOKIA, as it returns HDM Global on my device
• Display the result (user solution escaped HTML in a webview)

My suggestion is: Add another key to the API for known manufacturer names. (value type: JSON Array)
That would make the search for the correct solution much more easier and would not need an update of the lookup process / redeployment upon manufacturer name changes.

Example:

{"vendors": [  
{
  "name": "Nokia",
  "manufacturer_names" : ["HMD Global", "The Android One fakers"],
  "url": "/nokia",
  "award": 5,
  "position": 1,
  "explanation": "...",
  "user_solution": "...",
  "developer_solution": "..."}]}

BTW: I really like this whole project. As Huawei Users account for 98% of the support volume, it was always a pain to tell users why the app does not work in the background and it is not my fault as a developer. To "bundle" all that information in one place is awesome! Thank you!

Added as an "issue" here (don't know an other method to submit suggestions here), but intended as information to help people to prevent problems due to crazy app killing behavior at some devices.
See https://forum.xda-developers.com/showpost.php?p=78588761&postcount=7

As, this site info is helpful for non English speaker. It is good if translator can participate to translate this site as well.

I can contribute to translate the info to simplified Chinese and traditional Chinese. I think the major obstacle is that, I don't know how to translate UI text, for respective device. (Unless we have access to those device)

http://nine-faq.9folders.com/categories/2758-troubleshooting

I’m not an Android developer myself, so I heard advice about using AlarmManager to keep the app alive and prevent it from killing the Foreground service. Do you think this advice is still relevant these days?

Mainly just for the sake of proving what is even possible in iOS compared to Android, because after seeing this site, there will obviously be comparisons.

Reference: https://developer.apple.com/library/archive/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html#//apple_ref/doc/uid/TP40007072-CH4-SW1

On Nokia 1, the package that should be disabled is com.evenwell.emm. Removing it seems to completely disable any battery/memory optimizations that Android might make, thus resulting in apps slowly filling the memory. Once enough memory has been filled, the kernel apparently kills or evicts the background processes.

Disabling the Battery Optimizations of an app in Settings keep the app memory resident forever. Manually swiping away the apps from the Recent Apps list when done with them seems to keep the phone running smoothly without any hitches.

Disabling Battery Optimizations of apps that are supppsed to run in background and manually closing any unused apps seems to be the best way of using this device for now.

"Advanced settings" and "Power Plan" don't seem to exist, I searched in the settings and in the security app and nothing showed, maybe you could add screenshots for the users to see

Consider changing Xiaomi Miui 10 Pie-edition from 3 to 4 thumbs down. Suggested or equivalent changes in Settings don't work reliably anymore. Also, the Settings-structure have changed with Miui 10 Pie-edition, so the suggested step-by-step guide doesn't apply anymore. Finally: point out that a Xiaomi-phones with Google Android One system installed (like Xiaomi A2 Lite) works much better and should be given a rating of only 2 thumbs down.

Recently HMD pushed 351F update (March 2019) for Nokia 6.1/6.1Plus/7.1/7Plus and disabled Power Saver G3 from system, although they didn't remove it.

Power Saver G3 was originally designed for handling Chinese bloatwares, such as WeChat, Alipay, Taobao, TikTok, Kuaishou, etc. China variant uses "Whitelist" policy instead of "Blacklist". For some reason, looks like they didn't realize Power Saver G3 is unnecessary for Global release until now. Power Saver G3 will always exist in China Variant Nokia Phones.

Following URLs are Full OTA for both Nokia 6.1 and Nokia 7 Plus Global, if you want to analyze:

https://android.googleapis.com/packages/ota-api/nokia_pl2sprout_plate200ww/3601a351ff7577ed5a013d6f4fe5fdd64d32355c.zip

https://android.googleapis.com/packages/ota-api/nokia_b2nsprout_onyx00ww/5255f45225061bdc1c3525a32cf7361480e45ea3.zip

If you want to know your current Firmware Build, you can either dial * # * #227 # * # * to check "Version" in BBox app, or use command "fastboot oem getversions" under Fastboot/Download mode if BBox app displays nothing.
Expected build version looks like this: B2N-351F-0-00WW-B04, which is stored at systeminfo partition or /proc/fver .

People in phone company do "Kill App" for a reason, a good reason.

I live in oz, and my phone is running just fine.

But once I get to asian countries and start use their local apps, there are hundreds of ads notifications popups(literally hundreds) every day. And all the app developers are into some sorts of competition that makes the app stay alive as much as possible and popup ads as much possible(directly contributing to their revenue). Phone is ringing almost every minute showing a notification from some app. Uninstall that app? No Way! Because in some places you can not going out without the paying/chat/map apps.

Forced me to turn back on the "disable background" function in my phone. And my life(and my phone) is so much better that way.

There is an additional (presumably power saving) strategy that none of the existing instructions address, AFAICT.

My Huawei Honor 8 running Oreo stops responding on the network a few minutes after the screen goes off. It does not disconnect/disassociate with the AP. When I turn the phone back on it does not re-associate and get a new DHCP lease. It just continues on from where it went to sleep with the same lease and association.

Indeed, while it is sleeping, there is network traffic from and to it (but only if it's originated from the device), so it really does still have networking up and running, it just does not respond to anything trying to reach it. It won't even respond to ARP requests or ICMP Echo Requests.

It of course does response to Google FCM push requests.

Perhaps this should be documented somewhere on your Huawei notes.

I have only done minimal research as of yet, but Oppo seems to be quite notorious for not allowing any services to run in the background when the screen is turned off, and I believe it would be a worthy addition to this site.

The only situation that I can personally point to is with the Oppo F1S, I encountered a user for which my app's background services were killed (including accessibility services, which needed re-enabling) every time they turned the screen off. So far, a workaround for this is:

• pinning the app to the recent apps screen
• enabling it in the app list inside the security app's "startup manager" and "floating app list" (com.coloros.safecenter / com.coloros.safecenter.permission.Permission)
• turn off battery optimizations
• give the service a persistent notification to remain in the foreground

All four of those needed to be done before the app would function. Here are links to some other resources verifying that some of the above steps work on other Oppo devices:

https://forum.xda-developers.com/android/general/coloros-5-0-how-to-allow-apps-running-t3847738
https://forum.xda-developers.com/find-X/help/killing-apps-screen-off-arghh-t3818105
https://oppo-au.custhelp.com/app/answers/detail/a_id/1313/~/how-to-lock-applications-in-the-background%3F
https://www.quora.com/How-do-you-add-apps-into-Whitelist-in-OPPO-F1s-phone

Hopefully I will have the time to contribute to this project more - I hope to start organizing my own records of background service-related problems on various devices sometime soon, and will gladly merge the information I find with this project if it is of use.

From a viewpoint of someone who just found your website, I think that the score representation you display using 👎 (thumbsdown) marks seems kinda unfair.
Particularly scores with 1 or 2 👎s.
Quoting score definitions from https://dontkillmyapp.com/about_score:

• "Services are killed only when user explicitly configure there phone to do so.."
• "Particular foreground services are killed only when user explicitly configure those services so."

Imho those two are quite positive descriptions and you make them seem negative. What would be a positive score according to you? Removing the ability to configure the phone in the other direction? Seems like a negative to me.

So yeah, I would suggest changing the score representation since it seems misleading at the moment.

I am using this great page to help users configure their device properly. Unfortunately, if you use Google Translate to translate the page, the landing page cards that redirects to instructions are not clickable.

Here is an example when translated to French:

https://translate.google.fr/translate?sl=auto&tl=fr&u=https%3A%2F%2Fdontkillmyapp.com%2F

It's no surprise Chinese phone vendors top the shit list (2nd-5th). China has very bad Android ecology. As Google Play Store is blocked in China, Android users and developers don't have a universal and controlled app store to fetch and deliver apps. Instead, every phone vendor build their own app store and their policy differs greatly with each other. The result is a state of utter chaos. For example, Google requires all new app on Play Store to target API 26, but no Chinese app store has this requirement. So users in China will always get the benefit of new API much later than users out of China. What is worse, lack of constraint results in all developers trying to get their app alive in the background so they can push ads to the users whenever they want. This is not a matter of simply consuming more battery, all these apps will compete for more RAM and CPU, soon my phone will become lagged and lose response like a brick. A brickphone is more useless than a dumbphone. You say "Naturally users blame developers for their apps failing to deliver". This is true. But what is more naturally in China is that users blame phone vendors when their phone lose reponse because of these heavily resource consuming apps. So Chinese phone vendors have to take strict policy to control background behaviours. Any vendor who don't have strict background constraint will lose their market share. This results in the collateral damage to the apps that are not so heavily resource consuming and just do their expected jobs quietly in the background. This is just a weighting of cons and pros, and the market has made its choice. This is, most users want phones with strict background control policy. From a user's perspective, we must presume that all apps are evil. This is just what the phone vendors did. They strictly restrict the background behaviour of all third-party apps by default, while give users the option to whitelist certain apps. If developers try to workaround the restrictions, the phone vendors will update their system to cripple these workarounds. I think what the developers should do is teaching their users how to whitelist their apps, instead of trying to workaround the restrictions.

The closest in app settings I can see is "Akun säästäminen" (Battery saving), but it's already stopped. When I try to use adb, I receive:

FRT:/ $  pm uninstall --user 0 com.evenwell.powersaving.g3
Failure [not installed for 0]

Attempting to look for similar packages, I find

FRT:/ $ pm list packages|grep com.evenwell.powersaving
package:com.evenwell.powersaving.g3.overlay.base.s600ww

However I don't know if this is the package I should remove and am a bit afraid of removing it by myself, so I am still googling for com.evenwell.powersaving.g3.overlay.base.s600ww. Nokia 1 is an Android Go device which may be the reason for different package assuming the page has been written with Android One or their customized Android in mind.

8 minutes later:

pm list packages|grep com.evenwell.battery
package:com.evenwell.batteryprotect.overlay.base.s600ww
package:com.evenwell.batteryprotect

So far these packages are listed as something requiring more testing, but Robert Wallis at Medium says to have removed them without problems, but their phone doesn't seem to be Android Go.

As per title. Maybe this should be mentioned.

On Samsung's Android Pie, battery saving settings are organized a bit differently.
There seem to be even more of it, in different places, for even more confusion.

Hi all,

As an Urbandroid, Sleep as Android (I also have a Sleep phaser 🙂) and OnePlus user I'd like to note that I've never had any problems with Sleep as Android function, at least since the OnePlus 6. I believe the problems with OxygenOS's battery interference came from three things:

1. Problems with OxygenOS's 'Deep Optimization' function being turned on by default in the past, which turns normal battery optimization into super crazy block everything 'optimization'. This feature has gone by the names Enhanced optimization and Advanced optimisation in the past. I think this feature is now disabled by default
2. Problems with OyxgenOS moving apps back to 'Battery Optimized' automatically without warning (bug?)
3. The 'App Auto-Launch' problem previously mentioned.

As far as I'm aware, all these problems are fixed/resolved on the latest OnePlus firmware. At the very least I've had no problem with any of the OxygenOS firmware versions on the OnePlus 6. I'd greatly appreciate other OnePlus users feedback on whether number 1. was actually causing their problems with OnePlus battery optimization.

Good day sir. I am a graphic designer and i am interested in designing a logo for your good project. I will be doing it as a gift for free. I just need your permission first before I begin my design. Hoping for your positive feedback. Thanks

Here:
https://issuetracker.google.com/issues/122098785

It talks a lot about the issues that (mainly Chinese) manufacturers cause...

I have a US Nokia 3.1 that upgraded to Android 9 several weeks ago. HMD had reigned in their task killer on the 8.1 upgrade, but here we are on 9 and (sigh) it's back. Uninstalling com.evenwell.powersaving.g3 seemed to make no difference. Actually, I located all evenwell packages with pm list package -e | grep evenwell and disabled them with pm disable-user, and while my apps survive for a little longer now, they still get killed.

I'm thinking about rolling back to 8.1, but before I do, I was wondering what I can do to identify the task killer and how it works. (I'm thinking it may be a kernel or memory management tunable and not just a system app.) Obviously, the best-case scenario would be finding a workaround so I can stay on P.

Each vendor should have an easily embeddable badge in the form of an img at /vendor/badge

Resource: https://stackoverflow.com/questions/10721884/render-html-to-an-image