java-android-workflow

Java Android Workflow

Purpose

Preserve Java Android codebases and make Kotlin/Java boundaries explicit when Android modules are mixed-language.

The practical decision is whether to stay Java-only, add Kotlin interop carefully, or route implementation to Kotlin-first guidance without forcing a migration.

Source Check

Use repo-local Java, Kotlin, Gradle, and Android files first. Use Dash.app Java or Gradle docsets opportunistically for installed local reference. Use official documentation as authority for Android-specific APIs, Kotlin Java interop, AndroidX behavior, and version-sensitive rules:

• Android Developers documentation
• Java documentation
• Kotlin Java interoperability documentation
• AndroidX documentation
• Android build documentation

Translate documentation into concrete API, annotation, source-set, or validation choices.

Inspection Workflow

1. Inspect source ownership:
   • src/main/java
   • src/main/kotlin
   • generated sources
   • public Android library APIs
   • Java callers of Kotlin code and Kotlin callers of Java code
2. Identify interop boundaries:
   • nullability annotations
   • @JvmName, @JvmOverloads, @JvmStatic, @JvmField, or @Throws
   • SAM conversions and functional interfaces
   • checked exceptions and callback APIs
   • data classes, sealed classes, objects, companion objects, and generated bytecode as seen from Java
3. Preserve Java-only projects:
   • keep Java examples and implementation idiomatic for the existing codebase
   • do not add Kotlin plugin or Kotlin sources without user approval
   • keep AndroidX and Java language level aligned with repo configuration
4. Maintain mixed projects:
   • keep public APIs friendly from both languages when they already cross the boundary
   • use annotations for nullability and threading where the repo already does
   • keep generated binding, Room, Hilt, KSP, KAPT, or annotation processing behavior explicit
5. Validate:
   • compile or assemble the affected module
   • run unit tests that exercise the Java/Kotlin boundary
   • run lint when annotations, threading, lifecycle, resources, or Android APIs changed

Implementation Guidance

• Prefer Java implementation in Java-dominant Android modules.
• Prefer Kotlin implementation in Kotlin-dominant modules unless Java API compatibility owns the change.
• Keep Android callbacks, listeners, and lifecycle methods readable from the language that owns the file.
• Preserve binary and source compatibility for Android libraries unless the user approves a breaking change.
• Document migration decisions in repo-facing docs only when the task changes project policy.

Output Shape

Return:

1. Language owner: Java-only, Kotlin-first, mixed, or migration decision needed.
2. Interop boundary: APIs, annotations, generated code, callbacks, nullability, or bytecode concerns.
3. Affected modules: module, source set, public APIs, tests, and generated sources.
4. Validation path: exact Gradle commands.
5. Risk: migration, binary compatibility, annotation processing, nullability, or public API risk.

Guardrails

• Do not rewrite Java Android code to Kotlin just because Kotlin is preferred for new Android work.
• Do not add Kotlin to a Java-only project without an explicit user decision.
• Do not expose awkward Kotlin APIs to Java callers when public interop matters.
• Do not drop nullability, threading, or lifecycle annotations casually.
• Do not route backend Java services through this skill.