The First Beta of Android 15 | Hacker News Reader

The First Beta of Android 15

android-developers.googleblog.com

35 pointskieto15 comments

I wish there was a word about desktop mode. Plugging in my phone and having Windows 11 or Ubuntu or whatever pop up on my desktop has been my lifelong nerd fantasy. Something like DeX, but a "real" desktop OS (where i can open terminals, build stuff, maybe even launch nested VMs), and as a first-class citizen. Maybe Google/Android could have their own desktop skew of Android (like how Microsoft has Azure Linux optimized for their environment), e.g. take Debian and add integrations to it for the rest of the Android system, like when you get notifications, they will appear in the Gnome dock, etc.

I know you said you wanted it as a fist-class citizen, but you can roll your own here. Termux lets you set up a chroot Linux install, and you can run a display server and VNC in it. Then you can get a VNC viewer Android app and hook it up to localhost, hook up an external display+keyboard+mouse and you have yourself a heavily-compromised Linux desktop!

The very constrained environment sucks. Limited kernel with sparse modules, probably no root access (and Google's infernal Play Protect/SafetyNet will try to make sure you can't run certain apps if you do have root), lots of additional security layers... Android is antagonistic to userlands; it's no fun.

It'll be interesting to see how much of the Chrome OS work Android steals. ChromeOS also has an immensely locked down world, but they have build all kinds of secure/virtualizing proxies to let container OSes feel like they have access to hardware. Immense NIH is both daunting but also kinda cool, see https://www.chromium.org/chromium-os/developer-library/guide...

So when does RCS get a public API? I like google messages and all but I'd kill to see support open up to any of the other messaging apps that exist.

And as it is, the API restriction that's locking RCS support in is entirely an arbitrary one.

Never, because RCS doesn't work that way.

However, someone has created an open source prototype RCS client: https://github.com/Hirohumi

It supports only carrier-provided RCS, though. No one seems to have even attempted to connect it to Google's carrier-bypassing RCS service.

It's not that RCS doesn't work that way.

RCS support is actually embedded in android (albeit as a closed source rcsprovider implementation). They just won't actually open up the API (That they expose to other orgs that pay them enough like samsung for their apps).

There is no good technical reason why the RCS API needs to restrict itself to only pre-authorised applications vs making RCS access a permission for the user to approve.

If one is content with remote-controlling Google's proprietary implementation, it can unofficially be done by leveraging the Web UI: https://github.com/mautrix/gmessages

That however does come with all the drawbacks of adversarial interoperability.

With these being the major changes, it very much feels like Android is "done". That changes from now on will be small tweaks rather than fundamental redesigns?

Maybe that's a good thing? I've been enjoying my "done" KDE Linux desktop for many years and actually don't want people to "move around my furniture" all the time.

I'm not complaining if that is the case!

Just wondering if that is where we've got to or if I was missing something.

If it were "done" there would be nothing left to improve. But why aren't iOS users switching in droves then?

More like Android has hit its ceiling. Time to be replaced by a fundamentally new approach.

Personally, I'm hoping for a "real Linux" based desktop for multiple form factors or even with seamless sync. The Steamdeck has shown that it is possible to do even for smaller companies.

> With these being the major changes, it very much feels like Android is "done".

They change every program (sorry app) from the sake of change. And they fix bugs. No, not the ones introduced by those changes.

> Apps with the REQUEST_DELETE_PACKAGES permission can call the PackageInstaller requestArchive method to request archiving a currently installed app package, which removes the APK and any cached files, but persists user data.

Why do they call it archiving, it looks like it's just executing pm uninstall -k to keep the user data?

So this is at least a step into the right direction, how uninstalling was handled since decades: Never ever fiddle with user data on uninstall!

> users will see a UI treatment to highlight that those apps are archived. If a user taps on an archived app, the responsible installer will get a request to unarchive it

What happens if one tries to start an "archived" app which isn't available on the store anymore?

Correection: pm unstall -k also keeps the app cache which could, according to <https://old.reddit.com/r/privacy/comments/1ayheuf/is_there_a...>, be a problem when reinstalling an app. So I assume pm uninstall uses a new parameter or even a completely new command in Android 15 for archiving.

> Key management for end-to-end encryption

Hopefully this is sign that Android will support E2EE RCS that is interoperable with iOS.

> Hopefully this is sign that Android will support E2EE RCS that is interoperable with iOS.

Android/Google encryption is proprietary as evidenced by the fact that the Content-Type header is "application/vnd.google.rcs.encryption":

* https://www.gstatic.com/messages/papers/messages_e2ee.pdf § Messages Encryption

They state:

> In order to store and exchange user public keys like identity keys and prekeys, we need to have a central key server. Unlike the RCS messaging servers, the key server is currently only hosted by Google.

* Ibid § Key Server

For interoperability there would (potentially) need to be a neutral third-party where everyone's public key(s) are present. ("Everyone" potentially being all folks who use RCS, which may be every phone on the planet.)

Reply on news.ycombinator.com