jetpack-compose

2 posts

line

Android CLI for AI Agents: Applying It to Large-Scale Mobile Development Environments (opens in new tab)

LINE’s Android app is a large monorepo with hundreds of Gradle modules and developers, making unrestricted AI-agent searches expensive and unreliable. Generic tools such as `grep` and `glob` often return excessive, semantically weak results, causing agents to waste tokens and retry. The team therefore built thin wrappers, skills, and prompts around Android CLI to provide efficient documentation lookup and Android Studio’s semantic capabilities across multiple agents. ## Why Generic Search Breaks Down at Scale - Large repositories can return huge numbers of search results from a single request. - Search output consumes agent context and increases costs. - Text search cannot reliably answer semantic questions such as: - Where a symbol is declared or used - Whether a file contains IDE-detectable problems - Whether code is unused - As the number of modules grows, agents are more likely to rely on irrelevant results and repeat searches. ## Replacing MCP Documentation Search with Android CLI - The team first adopted Android CLI for official documentation search. - It provides current documentation for Android, Jetpack Compose, AndroidX, Firebase, and related technologies. - This helps reduce hallucinations caused by outdated pretrained knowledge. - Android CLI’s `docs` commands are exposed through the `get-android-dev-knowledge` skill: - `docs search` finds relevant documentation. - `docs fetch` retrieves the document body from its Knowledge Base URL. - Compared with the previous Google Cloud Knowledge MCP setup, Android CLI eliminates: - Per-developer Google Cloud authentication - An authentication proxy - Quota-management and workaround logic - The result is fresher documentation with fewer tokens and less supporting infrastructure. ## Bundling the Android CLI Binary The team stores the Android CLI binary in the repository and invokes it from a fixed path such as `.agents/tools/android-cli/android`. - **Consistent environments** - Developers, CI systems, and agent hosts use the same pinned version. - Installation differences in version, path, and platform are reduced. - **Security enforcement** - The wrapper automatically adds `--no-metrics`. - This prevents agents from accidentally omitting the company-required telemetry setting. - A fixed binary location makes reliable wrapper enforcement possible. - **Manageable repository cost** - Existing use of Git LFS makes storing the binary relatively inexpensive. ## Handling the Android CLI Metrics Bug - Android CLI 1.0 initializes metrics tracking before honoring `--no-metrics`. - It may still attempt to write under `~/.android/cli`. - In restricted sandboxes, this causes a multi-page Java stack trace, wasting agent context. - The wrapper now probes write access before invoking the CLI: - It creates `~/.android/cli`. - It attempts to create a temporary probe file. - If writing is blocked, it emits a concise, parseable error explaining the required permission. - This converts a noisy failure into an actionable one-line message. ## Android Studio Integration Android CLI 1.0 added integration with running Android Studio instances, enabling IDE-level semantic operations from the command line. - `studio check` - Verifies that Android Studio is running. - Confirms that the target project is open and indexing is complete. - `analyze-file` - Runs IDE inspections on a single file without a build. - Detects semantic issues such as unused code. - `find-declaration` - Locates symbol declarations in the project and inside `.aar` or `.jar` dependencies. - `find-usages` - Finds references to a symbol. - `render-compose-preview` - Renders Compose `@Preview` functions as PNG images. ## Wrapping Studio Features as Skills - The team does not expose raw Android CLI behavior directly to agents. - Each capability is wrapped in a lightweight script and presented as an agent skill. - The first skill created was `studio-check`. - This follows the same design used for documentation search and ensures failures are concise, predictable, and easier for agents to interpret. ## Practical Recommendation For large Android repositories, use Android CLI behind repository-pinned wrappers and agent skills rather than exposing generic search or raw CLI commands directly. Enforce security flags, validate filesystem prerequisites early, and prefer IDE-backed semantic operations when agents need declarations, usages, inspections, or Compose previews.

slack

Android VPAT journey (opens in new tab)

Slack’s Android VPAT review uncovered recurring accessibility issues after the company’s 2024 UI redesign. Slack addressed problems involving error announcements, headings, form labels, list counts, and workspace reordering through changes to UI components and TalkBack support. The review also showed that some vendor recommendations required interpretation against Android conventions, while keyboard navigation remains future work. ## Background and Triage - A VPAT documents how a product aligns with accessibility standards and helps customers evaluate software. - Slack commissioned a third-party VPAT in 2024 after its IA4 redesign. - Straightforward issues, such as poor color contrast and missing image labels, were assigned immediately. - The remaining Android findings were grouped into recurring themes: - Inaccessible error messages - Missing semantic headings - Unclear edit-field labels - Incorrect list item counts - Inaccessible workspace drag-and-drop - Strikethrough information not conveyed to screen readers - Errors communicated through color alone - Keyboard navigation and focus, which remain future work because Android’s large-form-factor support is limited ## Making Error Messages Accessible - Invalid form submissions displayed errors visually, but TalkBack did not announce them. - Slack addressed both primary error patterns: - `OutlinedTextField` now announces errors positioned below the field. - Error-type `SKBanner` components now announce their messages to screen-reader users. - Users can therefore understand both that a field is invalid and why it failed without swiping through the screen. ## Adding Semantic Headings - Missing headings made page structure difficult for screen-reader users to understand and navigate. - Slack added headings in lists, including the Preferences page. - The team did not classify top app-bar titles as headings because testing with other Android applications showed that this is not a consistent Android convention. ## Providing Persistent Edit-Field Context - Some fields relied only on placeholder text, which disappears after text is entered. - This can make the field’s purpose unclear, particularly for users with cognitive impairments. - The team explored difficult cases such as the main search field and message input area. - Because of space limitations, the message input received no ideal redesign. - Slack added a search icon to the search field, giving it a persistent visual cue even after the placeholder disappears. ## Correcting List Item Counts - TalkBack incorrectly counted decorative dividers as list items. - For example, a bottom sheet with five actual rows and two dividers was announced as containing seven items. - Slack introduced `SKListAccessibilityDelegate` for `SKListAdapter`. - The delegate overwrites accessibility `CollectionInfo` with the correct number of meaningful list items. ## Making Workspace Reordering Accessible - Dragging workspaces requires dexterity that some users may not have. - Slack added an explicit Edit mode with visible six-dot drag handles for each workspace. - TalkBack users can now use custom “Move before” and “Move after” actions from the accessibility context menu. - These actions are available through a three-finger tap or TalkBack gestures such as `L` and `r`. - A Done button exits Edit mode and removes the drag handles. Slack’s experience demonstrates that Android accessibility improvements often require both component-level fixes and alternative interaction models. Teams should validate screen-reader behavior directly, distinguish decorative elements from meaningful content, provide persistent context for inputs, and offer accessible alternatives to gesture- or dexterity-dependent interactions.