Methodology
A Boundary-First Method for Reviewing an Android/F-Droid Submission
A practical, evidence-led method for reviewing an Android application submission without overstating what a limited audit can prove.
When I review an Android or F-Droid submission, I start by defining the boundary of the review. A short review can establish useful facts about a release, but it cannot honestly certify that an application is free of security issues. The purpose is to create a repeatable evidence trail: what was examined, what matched, what did not, and which areas remained outside scope.
The process begins with provenance. I record the source revision and declared release version, then compare the available release artifact with its stated signing identity where the evidence allows. I also review packaging and repository metadata so that the declared project identity, source location, and release references tell a consistent story.
| Review area | What I check | Why it matters |
|---|---|---|
| Source and release identity | Pinned revision, declared version, and visible release references | Keeps findings tied to a specific artifact rather than a moving target. |
| APK provenance | Available signing and package evidence | Helps identify whether a reviewed artifact is plausibly connected to the declared project. |
| Application surface | Permissions, exported components, WebView usage, and obvious network-facing behavior | Creates an initial map of where risk may exist. |
| Static evidence | Dependency, configuration, manifest, and build observations | Provides reproducible facts without pretending to replace runtime testing. |
| Delivery status | Public CI or merge-request status | Separates source observations from release-process evidence. |
For the TabGreater F-Droid submission, I used this approach to publish a compact evidence table covering source/release pinning, APK provenance, FOSS and network transparency, a WebView chart surface, Android component exposure, and visible pipeline status. Within that static/APK review boundary, I found no confirmed inclusion blocker or security vulnerability. That is not the same as declaring the app secure.
Runtime behavior, network traffic, a F-Droid-built APK comparison, native-library review, and a full third-party JavaScript assessment were outside the bounded review. Stating those exclusions makes a report more credible, not less useful: it tells maintainers exactly what evidence exists and what follow-up work would be required for stronger assurance.
A good lightweight audit does not claim certainty. It makes the available evidence easy to inspect, explains the limit of that evidence, and leaves a clear trail for future testing.