Ah, ok, no worries then, here I thought they didn't care about engineering quality or tooling that works just recently, but turns out they never did! Thanks :)
Back when I cared about Android development, Google was famous for releasing stable builds of Android Studio/Android Gradle Plugin, that always broke on day 1, regardless of how many preview and candidate builds predated it.
The company with hiring processes for the creme de la creme among developers.
I honestly have no idea what is going on. Lots of broken things in what's supposed to be front products for Google and other "high name" brands. I don't get it: Where is everybody? Is there no one there? Are these companies really dead inside?
It's (at least partially) the layoffs. I've noticed significant degradation in the external-facing administrative layer at these companies. I recently did some work for a company that was trying to partner with Meta's e-commerce platform and even though there was a ton of documentation on how to integrate, etc. the human approval and planning piece of the project was completely dysfunctional on their side.
MS showing "view summary" button for all meetings, then doing bait-and-switch to tell you to buy Copilot license (on a corporate seat no less, where regular users don't have purchasing decision power) is top annoyance now
>Google collects usage data for the Android CLI, such as commands, sub-commands, and flags used. This data does not include custom parameters or identifiable information. This information helps improve the tool and is collected in accordance with Google's Privacy Policy.
> How would Google have enough data about a brand new product without collecting that data?
They wouldn't. But on the other hand, they probably have a large amount of in-house Android app developers on whom they can conduct such metrics collection. I wouldn't expect outsiders to have vastly different workflows, because when you get out of the happy path with Android all you get is pain.
Outsiders probably do have vastly different workflows. Google internally love to stick Bazel on everything and that's quite different (and overly complicated) compared to the usual Gradle route.
You could export BASH_ENV to have Bash processes source a given file at startup.
Zsh has .zshenv, and Fish just has config.fish for everything with the ability to guard certain things within it to login only or non-interactive only.
Everything I do for macOS/iOS is already without Xcode but it's a pain in the ass to keep up with changes, and there are things I haven't figured out yet (like AUv3).
Wow. Thanks for this update. It streamlined a lot of tasks.
Apart from this, next step will be to add suport for building android apps on the android phones itself. No desktop needed.Building on the laptop with agents and installing the build in the phone and testing doea not seem AI native. If everything can run on my android phone, development cycle will speed up.
android docs is the superpower we need for everything. NPM / pnpm should have similar npm docs that would allow humans and agents to search for type-signatures and JSDocs.
It is so annoying that each agent has its own ideas where it tries to get the docs, usually by blindly grepping.
Let's see if even mid/big companies with tons of resources, with AI and the right tooling will continue to write webview-apps or, even worse, use some kind of multi target wrapper.
This is a good step forward, but keep in mind the claimed gains are about "project and environment setup", not the tasks you deal with on a daily basis in an existing project.
CLI in a product name now means LLM agent TUI specifically and not just, as I would have expected, any kind of Command Line Interface? And usually there is barely a CLI included at all and you are expected to mostly launch the full TUI with its own embedded readline-loop rather that use the CLI?
This is great. We also need a tool to expose source jars to agents so they don’t need to compress. There’s a lot of Compose overloads that Claude just guesses at. I built something internally but it needs polish and Claude really struggled with the deep Gradle integration.
Efficiency claim: 70% less token usage, 3x faster task completion in internal testing. Even if that's marketing-inflated, the structured CLI commands replace a lot of trial-and-error. Gonna try it.
Is there Live Edit support? I've literally left an agent running to automate the use of Android Studio out of my workflow when I just want to iterate on UI.
I expected something useful for application development. All it offers is some wrapper around the basic Android setup command that LLMs are already good at. What, initial empty project creation now takes 5 minutes instead of 10? Big deal, who cares?
I had another hope awakening that at least skills might be useful. But except for a few migration recipes, there's nothing of value for day to day Android development.
Facit: I'll skip installing another Google app whose only purpose is more spying on me and keep developing Android apps the way I already do.
great! now let me know when your official app store transparently alerts users when an app they were using was sold to a third-party adtech surveillance company, please :)
138 comments
curl -fsSL https://dl.google.com/android/cli/latest/windows_x86_64/inst... | bashThe URL shown for individual OSs work, but the script errors for me.
curl.exe -fsSL https://dl.google.com/android/cli/latest/windows_x86_64/inst... -o "%TEMP%\i.cmd" && "%TEMP%\i.cmd"I manually downloaded the exe, but it say socket error. vibe coding is going strong!
The company with hiring processes for the creme de la creme among developers.
Maybe it's a size thing.
> Your agents perform best when they have a lightweight, programmatic interface to interact with the Android SDK and development environment.
F you google. Me too. Why didn't we get a sane way to build android apps before you had to please chatbots?
>Google collects usage data for the Android CLI, such as commands, sub-commands, and flags used. This data does not include custom parameters or identifiable information. This information helps improve the tool and is collected in accordance with Google's Privacy Policy.
>https://policies.google.com/privacy
>Disable Android CLI metrics collection by using the --no-metrics flag.
No thanks, is there no env variable for this? Doesn't Google have enough data already?
How would Google have enough data about a brand new product without collecting that data?
> How would Google have enough data about a brand new product without collecting that data?
They wouldn't. But on the other hand, they probably have a large amount of in-house Android app developers on whom they can conduct such metrics collection. I wouldn't expect outsiders to have vastly different workflows, because when you get out of the happy path with Android all you get is pain.
alias android-cli='android-cli --no-metrics'exec command android-cliwould work I believeZsh has .zshenv, and Fish just has config.fish for everything with the ability to guard certain things within it to login only or non-interactive only.
> enough data
No such thing.
Everything I do for macOS/iOS is already without Xcode but it's a pain in the ass to keep up with changes, and there are things I haven't figured out yet (like AUv3).
> Everything I do for macOS/iOS is already without Xcode
Doesn't Xcode allow you to plug in agents like VS Code does?
What I'm interested is in the CLI tool for my own use, not necessarily for agents.
So far I’ve been shipping internal apps without it! Even notarizing works :)
Apparently Audio Units v3 is only available with Xcode, which is why I’m only doing v2.
Apart from this, next step will be to add suport for building android apps on the android phones itself. No desktop needed.Building on the laptop with agents and installing the build in the phone and testing doea not seem AI native. If everything can run on my android phone, development cycle will speed up.
android docsis the superpower we need for everything. NPM / pnpm should have similarnpm docsthat would allow humans and agents to search for type-signatures and JSDocs.It is so annoying that each agent has its own ideas where it tries to get the docs, usually by blindly grepping.
> 3x faster
Because the real bottleneck is really the velocity of development, right next to keeping the codebase small - right guys?
Is there any step by step process or guidance on it?
I expected something useful for application development. All it offers is some wrapper around the basic Android setup command that LLMs are already good at. What, initial empty project creation now takes 5 minutes instead of 10? Big deal, who cares?
I had another hope awakening that at least skills might be useful. But except for a few migration recipes, there's nothing of value for day to day Android development.
Facit: I'll skip installing another Google app whose only purpose is more spying on me and keep developing Android apps the way I already do.
TLDR: Nothing to see here. Move on.