Accrescent supports Android 10, but its unattended updates need Android 12

Three releases in eighteen days, then ten months of commits with none

The project says one word about its own maturity: early alpha. The version numbers agree with that, sitting at 0.28 rather than crossing 1.0.

The release dates are the interesting part. Three releases came within eighteen days in late 2025: 0.27.0 on 2025-10-24, 0.28.0 on 2025-11-03 and 0.28.1 on 2025-11-10. Then nothing. The last push to the repository is dated 2026-09-28, roughly ten and a half months later.

So the pattern is a burst of shipping followed by a long silence in releases while commits continue. That is a meaningful distinction for anyone installing it, because the version number most people see is frozen at 0.28.1 while the default branch has moved through ten months of work.

Nothing in the README explains the gap. No note about a release process being paused, no statement that builds are distributed through a channel other than tagged releases, and no mention of a roadmap or an issue tracker where the current state of a release would be described. For a project whose central claim is about provenance and verifiability, the release history is the part a reader cannot verify from the page.

The translation platform, the build workflow badge and the code-quality badge all point at active maintenance, so the silence looks like a packaging decision rather than an abandoned project.

It supports Android 10 while one of its seven features needs Android 12

The feature list has seven items. Two of them are the differentiators and the rest are supporting claims, but one of the seven carries a platform qualifier that contradicts the stated support floor.

The feature is automatic, unprivileged, unattended updates, and the qualifier is Android 12 and later.

The support floor is stated separately: Accrescent currently runs on Android 10 and up.

So on Android 10 and 11, which the project claims to support, that feature does not exist. There is no automatic unattended update path on the oldest versions in range, and a user on those versions is relying on a manual update flow the feature list does not mention.

That is a narrow gap rather than a serious defect, and it is easy to read past, because the qualifier sits in parentheses at the end of a bullet. But it is the kind of detail worth knowing before you pick a store based on update behaviour, since the behaviour differs by the version of Android on the phone.

The other six features have no such qualifier: app signing key pinning, signed repository metadata, first-class support for split APKs, no remote APK signing, quality control on submitted apps, and no account requirement for installing.

Verification compares a hash against a website and a social account

The security story in this project is mostly a list of mechanisms, and the mechanism you are asked to check yourself is the signing certificate. The hash is printed in the README:

067a40c4193aad51ac87f9ddfdebb15e24a1850babfa4821c28c5c25c3fdc071

The instruction is to check it against the hashes on the project website and on its Twitter account in order to verify legitimacy.

So the trust chain is: install the app, read a hash out of it, and compare that hash against a string published on two web properties the project controls. That is a genuine improvement on trusting nothing, and it will catch the common case of a build that is not the one the project made. It is not a cryptographic proof of provenance, because the value you compare against is hosted on the same project's own site and social account rather than being signed into the artefact or chained to a release. If either of those properties is compromised, the comparison passes.

What is also worth noting is that nothing in the app records whether the check happened. The verification is a manual step performed once by a user who knows to look for it, which for a project whose pitch is that the chain is inspectable is a reasonable design and still a manual one.

A link definition survives for a sentence that is no longer there

At the bottom of the README there is a set of link definitions. Most are used. One is not.

The unused one points at Google's documentation for app signing, with the label Play App Signing. Nothing in the visible body text refers to it.

That is a small artefact and it tells you something specific. The feature list contains a negative claim, no remote APK signing, which is precisely the property that distinguishes this store from a hosted signing service. The natural way to make that claim land is to contrast it with the one most developers already know, and the link definition is the remains of a sentence that did exactly that. The claim survived; the sentence explaining it did not.

It is worth mentioning because it is the kind of evidence that a page is edited rather than written, and it sits next to two other small signals of the same thing. The screenshot section is laid out as four cells, for a home page, app details, the settings menu and a theme variant, and every one of those image cells is empty. The layout is preserved and the images are gone, which is what a screenshot migration looks like when the links break.

Neither fact affects the software. Both are visible in the first screenful a visitor sees.

The trademark section calls forks forbidden, in an Apache-2.0 repository

There is a trademark section, and it is the most assertive text in the README.

It states that the name and the logo are common law trademarks owned by the project, and that all other parties are forbidden from using the name and branding, as are derivatives. Derivatives are then defined, and the definition includes, but is not limited to, forks and unofficial builds.

Two things are worth separating. The core of it is ordinary: an open-source project asserting its own name is not up for general use, and that is what every trademark notice does, including this one, which is also why Apache-2.0 lets you fork while not letting you rename the fork as though it were the original.

The part that goes further is the word forbidden, and the explicit inclusion of forks in the definition of a derivative. Apache-2.0 grants you the right to fork and distribute the code under that licence. A trademark notice can withhold permission to use the mark; it cannot make the fork itself infringing, and the readme does not attempt to argue otherwise, but it does state the conclusion rather than the mechanism.

That is a legitimate choice for a project whose entire value proposition is that the build you are running is the build the project made. It is also a claim you should read before forking rather than after.

Per-file license annotations, a retired licence file, and a well-known directory

The repository root carries more licensing material than a project of this size normally does, and that is consistent with a pitch built on provenance.

There is a licence file, a directory of licence files for third-party material, a second licence file with an old suffix retained rather than deleted, and two individual files with licence sidecars next to them: one for an icon image and one for the dependency-automation configuration. That is the per-file annotation style used to prove, mechanically, that every file in a repository has a stated licence.

Keeping the retired licence rather than removing it is the correct choice for the same reason. A file that carried a different licence in an earlier commit still exists in the history, and pretending otherwise by deleting it breaks the chain.

There is also a directory at the root using the standard well-known name, which is the location web protocols reserve for site-level declarations such as domain verification or a security contact. Nothing on the README page explains what it contains, which is a small gap given how much of the project's argument rests on verifiable claims: the mechanism a user is told to verify against is the website, and the repository publishes a well-known directory that is not mentioned in the instructions.

The dependency automation file having its own licence sidecar, rather than being covered by a repository-wide rule, is the clearest sign that this is deliberate.

The quality badge measures new code, not the repository

Three badges sit at the top of the page, and each points somewhere different.

The build badge points at a continuous integration workflow, which is the ordinary thing and tells you a build runs on every change. The translation badge points at a hosted translation platform rather than at translation files in the repository, which means the translation workflow is outsourced to a service and the strings are not versioned here.

The third is a code-quality summary whose query is scoped to new code rather than to the repository as a whole. That is a meaningful distinction and a common one: a badge over new code reports on what has been written since the last quality baseline, so it can stay green on a repository with a poor overall history, and it goes red on a change that introduces a regression even if the total improves.

For a reader deciding whether to trust the code, the two numbers answer different questions and only one of them is shown. There is no overall figure anywhere on the page, and no badge for test coverage, which for a store whose pitch includes quality control on submitted apps is the metric a reader might most want to see.

The sponsors section is a short list of three, one of which is an organisation that publishes privacy audits. The README does not link to any audit or state a result, so there is nothing here to weigh, only a name.

Editorial conclusion

Accrescent is worth following if you want an Android store where the signing chain is inspectable rather than delegated, because the two claims that matter most, no remote APK signing and no account needed to install, are properties you can check rather than promises about intent. Four things to check. The maturity, because it describes itself as early alpha, its newest release is 0.28.1 dated 2025-11-10, and the repository has been committed to since, so what you can build from the branch is ahead of what most people are running. The platform floor, because it states it runs on Android 10 and up while the unattended unprivileged update path needs Android 12, so one of the seven headline features is simply absent on the oldest versions it claims to support. The verification story, because the signing hash is checked against a value published on a website and a social account rather than against something cryptographically chained to a release, which makes it a consistency check across three surfaces rather than a proof, and nothing in the app records whether you performed it. And the trademark position, because a repository under Apache-2.0 states that other parties are forbidden from using the name and that forks count as derivatives, which is a stronger claim than the licence itself grants and worth reading before you fork.

Frequently asked questions

Official sources

1. accrescent/accrescent on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases