I manually downloaded the exe, but it say socket error.
vibe coding is going strong!
throwa356262 1 days ago [-]
Goggles Android tooling has been like this forever, nothing to do with AI.
embedding-shape 20 hours ago [-]
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 :)
fabiensanglard 14 hours ago [-]
What error message did you get? Perhaps you ran it with PowerShell (this is a Cmd script)?
anabis 5 hours ago [-]
Tryed both. Copilot said it was wrongly utf16, but it was utf8 according to vscode.
anabis 24 hours ago [-]
I got a workaround a la GH Copilot:
<pre>
> android skills list
Picked up JAVA_TOOL_OPTIONS: -Djava.net.useSystemProxies=true
</pre>
csomar 21 hours ago [-]
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?
patates 16 hours ago [-]
Same for Microsoft. Redirects to the void, 5-level-deep sign-in prompts, "contact your administrator" who doesn't exist...
Maybe it's a size thing.
anabis 5 hours ago [-]
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
CodingJeebus 16 hours ago [-]
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.
DaSHacka 19 hours ago [-]
[flagged]
sunaookami 1 days ago [-]
>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.
>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?
gowld 1 days ago [-]
Android CLI can write a tool that wraps android-cli and automatically passes the flag based on an env variable.
How would Google have enough data about a brand new product without collecting that data?
tredre3 1 days ago [-]
> 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.
Onavo 16 hours ago [-]
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.
I'm pretty sure this will just call itself in a loop. You need to use the absolute path to the wrapped binary to distinguish it from the wrapper.
oblio 21 hours ago [-]
Also it's not a binary :-)
figmert 16 hours ago [-]
Aah! Yes absolutely right! Using `exec command android-cli` would work I believe
panzi 13 hours ago [-]
Nope. I have this alias (a default on my distribution) and it's no loop:
alias ls='ls --color=auto'
yorwba 12 hours ago [-]
Creating an alias is not the same as putting an executable in your $PATH.
EdwardDiego 1 days ago [-]
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.
whstl 1 days ago [-]
I wish the same thing existed for Apple.
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).
netdevphoenix 20 hours ago [-]
> Everything I do for macOS/iOS is already without Xcode
Doesn't Xcode allow you to plug in agents like VS Code does?
whstl 20 hours ago [-]
I don't know, I don't use/want to use Xcode.
What I'm interested is in the CLI tool for my own use, not necessarily for agents.
generalpf 16 hours ago [-]
Come on now, you're going to need Xcode at some point during development.
whstl 15 hours ago [-]
Hopefully not!
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.
groby_b 16 hours ago [-]
No, you really don't. Apple would like you to use it (god knows why), but it's not necessary.
brailsafe 12 hours ago [-]
I feel like this needs a big asterisk. Can you ship a a non-trivial iOS or Mac app that uses SwiftUI or other first-party APIs without Xcode? Is it practical? Those are real questions, some cursory searching did not turn up a concrete answer.
generalpf 16 hours ago [-]
It does.
srslyTrying2hlp 1 days ago [-]
[dead]
hemc4 1 days ago [-]
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.
xstas1 1 days ago [-]
you already could! just install Termux, npm install your favourite agent harness (pi for one has explicit Termux support, but its AGENTS.md works just fine with Claude Code for example - https://github.com/badlogic/pi-mono/blob/main/packages/codin...), and say you want an android app. It problem solves for a bit, then spits out an apk out to your Downloads folder.
hemc4 1 days ago [-]
Let me try this. Last year this was a dream. Can't belive we are so close to automate all of this.
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.
fragmede 24 hours ago [-]
ask the agent to run adb log so it can read it for itself
xstas1 1 days ago [-]
Also coding agents will happily compile android applications (of maximum complexity) via Github Actions where you can just pick them up with Obtainium. No PC needed
laxisOp 21 hours ago [-]
What is obtainium.
intuxikated 20 hours ago [-]
An android app that tracks releases to install the latest versions of apps directly from github.
aquariusDue 18 hours ago [-]
Also it works with private repos too if you provide a personal access token (fine-grained) in the Obtainium app settings. Just make sure to "release" (on the Releases tab) the .apk file on the GitHub repo and tag it latest.
I use 'just' (command runner) and the 'gh' CLI to automate this:
Android Studio on its deathbed. Just release VSCode plugin and kill it for good, it has been a buggy, slow mess for the last 3 years or so.
Steltek 16 hours ago [-]
I can't be the only one with a severe aversion to language/platform specific IDEs. "Oh no, you can't write Python in Vim, you need to get Pycharm!" "iOS apps? Don't try anything except XCode."
IDEs 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.
netdevphoenix 20 hours ago [-]
If you think Android Studio has been a bug in the last 3 years, you haven't used it back in the days of Android Studio Beta. It has come a long way.
belimawr 17 hours ago [-]
Must be a web dev who adamantly uses VSCode for everything
hbn 9 hours ago [-]
I haven't touched Android dev in the better part of a decade.
Is Android Studio notably worse than IntelliJ? Cause I use that every day for work and I love it.
barrkel 22 hours ago [-]
Do you still use IDEs?
I haven't used an IDE since December.
codebolt 22 hours ago [-]
Debugging and local testing is the main remaining use case of IDEs. Especially so for mobile apps where you need to manage one or more emulators.
wiseowise 21 hours ago [-]
Not on Android, where debugger works once in a blue moon.
rvillberg 1 days ago [-]
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.
anabis 1 days ago [-]
Taking screenshots, optionally with component borders highlighted, and operating the UI with element names like "button1" instead of tap 200,30 looks useful. If I could get it to work.
noahz-google 9 hours ago [-]
hey! I'm the dude workin' on that + the `layout` command to try to make device interaction via CLI less painful. please do throw your gripes and complaints/suggestions at me; I'd like to make it work well/intuitively for folks.
anabis 5 hours ago [-]
Thx.
In other comment, but setting Java options for proxy settings worked.
I was guessing annotations would be based on UI framework borders(which I can toggle on screen via debug menu), but looks it's based on image recognition locally. Maybe you can have UI component borders as option(haven't heavily used it yet, so throwing around ideas)
Ciantic 20 hours ago [-]
`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.
hansmayer 21 hours ago [-]
> 3x faster
Because the real bottleneck is really the velocity of development, right next to keeping the codebase small - right guys?
overfeed 20 hours ago [-]
Code-generation velocity, and the absolute number of lines churned are 2 metrics AI tools can irrefutably benchmaxx, so the vendors highlight them.
hansmayer 20 hours ago [-]
Oh absolutely - the old saying about only having a hammer and seeing each problem as a nail applies.
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...
antirez 1 days ago [-]
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.
1313ed01 19 hours ago [-]
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?
jezzamon 18 hours ago [-]
This is a CLI, the example shows the Gemini TUI using it
iririririr 1 days ago [-]
> 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?
bitpush 1 days ago [-]
Damned if you do. Damned if you dont.
wiseowise 23 hours ago [-]
Google has been neglecting Android for years with subpar tooling and ridiculous development practices.
cageface 21 hours ago [-]
If you think Android tooling is subpar wait until you try iOS.
wiseowise 21 hours ago [-]
Apple deliberately makes them shitty, big difference.
stavros 1 days ago [-]
Damned if you don't, damned if you do fifteen years later for an entirely different reason.
mixedCase 8 hours ago [-]
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.
jadar 1 days ago [-]
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.
sailingcode 18 hours ago [-]
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.
mridulmalpani 1 days ago [-]
How can I use this official android skill with Claude code?
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
Evidlo 1 days ago [-]
Now please let us install the apps just as easily
stronglikedan 1 days ago [-]
downloading an APK and opening it is already about as easy as it gets. the only thing easier would be for someone else to do it for you
throwaway81523 1 days ago [-]
You're forgetting the installation ("sideloading", what everyone else calls installation) restrictions they are about to deploy. It will be a significant hassle to install anything without Google's approval. Many F-droid apps are showing warning notices about this upcoming change.
kube-system 1 days ago [-]
Good, it shouldn't be two clicks for elderly people to install trojans on their phone that then drain their bank account. There should be some explicit confirmation that the user knows what they are doing and they are not being scammed. It is long overdue.
user_7832 22 hours ago [-]
> Good, it shouldn't be two clicks for elderly people to install trojans on their phone that then drain their bank account.
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.
kube-system 17 hours ago [-]
We can and should address more than one problem at a time.
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.
user_7832 16 hours ago [-]
> We can and should address more than one problem at a time.
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.
I am not a Googler and I am not fond of Google, but I don't have any reason to think that the changes they have proposed are some elaborate fabrication.
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.
Evidlo 12 hours ago [-]
I guess we'll see in 5 years how well these comments will age. I can easily see a future where 3rd party apps are not allowed anymore.
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"
LtWorf 1 days ago [-]
It is 1 click because the malware is on the play store already!
kube-system 1 days ago [-]
Both are problematic.
darkwater 23 hours ago [-]
Think of the elders!
kube-system 8 hours ago [-]
Telephones are a public utility that need to be accessible for everyone in society.
stavros 1 days ago [-]
"This APK cannot be scanned and its safety cannot be verified. Learn more/go back" and "learn more" has a link that looks like nothing but is actually a button to actually install the app.
I can think of some easier things, for example popping up a dialog, pressing "install" and having my all actually be installed after that.
TeMPOraL 1 days ago [-]
You're saying it should look like those damned browser certificate failure sites, with option to open the damn site hidden under button that looks like an unassuming link?
stavros 22 hours ago [-]
That's how it looks now.
Natfan 21 hours ago [-]
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 :)
OutOfHere 1 days ago [-]
But can I publish an app without having to share my ID? I want an ecosystem that doesn't require it.
binkHN 1 days ago [-]
It's not just your ID; it's your address, phone number, and the list goes on.
Flavius 1 days ago [-]
Absolutely not. That would be crazy.
nout 1 days ago [-]
Zapstore or Obtanium...
digitalShield 13 hours ago [-]
not bad
17 hours ago [-]
miroljub 21 hours ago [-]
I must say I'm quite disappointed.
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.
DeathArrow 1 days ago [-]
Can we have a web development CLI with web development skills?
user2722 1 days ago [-]
Agents will allow human programmers to get what they've been begging for decades now: proper requirements and flexible, logical, tooling.
rtpg 1 days ago [-]
this has been my sort of big tent alignment with AI people. If I'm getting good CLI tooling that _actually works_ (or fixes to existing ones that have been busted forever) then I'm pretty happy.
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
phyzix5761 1 days ago [-]
Its like major cities repairing their roads to incentivize autonomous vehicles to operate there. Win win for everyone.
noosphr 1 days ago [-]
Apart from pedestrians.
phyzix5761 1 days ago [-]
It never made sense to me why cars and pedestrians need to share the same spaces. Why can't we have more efficient walking routes that are away from cars?
noosphr 23 hours ago [-]
Because cars took over the streets from pedestrians between 1900 and 1930 and no one noticed.
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.
phyzix5761 23 hours ago [-]
Its already over $12 per gallon in Singapore. Let's see what happens.
rtpg 23 hours ago [-]
if you have roads shared with pedestrians and cars (and bikes!) you can build denser cities.
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.
oblio 21 hours ago [-]
Yes, we can do that by banning leisure cars trips from all dense areas.
What's that you say? Drivers are a major and rich political force and they will block such decisions?
whattheheckheck 1 days ago [-]
Any textbooks or resources on getting better at naming things?
The conclusion I drew from that book is that I shouldn't be naming things.
volume_tech 1 days ago [-]
[dead]
jadbox 1 days ago [-]
I've been thinking the same thing lately. It's sorta frustrating that it required bots to force tech companies to make clean simple cli driven development workflows.
qingcharles 1 days ago [-]
It's wild that it took AI to get half the companies on the planet to actually add reasonably priced APIs to their products so I don't have to puppeteer every damn thing with a flakey harness.
bayarearefugee 1 days ago [-]
> Agents will allow human programmers to get what they've been begging for decades now: proper requirements and flexible, logical, tooling.
...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.
risyachka 1 days ago [-]
The tooling in 2026 is so easy you can do almost anything without AI very very quickly.
oblio 21 hours ago [-]
What tooling?
risyachka 20 hours ago [-]
Frontend, backend, workflow engines, payments, idk all of it.
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.
oblio 17 hours ago [-]
We must live in different worlds. Even for professionals building high quality apps is hard. It's easier with AI, but it's still quite hard. And it was definitely harder without AI.
fragmede 1 days ago [-]
At the expense of no longer needing the human programmer...
canarias_mate 11 hours ago [-]
[dead]
hyhmrright 1 days ago [-]
[dead]
kevinten10 1 days ago [-]
[dead]
kdhaskjdhadjk 1 days ago [-]
[flagged]
rafram 1 days ago [-]
What does this have to do with the Android CLI?
kdhaskjdhadjk 1 days ago [-]
[flagged]
AnimalMuppet 1 days ago [-]
Since rafram is not the only one confused, yes, you really do.
rvz 1 days ago [-]
It isn't that hard to understand:
> Just wait until there are entire classes of vulnerabilities related to LLM usage
This is a valid concern.
There are going to be a new class of vulnerabilities which an LLM is involved which are going to be discovered and it will make it possible to cause catastrophic damage to a company; very easily.
This won't be surprising since we have companies building casual remote code execution tools for "agents" waiting to be hijacked.
AnimalMuppet 1 days ago [-]
I understand that. What about that relates specifically to the Android CLI? That was rafram's question, and mine, and as far as I can tell still hasn't been answered.
I mean, I guess if you're going to say "don't use LLMs", then you also don't want to let agents use the Android CLI, but it seems like raising an awfully general concern in a discussion about a very specific article.
kdhaskjdhadjk 1 days ago [-]
[dead]
1 days ago [-]
vlapec 1 days ago [-]
That probably depends on how good 2026-era LLMs already are. But I hope you’re right, and that pre-AI devs will still make a real difference.
kdhaskjdhadjk 1 days ago [-]
[flagged]
winrid 1 days ago [-]
Catching up to Flutter.
wiseowise 23 hours ago [-]
Not even close. Flutter has been engineered from the ground up with excellent tooling, unlike Android’s mess of organically evolved crap held together by a duct tape.
aquariusDue 18 hours ago [-]
Yeah, I've been using Flutter since December last year and I'm really amazed how good the developer experience is. I kinda regret not picking it up sooner but from what I understand now's a great time too with the roadmap they've planned for this year (videos on YouTube explaining Flutter concepts and decoupling Material and Cupertino).
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.
`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!
<pre>
> android skills list
Picked up JAVA_TOOL_OPTIONS: -Djava.net.useSystemProxies=true
</pre>
Maybe it's a size thing.
>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.
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.
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:
IDEs 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.
I haven't used an IDE since December.
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...
F you google. Me too. Why didn't we get a sane way to build android apps before you had to please chatbots?
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
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.
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.
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
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?
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>.
...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.
> Just wait until there are entire classes of vulnerabilities related to LLM usage
This is a valid concern.
There are going to be a new class of vulnerabilities which an LLM is involved which are going to be discovered and it will make it possible to cause catastrophic damage to a company; very easily.
This won't be surprising since we have companies building casual remote code execution tools for "agents" waiting to be hijacked.
I mean, I guess if you're going to say "don't use LLMs", then you also don't want to let agents use the Android CLI, but it seems like raising an awfully general concern in a discussion about a very specific article.
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.
[0] https://flame-engine.org/