android-studio

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.

With Figma’s new SVG Exports, less = more | Figma Blog (opens in new tab)

Figma redesigned its SVG exporter around a simple principle: producing less markup makes files easier for people and more compatible with other tools. Its older exports prioritized storing as much structural information as possible, but this created bloated SVGs that many importers—including Android Studio—handled poorly. The new exporter favors pragmatic, compact markup while preserving the visual result. ## Why SVGs Render Differently Across Tools - SVG describes instructions for drawing an image, unlike bitmap formats that store a fixed snapshot. - Although SVG is an open standard, there is no single standardized implementation for converting SVG markup into pixels. - Design tools and importers often support only subsets of the complex specification, sometimes with bugs. - Features such as reusable definitions in `<defs>` referenced through `<use>` are not reliably supported; Android Studio frequently failed to handle them. - Figma’s previous output was difficult to read and unnecessarily large, forcing users to run tools such as SVGO or manually clean up files. ## A More Pragmatic Export Strategy - Figma originally hoped SVG would become a universal interchange format between design tools. - Feedback from users led the team to abandon that idealized assumption and optimize instead for compatibility with real-world tools. - A simple rectangle example illustrates the change: - The old exporter generated deeply nested groups, clipping paths, masks, reusable definitions, and verbose path data. - The new exporter reduced the same design to a direct `<rect>` element with a fill and stroke. ## Using SVG Primitives - Simple shapes such as rectangles and circles are now exported using native SVG elements. - For example, a verbose rectangle path like: ```markup <path d="M0 100V0H100V100H0Z"/> ``` becomes: ```markup <rect width="100" height="100"/> ``` - Primitive elements are smaller, clearer, and more likely to be understood by other software. ## Simplifying Inside and Outside Strokes - SVG natively supports centered strokes, but design tools also need inside and outside stroke behavior. - Figma previously simulated these effects with doubled stroke widths plus masks, substantially increasing complexity and file size. - The new exporter adjusts path coordinates so the original stroke width produces the desired visual result. - This removes unnecessary masks and makes the resulting geometry easier to inspect and process. ## Removing Unnecessary Markup - Informational elements such as `<title>` and `<desc>`, grouping elements such as `<g>`, and attributes like `id` and `version` are omitted when they do not affect rendering. - Clipping paths are generated only when clipping is actually needed rather than for every clipped frame. - Figma also inlines elements that were previously deduplicated through `<use>` references in `<defs>`. - Although inlining sacrifices some deduplication, the simpler structure improves compatibility with limited SVG importers. Figma’s updated exporter demonstrates that SVG output should prioritize practical interoperability over preserving every possible piece of design-tool metadata. Simpler primitives, fewer masks and references, and only meaningful markup produce files that are smaller, easier to understand, and more broadly usable.