I wonder what this means for all the schools that invested in Chromebooks.
There is a good chance the average end user wont even notice the difference. It seems doable, but I guess the devil is in the details. If they can't pull it off, Apple is rumored to be launching a ~$599 macboook. Would not be really stretch to see them complete in this space again in the future.
But one day they'll have to switch, when the support runs out. IIRC it's 7-10 years depending.
In like 2015 before all the OEMs lost interest when it turned out tablets didn't have phone-esque upgrade cycles maybe? Isn't the Android tablet market basically on life support from occasional Samsung refreshes at this stage?
They are all (AFAIK) based around android 9 or 10.
You are seriously almost better off just doing something like a windows tab converted to a linux machine.
That’s not what I see when I lookup tablets. My old cheap Samsung Tab S6 Lite (2022 version) has Android 14 with security patch from May 2025.
My SO bought a cheap Xiaomi tablet this month with Android 15 and patch from August 2025.
I dont think so, it's more active recent year. There are a lot of good Chinese tablet(from well known brand). Xiaomi, lenovo, vivo, oppo and oneplus all have "flagship" tablet(running high end CPU, with very good screen and build quality)
I think usually people that only see iPads around come from the few markets that are dominated by Apple.
https://gs.statcounter.com/vendor-market-share/tablet/europe
If you go world wide in another data set, it is around 54%
https://www.bankmycell.com/blog/global-tablet-market-share/
Even considering the more generous number, that makes half of the tablets being sold across the planet are not iPads.
If you unlock and you cannot run google wallet or your banking app, it's a closed box and the EU anti-monopoly lawsuit may still apply on this. But, if they can make a "trust" story run about LEA access to lawful decode or something, this might go away.
I'd say that the projections about fuschia and the like have turned out to be less interesting than some people hoped: but having two OS in the public eye (3 or more if you include Android TV and whatever closed systems run on Nest and Chromecast) was always a mistake.
I can live inside termux but there are things termux struggles to do, (like tcpdump maybe? and interacting simply with data downloaded from outside termux because of sandbox rules), which I very much would want.
I do not like how Android interacts with removable storage. It's an anti-pattern.
> (50) [...] In order to ensure that third-party software applications or software application stores do not endanger the integrity of the hardware or operating system provided by the gatekeeper, it should be possible for the gatekeeper concerned to implement proportionate technical or contractual measures to achieve that goal if the gatekeeper demonstrates that such measures are necessary and justified and that there are no less-restrictive means to safeguard the integrity of the hardware or operating system.
> (54) Gatekeepers can hamper the ability of end users to access online content and services, including software applications. Therefore, rules should be established to ensure that the rights of end users to access an open internet are not compromised by the conduct of gatekeepers. Gatekeepers can also technically limit the ability of end users to effectively switch between different undertakings providing internet access service, in particular through their control over hardware or operating systems. This distorts the level playing field for internet access services and ultimately harms end users. It should therefore be ensured that gatekeepers do not unduly restrict end users in choosing the undertaking providing their internet access service.
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%...
The ability for open source software developers to write and run applications on their [fork of AOSP with a bunch of binary closed source out-of-tree kernel modules] devices should be protected, in order to prevent anti-competitive practices from squandering the open platform the community has helped to build.
Play Store requires a DUNS number and registration therefore these days.
F-Droid does not require a DUNS number for app upload.
(F-Droid is one of a number of third party APK registry and APK installer services. The F-Droid web service hosts signed Android "APK" software packages and updates which can be uploaded by registered users and downloaded without registration or login. The F-Droid application installs APKs from the F-Droid web service; though app install and update requires more taps to install or update multiple packages due to Android's lack of functionality to add third-party package repos with keys, a standard feature in modern Linux software package management systems.)
Android app developers can already choose whether their app can be installed or run on a device that doesn't pass Play Integrity checks.
If non-rooted third-party AOSP forks with recent Security Patch Levels fail Play Integrity checks and thus cannot work with retail banking apps for example, then old versions of Android for which there are no longer updates should also fail Play Integrity checks.
There are various tools which sideload APKs over HTTPS without any checksum or signature (e.g. from GitHub releases instead of from for example an OCI Registry) which are as reckless as curl | sh.
Couldn't bash and zsh run in a container2wasm WASM container that, in a browser tab without install, gets its own SELinux security context like all apps since Android 4.4+?
Does ls -Z work in Android Terminal (or termux, or the ChromeOS term)?
Students and Family Link accounts are currently denied access to containers on Chromebooks.
So on a Chromebook the same curriculum is limited to JupyterLite in WASM which almost works offline in a browser, instead of a local repo2docker container or a devcontainer.json (because there is no money for students to have server resources (like shells, CI, GitLab+k8s resource quotas) other than their provisioned computer).
container2wasm: https://github.com/container2wasm/container2wasm :
$ c2w ubuntu:22.04 out.wasmThe most compatible setup I found is proot-distro into alpine, which bypasses a lot of the android blockers, and the bionic-libc incompatibilities by using musl. Comes at a performance cost, however.
Android Terminal works pretty well on the pixel at the moment, so hopefully the merged version in ChromeOS-style laptops and tablets will be fully usable.
Because that isn't part of the set of allowed NDK APIs.
https://developer.android.com/ndk/guides/stable_apis
Anything that termux manages to do outside of that list is more out of sheer luck that Android team hasn't closed down that specific Linux syscall.
Initially Android only got the NDK back in Android 2.0, due to pressure from game developers, and Dalvik having such a lame performance, it was never for writing full applications.
Not a stretch to imagine that its the same work, so its desktop android, not, ChromeOS merge, this time.
Seriously though this is inevitable as Fuchsia wound down and Android essentially proved its worth running on Windows (which was a nice experiment I guess).
The only android on Windows I know about was the subsystem but that was shackled to the Amazon app store and was killed off when Amazon finally gave up on their app store.
The one with Amazon store was the second attempt.
Which is that Google might move Android from a Linux base to a Fuchsia at some point.
Makes sense, as they already ported the Android runtime to it.
This could be the "next generation" ChromeOS that are exclusively available on new/recent Chromebook devices, while Google keep updating the "legacy" ones with only security patches. From what I can tell, Google never explicitly promised that every supported Chromebook can get the latest feature updates. The only said "updates".
Of course this is pure speculation and I'd love to be proven wrong.
All of which to say: Yeah, I'm actually somewhat optimistic that we get official Android x86 out of this.
xnx•4mo ago
gclawes•4mo ago
Great opportunity for mandatory remote attestation and mandatory software.
thewebguyd•4mo ago
The big tech companies are boiling the frog, trying to get us used to Linux just being an "app" we run on our licensed, not managed by us devices.
Google will point to the linux terminal app on Android and go "see, it's OK that we're making these sideloading changes - you can just run Linux (in a VM, on a device you don't have root on). WSL also gets us used to the idea that Linux is just an app.
Get ready for people to not see between the lines, adopt it, and then the rug will get pulled. We'll see hardware OEMs that lock boot loaders, no more alternative OS for you, or if you do manage to install another OS, you won't get to access any internet services because you won't pass the device attestation checks.
mikestorrent•4mo ago
All it will take is Cloudflare et al. offering it as a free option for every CDN customer and who wouldn't turn it on? Especially if the alternative is having to handle ID verification yourself, right?
bitwize•4mo ago
transpute•4mo ago
"Terminal app can now run full graphical Linux apps in the latest Android Canary", https://news.ycombinator.com/item?id=44681858
"Coding without a laptop: Two weeks with AR glasses and Linux on Android", https://news.ycombinator.com/item?id=43985513
rs186•4mo ago
Technical capability often has little to do with how the product works.
rileymat2•4mo ago
thewebguyd•4mo ago
pjmlp•4mo ago
Anything outside of what is allowed, may work or crash and burn.
hulitu•4mo ago
This is like making sex in public. It is doable, but dangerous.
transpute•4mo ago
Thanks to SoC CPU/memory virtualization at the VM boundary, there is stronger isolation between Debian software packages and the rest of the device, than between any two Android software packages distributed by App Store, which are executing within a single VM context. This protects the device from side effects of Debian Linux software in the Developer Terminal VM.
This is more safe and more secure than status quo.
> doable, but dangerous
Incorrect. It is more isolated, less dangerous, more secure, more flexible for developers and increases functionality to users.
SnuffBox•4mo ago