Android Modularization

When To Use

• Use this skill when the request is about: android module split, feature modularization in android, break cyclic module dependency.
• Primary outcome: Design Android repositories with feature, core, and build-logic modules that scale without cyclic dependencies.
• Reach for this skill when the problem is dependency direction, API ownership, or feature/data/core boundaries, not task-level build speed tuning.
• Handoff skills when the scope expands:
• android-gradle-build-logic
• android-architecture-clean

Workflow

1. Map the current module graph first: app, feature, data, core, build-logic, and any dynamic-feature or test-only modules.
2. Identify which direction is wrong: feature-to-feature coupling, framework leakage into domain/data, API surface too wide, or duplicated shared code with unclear ownership.
3. Split by ownership and change rate, not by abstract theory; create the smallest module boundary that removes the current coupling problem.
4. Keep api vs implementation, public surface area, and test fixture ownership explicit so the new boundary stays stable.
5. Hand off build-speed or plugin-architecture issues only after the module graph itself is coherent.