Android Static Analysis: What the Binary Can and Cannot Tell You

Match the artifact to the question

A snippet checker cannot know every dependency, generated source file or runtime configuration. A binary analyzer cannot reconstruct all comments, build settings or original source intent.

Establish a build-aware baseline

For a project you own, start with the project's wrapper and the relevant lint task:

./gradlew :app:lintRelease

The exact task depends on modules and variants. Preserve the report, commit identifier and toolchain version. Android Lint checks Android-specific problems that a generic text scanner may miss.

Do not delete an existing lint baseline merely to make a build fail everywhere. Review new findings against the baseline, then reduce justified technical debt intentionally.

Triage findings with context

For each finding, identify the code or manifest location, the affected build variant, the potential impact and a reproducible check. A security-sensitive API in dead sample code is different from the same API on a production authentication path.

When suppressing a warning, prefer the narrowest scope and document why the warning does not apply. A project-wide suppression often hides future mistakes unrelated to the original case.

Combine source and binary checks

Inspect the built release to confirm that the intended manifest flags, resource exclusions and SDK changes actually shipped. Generated manifests and dependency merging can make the final package differ from the source fragment reviewed by a developer.

Know APKLint's role

APKLint's source and static-code tools provide focused heuristics and readable findings. They are useful for quick inspection, especially when the full project is unavailable. They are not equivalent to running Android Lint, a compiler, a full data-flow analyzer or the runtime tests described in the OWASP MASTG.