Our mission
Smartphones are getting more and more powerful, but the battery capacity is lagging behind. Vendors are always trying to squeeze some battery saving features into the firmware with each new Android release.
But some go so far that they break useful apps just to artificially claim more battery life. This even gets so absurd that with some vendors (e.g. Nokia, Xiaomi, OnePlus, Samsung or Huawei) our smartphones are becoming dumbphones again.
Dumbphones are unable to do any useful tasks for you in the background unless you actively use your device at the time. This affects most of the apps that are not just another browser window. Most affected are alarm clocks, health trackers, automation apps, or simply anything that needs to do some job for you at a particular moment when you aren’t using your device.
With Android 6 (Marshmallow), Google has introduced Doze mode to base Android, in an attempt to unify battery saving across the various Android phones.
Unfortunately, vendors (e.g. Xiaomi, Huawei, OnePlus or even Samsung…) did not seem to catch that ball and they all have their own battery savers, usually very poorly written, saving battery only superficially, with side effects.
Naturally users blame developers for their apps failing to deliver. But the truth is developers do all they can. Always investigating new device specific hacks to keep their (your!) apps working. However in many cases they simply fall short, as vendors have full control over processes on your device.
This is the true aim of this site. To help set things right whenever possible. Communicate these issues with users and provide them with hacks, workarounds and guides to keep their apps working and making their lives easier.
The issues have been reported to Google on the Android Public Tracker:
- Chinese OEMs constantly violating Android compliance
- Request: Don’t let manufacturers to ruin how apps start themselves
Sources
The info on the site is gathered from multiple sources. The big part is from the experience of the Urbandroid Team, but increasingly info is added from FAQs of other developers, and from personal experience shared on the GitHub repo.
How we evaluate the negative score
We want to be maximally transparent about how we evaluate vendors and give them our negative score. So here it is.