Spectrum standardizes all Java code on the Android Open Source Project (AOSP) coding standards. Spotless runs automatically on every Gradle build and reformats source files to match these rules, so style is enforced regardless of who wrote the code. You rarely need to think about formatting manually — but understanding the conventions helps you write code that looks right before the formatter touches it.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/spectrum3847/2026-Spectrum/llms.txt
Use this file to discover all available pages before exploring further.
Spotless integration
Spotless is wired into the Gradle build so that running./gradlew build reformats any non-conforming files in place. If a file is changed by Spotless, the build reports a formatting diff and succeeds on the next run. You can also trigger formatting alone:
Be consistent
The most important rule is consistency. Before writing new code, spend a moment reading the surrounding code to understand its style. If the existing code spaces aroundif clauses, yours should too. If it uses a particular comment style, match it. Readers can focus on what the code does — not how it’s formatted — only when the style is uniform throughout.
“If the code that you add to a file looks drastically different from the existing code around it, it throws readers out of rhythm when they read it. Try to avoid this.” — AOSP Code Style
Capitalization conventions
| Identifier type | Convention | Examples |
|---|---|---|
| Classes and interfaces | CamelCase (first letter uppercase) | MyClass, MyInterface |
| Methods | camelCase (first letter lowercase) | calculateAverage(), getStudentName() |
| Variables | camelCase (first letter lowercase) | studentName, averageScore |
| True constants | ALL_CAPS_WITH_UNDERSCORES | Math.PI |
Acronyms
Treat acronyms as words and capitalize only the first letter. WriteHttpRequest, not HTTPRequest; write canId, not canID.
No prefixes on variable names
Do not add prefixes likem_ to denote member variables. If you encounter this pattern in the codebase, it is likely inherited from an external library or team and should be renamed to remove the prefix when you touch that code.
