dontkillmyapp.com catalogues the Android vendors that kill background apps

The problem behind the site: background apps killed by the manufacturer

dontkillmyapp.com is a complaint aimed at Android vendors. The README title is the whole thesis, Android vendors, don't kill my app, and the topic tags are android, dontkillmyapp and vendors. The project describes a category of behaviour in which a manufacturer restricts how long, or whether, a background application keeps running, and which then leaves app developers with behaviour that differs per device brand rather than per Android version.

The stated origin explains the shape of the project. The Urbandroid Team says every independent Android developer is at least partly affected by this issue, and that its own Sleep as Android app is affected heavily. It gathered information about hacks and workarounds, contacted individual indie developers to exchange what they had learned, and concluded that a shared libre software website would be a more effective way to pass the information on than private conversations.

So the output is a catalogue rather than a tool. Each vendor entry answers three questions in separate fields: what the vendor does, what a user can do about it, and what a developer can do about it. That split is the design decision worth noticing, because the same restriction has two different remedies, one in the phone settings and one in the application code, and a page that merged them would be useful to only one audience at a time.

One markdown file per vendor, with a front matter template

Adding or editing a vendor means creating or changing a single markdown file in the _vendor folder, and the README gives the front matter template to copy. The fields map directly onto the three content areas and onto the URL the vendor page gets. The front matter starts with the vendor name, sets layout to vendor, and gives the permalink the slug the page and the API use. The explanation, user_solution and developer_solution keys hold the three text blocks, in HTML or Markdown. The body of the file below the front matter is free text, and the sample body in the README is a joke line rather than anything a contributor has to write. The permalink is the relative path, which the API later exposes as the url field, and the layout value selects the page template for the site build.

Scores are added in the same way. To award a vendor, the contributor adds an award variable to the vendor file:

award: (int between 1 and 5)

The position value is what the site uses for ranking, and the API schema allows it to be null. What the README does not do is define the scale, and it says nothing about which end of the one to five range means a worse behaviour for developers. If that ordering matters to your use of the data, you have to read the site or the code, because the file format alone does not tell you.

The JSON API: one aggregate document or one file per vendor

The site publishes a JSON API for developers who want the data on their own site or inside their app, and there are two versions with different shapes. Version 1 returns every vendor in one document at https://dontkillmyapp.com/api/v1/output.json, with a vendors array whose objects carry name, manufacturer, url, award, position, explanation, user_solution and developer_solution. Version 2 splits the same object into one document per vendor, at a URL of the form https://dontkillmyapp.com/api/v2/[vendor].json, where the example given is nokia.json. The README points developers who need a per vendor URL at version 2.

The object schema is the same in both, and it starts like this in the version 2 document:

{
  "name": "Human-readable vendor name",
  "manufacturer": ["name","alias1","alias2"],
  "url": "/relative-url-to-vendor",
  "award": number or null,
  "position": number or null
}

Three fields are worth reading closely. The manufacturer field is an array of names and aliases rather than a single string, which is what makes the data usable for detection, since a device reports one of several spellings. The url field is relative, so a consumer has to resolve it against the site. And the three content fields, explanation, user_solution and developer_solution, hold JSON escaped HTML, so a client has to decode and render markup rather than read plain text.

The API carries conditions. The README asks that anyone using it get in touch by e-mail at [email protected] and give credit to dontkillmyapp.com. That is a request rather than a licence term, and the licence section sets the actual obligation for the site content, which is separate.

A static site with translations, a badge and a scores page

The repository layout shows how the site is assembled. There is a Gemfile and Gemfile.lock, a _config.yml, a _layouts folder, a _sass folder for styles, a _posts folder, a _data folder, a _plugins folder, a _vendors folder and a _vendors-content folder, plus a CNAME file, a 404.html page and an assets directory. Those are the conventional parts of a Jekyll site, and the.idea and.gitignore entries are the usual project noise.

Two things in that listing matter to a user of the data. The badge directory and badge_plain.svg indicate that the project ships a badge image. The other is output.json sitting at the repository root next to an api directory and an _api directory, which is the static file that the version 1 URL serves, with the version 2 files generated per vendor from the same source files.

Translation is handled by crowdin.yml, so the content is maintained in a translation platform rather than by hand, and about_score.md is a separate page about the scoring, which suggests the score has a described methodology even though the README does not reproduce it. The repository lists a Gemfile rather than a package.json, which matches a Ruby based static site generator even though the repository's primary language is listed as JavaScript.

Licence terms: attribution for content, a caveat on the source

The licence is split in a way that is worth reading carefully. The licence field in the repository metadata reads CC-BY-4.0, and the README states that the content, meaning the compiled site as it appears at www.dontkillmyapp.com, is licensed under the CC-BY licence, so it is free to be shared, adapted, and even used commercially, provided the original authors are mentioned, either as www.dontkillmyapp.com or as Urbandroid Team.

The source code is a separate case, and the README is unusually blunt about it: the source is open but not intended to be copied in its entirety. That is a statement of intent rather than a licence grant, and it sits alongside a content licence that is otherwise permissive. If you plan to reuse the site code, read the LICENCE file in the repository root before assuming the CC-BY terms extend to it.

For the API specifically, the practical requirement is attribution in whatever surface consumes the data, plus the e-mail notification the README asks for. Neither is a technical obstacle, but both are conditions the README attaches to use of the endpoint.

Where this project is the wrong tool

The first limitation is that the data is a snapshot of editorial work. Every vendor entry is a hand written markdown file, and the award value is an opinion expressed as a number. Nothing in the API measures a device or detects a vendor at runtime, so an app that treats the API as authoritative about current device behaviour is relying on a human maintaining a file. The vendor page may also describe behaviour that a later firmware update has changed, and the site has no versioning or timestamp in the schema to tell you when an entry was last revised.

The second limitation is that the source of the data is one site on one domain. There is no mirror, no published change log and no release history, since the repository has no GitHub releases. A project that depends on the endpoint at request time inherits that dependency, and a project that vendors a copy inherits the cost of keeping it current. The maintenance record supports that concern: the last push to the repository was on 2026-06-09, and the project has had no tagged release to pin against.

The third limitation is reputational rather than technical. The project is openly adversarial towards named manufacturers, awards them a score, and displays screenshots of specific device behaviour such as the Samsung battery pages in the repository root. That approach is the reason the catalogue is candid, and it also means the project can attract attention from the parties it criticises, which is a risk for a dependency you do not control.

The alternative: read the per-vendor workaround and implement it yourself

The site competes with two other approaches rather than with a single product. For a developer, the alternative is to detect the vendor yourself and implement the workaround in your own code, which is exactly what the developer_solution field of each entry is for. The difference in approach is between a maintained central table and per app engineering: the table gives you one lookup and a starting point across many vendors, while the per app route gives you control over the behaviour and no dependency, at the cost of repeating the work in every product you ship and keeping it current yourself. The manufacturer alias array in the schema is the part of the table that is genuinely hard to reproduce, because it encodes the spellings vendors report.

For a user, the alternative is to read the vendor's own documentation and settings, and the user_solution field exists to shortcut that. Here the difference is in effort and currency rather than function, and the site's advantage is that several people have already read the documentation and written down the path.

If your need is a general device capability check rather than a curated workaround list, the API is the wrong shape of tool, because it describes vendor policies, not API levels. The table is worth consulting when the question is specific, for example how one brand's background restriction works and what to tell a user about it, and it is not a substitute for reading the platform documentation when you need a guaranteed API contract.

Editorial conclusion

Adopt the API if you ship an Android app and need a maintained, machine readable list of vendor background restrictions and their workarounds, and accept that the data is a hand curated snapshot rather than a detection service. Do not adopt it as a runtime dependency on its own domain, and do not treat the award score as a technical measurement, since the README defines it only as an integer between 1 and 5. Verify first by fetching https://dontkillmyapp.com/api/v1/output.json and comparing the manufacturer aliases in it against the values your own code sends, then check the licence terms for the credit line the README asks for.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-4.0
3. README
4. urbandroid-team/dont-kill-my-app on GitHub