Java Code Review Checklist for Android: Lifecycles, Errors and Resources

Review the lifetime of each resource

Ask who owns a stream, cursor, listener, executor and context reference, and when it is released. Prefer structured cleanup such as try-with-resources for compatible resource types.

try (InputStream input = resolver.openInputStream(uri)) {
    if (input == null) {
        throw new IOException("The selected content is unavailable");
    }
    // Stream and validate bounded content here.
}

This fragment illustrates cleanup and a missing stream; it is not a complete import pipeline.

Check Android-specific failure paths

The memory guide, crash guidance and security recommendations provide platform context for these questions.

Reject silent catch-all handling

Catching Exception and continuing as though an operation succeeded can hide data loss. Handle expected failures with an explicit result, log redacted diagnostics and let programming defects remain discoverable through tests and monitoring.

Do not log tokens, full private documents or credentials just to make debugging easier.

Test state changes, not only the happy path

Rotate or recreate the screen, cancel the operation, revoke permission, remove connectivity and reopen the app after process loss. These tests reveal assumptions that ordinary unit tests may not exercise.

Use static checks as support

APKLint's code checker can point out suspicious patterns, but it cannot infer every lifecycle owner or execute the flow. A useful review comment names the failing state and expected behavior, then asks for a focused test—not merely a preferred style or design-pattern label.