AICHE +

A

Android Studio Integration

The short answer: open Android Studio, position cursor in a KDoc comment or documentation file, press ⌃+⌥+R (Mac) or Ctrl+Alt+R (Windows/Linux), speak your documentation for 30-60 seconds, and AICHE inserts the text at your cursor.

Android development involves layers of configuration that all need explanation. XML layouts, Gradle build files, manifest declarations, ProGuard rules, Compose UI trees. The code itself is not the hard part. The hard part is leaving enough context for the next developer (or yourself in three months) to understand why the Gradle dependency has a specific version pin, why the layout uses a ConstraintLayout instead of a LinearLayout, or why the ViewModel handles that edge case differently on API level 28.

Voice helps because these explanations are conversational by nature. You know the reasons. You just skip writing them down because typing a paragraph in a KDoc block feels like it takes forever when you want to get back to building features.

1. Open Android Studio with your Android project.
2. Navigate to the file you want to document - Kotlin/Java source, build.gradle, or a markdown file.
3. Position cursor above a function, class, or composable. Type /** to start a KDoc block.
4. Press ⌃+⌥+R (Mac) or Ctrl+Alt+R (Windows/Linux) to start AICHE recording.
5. Speak your complete documentation: what the component does, its parameters, return value, lifecycle considerations, and any Android-specific concerns.
6. Press the hotkey again. AICHE transcribes and inserts the text.
7. Add KDoc tags (@param, @return, @throws, @sample) manually. Android Studio's autocomplete suggests tag names.

Heads-up: Android Studio is based on IntelliJ IDEA, so all JetBrains features work here. AICHE runs as a standalone desktop app, not a plugin. No Gradle sync required, no build.gradle dependency, no Android SDK interaction.

KDoc for Android APIs

Documenting Composables

Jetpack Compose composables benefit from clear documentation because their behavior depends on parameters, state, and composition context. Position cursor above a composable function, start a KDoc block, and dictate. Describe what the composable renders, what each parameter controls, how it responds to state changes, and what happens during recomposition.

For composables that accept lambdas (content slots, onClick handlers), explain what the caller should provide and what constraints exist. Say "the content lambda receives a ColumnScope, so child elements can use Modifier.align. The onClick lambda fires after the ripple animation completes and receives no arguments. If null, the entire component becomes non-clickable and removes the ripple."

ViewModel and Repository Documentation

Android's architecture components (ViewModel, Repository, UseCase) form the backbone of most apps. These are exactly the classes where documentation matters most, because they contain business logic that outlives any single UI implementation. Dictate what each public method does, what LiveData or StateFlow it updates, what threading guarantees it provides, and how it handles configuration changes and process death.

Play Store Listing Text

App Descriptions

Google Play Store listings need a short description (80 characters) and a full description (4000 characters). Writing marketing-style text is a different skill than writing code, and most developers struggle with it. Open a text file in Android Studio or your Play Store listing draft, press ⌃+⌥+R, and speak naturally about what your app does, who it is for, and what makes it useful.

Enable Message Ready in AICHE settings, and your conversational explanation gets formatted into polished, professional text suitable for a store listing. You can iterate quickly - dictate a version, read it, then re-record if the tone is not right.

Release Notes

Every app update should have meaningful release notes, not "bug fixes and performance improvements." Click into your release notes document, press the hotkey, and dictate what actually changed: new features, fixed bugs, improved performance in specific areas, and any breaking changes users should know about. Specific release notes build user trust and encourage updates.

Gradle and Configuration Documentation

Build Configuration Comments

Gradle build files accumulate configuration over time, and without comments, nobody remembers why a specific dependency has a version pin, why a particular build type disables minification, or what that custom task does. Open your build.gradle.kts, position cursor above a dependency block or configuration section, and dictate the reasoning.

Say "pinned to version 2.4.1 because 2.5.0 introduced a binary incompatibility with our custom serialization adapter. See issue tracker link for details. Safe to upgrade after the serialization module is migrated to the new API." That context saves someone an hour of investigation when they try to update dependencies.

Migration Guides

Android's ecosystem changes frequently - Kotlin synthetics to View Binding, View Binding to Compose, Java to Kotlin, Support Library to AndroidX. If your team is mid-migration, maintain a migration guide document. Dictate the current status, completed steps, remaining work, known issues, and the approach for each module. This document prevents duplicate effort and keeps the team aligned.

Android Studio-Specific Tips

• Logcat annotations. Keep a markdown scratch file open while debugging with Logcat. Dictate observations about log patterns, timing issues, and state transitions while the logs scroll in the adjacent panel.
• Emulator alongside dictation. Run the emulator in a separate window and dictate UI behavior observations into comments or documentation while interacting with your app. Describe what you see, what you expected, and what needs fixing.
• Layout Inspector notes. When using Layout Inspector to debug Compose or View hierarchies, dictate your findings. Describe which layouts are causing overdraw, which recompositions are unnecessary, and what the fix should be.
• Built-in terminal. Android Studio's terminal (Alt+F12) works with AICHE for adb commands, Gradle tasks, and git operations. Dictate commit messages without leaving the IDE.

The pro-tip: When documenting Android lifecycle methods, speak what happens in each callback and why. Explain which lifecycle events trigger your logic, what gets initialized or cleaned up, and how you handle configuration changes and process death. These are the details that prevent production crashes and save debugging time.

Result: KDoc comments with lifecycle considerations and threading notes. Play Store descriptions written in minutes instead of hours. Gradle configurations with explanatory comments that prevent "why is this here" questions. Migration guides that keep teams aligned during platform transitions.

Do this now: Open Android Studio, find one undocumented ViewModel or composable, type /** above it, press ⌃+⌥+R, and dictate complete documentation including Android-specific concerns like lifecycle, threading, and recomposition behavior.