Match the artifact to the question
| Artifact | Suitable investigation |
|---|---|
| Complete Android project | Android Lint, build-aware checks and dependency resolution |
| APK or split APK set | Packaged manifest, code, resources and signing structures |
| Single Kotlin or Java snippet | Local patterns with limited surrounding context |
| Gradle declarations | Dependency intent, not necessarily the resolved graph |
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.
Investigate a permission present only in the release package
Suppose a source review finds no direct sensitive permission declaration, while an APK inspection reports one. Inspect the merged release manifest and dependency contributions before deciding which tool is wrong. A library manifest or product flavor can explain the difference. The source fragment and final binary answer related questions at different stages of the build.
The Android Lint guide describes build-aware analysis and variant selection. Run the appropriate task through the project's wrapper, then preserve its report with the commit and resolved tool versions. A snippet pasted into a website cannot supply all of that context.
Follow one warning to the reachable feature
For a flagged API call, identify its source set, module and callers. Determine whether the release includes it and whether the sensitive feature can reach it. A warning in a test fixture needs a different response from a warning on the production login path, but the conclusion should be supported by the build and code evidence.
After repairing the issue, rerun the same analysis and inspect the packaged artifact when the change affects resources, manifests or dependencies. If a new build still contains the old declaration, investigate merging or configuration rather than repeatedly editing the same source line.
Use a runtime test for the behavior that static evidence cannot establish. For an exported link handler, for example, the manifest reveals exposure while controlled requests reveal whether object authorization is enforced. Keep those observations distinct so the report does not claim that manifest inspection proved a backend rule.
When suppressing a false positive, preserve the exact rule, location and justification. A narrow suppression can express a deliberate exception; a project-wide disablement can hide future unrelated mistakes. Review the suppression when the affected implementation or dependency changes.
Track new findings separately from existing reviewed debt. This allows a team to improve a large project without either ignoring every warning or treating an unchanged historical warning as proof that a new fix failed. The release decision should use the current evidence and material unresolved issues.
Sources and further reading
- OWASP: Mobile Application Security Testing Guide
- Android Developers: Improve your code with lint checks
- Android Developers: apkanalyzer command-line reference
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
