Android CLI: Build Android apps 3x faster using any agent
android-developers.googleblog.com
android-developers.googleblog.com
`curl -fsSL https://dl.google.com/android/cli/latest/windows_x86_64/inst... | bash`
The 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.
<pre>
> android skills list
Picked up JAVA_TOOL_OPTIONS: -Djava.net.useSystemProxies=true
</pre>
Maybe it's a size thing.
F you google. Me too. Why didn't we get a sane way to build android apps before you had to please chatbots?
>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?
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.
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.
mkdir -p ~/.local/bin
printf '#!/usr/bin/env sh\nexec android-cli --no-metrics "$@"' > ~/.local/bin/android-cli
echo 'PATH="$HOME/.local/bin:$PATH"' >> ~/.zshenv alias ls='ls --color=auto'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).
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.
Is it possible for 100% of situations? I don't know, because I haven't tried 100% of the situations. And in one case I haven't figured out yet (AUv3).
You obviously still need to use signing pipeline etc, but that can all be done via CLI.
As for "non-trivial", here are Chrome's build instructions for macOS: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/m...
Which contains the words "While using Xcode is unsupported" :)
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.
My major issue last time was providing the feedback to the agent by running the apk on phone i.e, pass the debug log from the apk back to agent so it can iterate on it without me providing any input.
I use 'just' (command runner) and the 'gh' CLI to automate this:
# Build and publish a GitHub release
release: apk
VERSION="v$(date +'%Y.%m.%d')-$(git rev-parse --short HEAD)"; \
APK="build/app/outputs/flutter-apk/app-release.apk"; \
REPO="$(git config --get remote.origin.url | sed -E 's#.*github.com[:/](.*)\.git#\1#')"; \
echo "Releasing $VERSION to $REPO"; \
git tag "$VERSION" 2>/dev/null || true; \
git push origin "$VERSION"; \
gh release create "$VERSION" "$APK" \
--repo "$REPO" \
--title "$VERSION" \
--notes "Automated release for $VERSION" \
|| gh release upload "$VERSION" "$APK" --repo "$REPO" --clobberIDEs are (were? :-/) a very personal choice. Maybe I'm an AI but I would have loved a CLI-centric workflow. It would have kept options open.
Is Android Studio notably worse than IntelliJ? Cause I use that every day for work and I love it.
Not sure what that dude is going on about, noone sane wants VSCode over that.
And those of us that used NDK, had to wait until JetBrains came up with Clion, for Google to finally offer an alternative.
Apple, mostly in-house, Google, mostly out sourced to JetBrains.
It is so annoying that each agent has its own ideas where it tries to get the docs, usually by blindly grepping.
Because the real bottleneck is really the velocity of development, right next to keeping the codebase small - right guys?
On the positive side, they've decided to come down from "superintelligence", "superchanging workflows" and other bullshit to the actual feature - 3x speed of text generation. Which is not quite the problem that needed to be solved in software engineering, but as you said yourself...
And what makes you think that most scams involve fancy zero days/CVEs/hijacking the OS, and not simple social engineering?
You do not require a malicious apk to receive 2FA codes, or for the gullible user to read them aloud to the scammer. All phones come with an SMS and phone app.
You do not require a malicious apk to send transactions in banking apps (eg tricking people selling their product to send the money.)
You do not require a malicious apk to engage in a pig butchering scam, or to buy gift cards.
> There should be some explicit confirmation that the user knows what they are doing and they are not being scammed. It is long overdue.
I agree. Social engineering counters should have awareness raised by the governments. But blocking 3rd party apps for this is like using a cannon to shoot a mosquito. I'm not sure it makes the slightest of sense.
Malicious APKs are a real problem that exists. I work tangentially in this space.
> But blocking 3rd party apps for this is like using a cannon to shoot a mosquito.
I’d agree, if that was what was going to happen. But it isn’t. Google is not going to block 3rd party apps.
Very much agree. Here in India, one of the big telecos has now rolled out a system where if you're on a call with an unknown number, OTPs are not sent to the phone till the call ends. IMO systems like this (or ironically - using OEM installed on device AI as a MITM to stop a call when an OTP is heard) are very good ideas.
> Malicious APKs are a real problem that exists. I work tangentially in this space.
Not doubting it for a moment. I've myself installed an app (that in my defense I pretty much suspected to be malware) that was malware. Even a few weeks ago I helped someone remove a hidden app that was draining their battery like anything (idk doing what, crypto mining or something I guess?). Ofc this app had accessibility permissions and would close settings if you tried to uninstall it.
On the flip side, I've also been stopped by my own phone to give accessibility permissions... to TapTap (a FOSS app by legendary developer quinny98) [1].
I should probably add - here in India, UPI scams use(d?) to be very common, let alone "giving someone your OTP" scams. I personally know someone very close who's lost a good bit of money, purely via someone social engineering them to hand over OTPs.
Even today, scamsters call and threaten a "digital arrest" (whatever the fuck that is) to unsuspecting victims. Presumably many hand over their money.
I have absolutely nothing against technical solutions. But IMO social education to never install apps from outside the play store, combined with "Digital Arrest does not exist" ads that the Indian govt is already running, are significantly stronger and resistant to much more things (like I mentioned - pig butchering or gift card scams).
I would be very curious if you had stats for how much is lost to scams via social engineering, vs malware. I asked Gemini (I can share the chat link via some private method of communication if you're interested), and apparently per IC3, it's 13.7B USD for social engineering, vs 1.57B USD for malware. If you have better data, I'd be happy to know more.
> I’d agree, if that was what was going to happen. But it isn’t. Google is not going to block 3rd party apps.
Perhaps I'm a cynical guy (which is true!), but I see zero reason to give google the benefit of doubt when it comes to control. I understand you're perhaps a googler (or you work on the same side) - nothing against it at all. Hardening is 100% helpful.
But companies famously like to increase revenue, and do not care about users. Every app on the play store (and btw there are a ton of scammy ones - I know because I get their ads on Youtube :) nets google some money. There's nothing stopping google from going "Actually we decided to stop all apk installs as people get scammed by them" tomorrow?
There is no fundamental reason to believe them beyond trusting them at their word. And there are many reasons to not believe them, unfortunately.
IMO, the old adage holds true - beating tech is hard, beating humans (with a wrench ;) is easy. Aka, XKCD 538.
1. https://github.com/KieronQuinn/TapTap 2. https://xkcd.com/538/
A decent amount of this fraud is not solely malware or solely social engineering -- there's often elements of both -- where they fool the person into installing the malware which helps to further facilitate the scheme. And in these cases, urgency is often used as part of the SE vector. So I think a 24 waiting period and warning about scams is particularly a good idea to mitigate these issues.
The harder it is to install 3rd party apps, the less people will do it and therefore care about it. When few enough people care, it will be easy for Google to justify turning it off. e.g. "Only scammers/hackers use APK installs"
I can think of some easier things, for example popping up a dialog, pressing "install" and having my all actually be installed after that.
Is there any step by step process or guidance on it?
There's a link to a repo or you can use the CLI tool to init the skills
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.
...and once this goal is finally reached the programmer will breathe a sigh of relief and then promptly be fired since now the machine can do the job as well as they could.
Like you can make a cross-platform react native app with expo in a day without any AI (a proper app, not a boilerplate). Same with many web apps.
Shadcn with themes and components, tailwind, temporal workflows, etc etc. The complexity of making apps was solved years ago.
Things that make systems more understandable to the LLMs ... usually make things more understandable for humans as well. Usually.
The biggest issue I've found is that vibed up tooling tends to be pretty bad at having the right kind of "sense" for what makes good CLI UX. So you still have awkward argument structures or naming. Better than nothing though
The Programmers Brain book was my go to
http://www.robertames.com/blog.cgi/entries/the-unix-way-comm...
TLDR: standard list of long options <https://www.gnu.org/prep/standards/standards.html#Option-Tab...> and short options from -a to -z <http://www.catb.org/~esr/writings/taoup/html/ch10s05.html>.
Hopefully when petrol hits $10 a gallon in the next few months more of the world will think about banning cars from high density areas.
I lived real downtown in Tokyo and my street was like "1.5" lanes wide (if cars were coming in both directions one basically needs to pull over and stop). I could just walk in the middle of the street. There was no sidewalk. No street parking of course. Cars would drive down at 15km/h or whatever, and slow to a crawl if people were in the street.
Straight lines are efficient walking routes, and ... well... that might involve just crossing the street directly! Every layer of grade separation gets in the way of that.
End result of all of this is less pavement to maintain, slower drivers (-> safer!), good walking and cycling conditions, etc etc etc.
What's that you say? Drivers are a major and rich political force and they will block such decisions?
You can even make 2D games with Flutter with the help of Flame[0] but be wary that pixel art style games are a bit of a hassle due to some bugs in Flutter itself. Otherwise Flutter is a joy to use for its intended purpose: cross-platform apps.