Live data from Hacker News

Android 16 is here

blog.google

121–130 of 360 posts

Re: Android 16 is here

#121
post #92

Earlier quoted context omitted.

For control surfaces, padding prevents misclicks. It's actually very important part of perceived interface quality when dealing with a handheld touchscreen device.

Different topic: CSS doesn't have a good way to manage nearby clicks? A tap just a few px outside a button should click the button? s can steal focus from nearby taps on Mobile Safari (which can also be a fuckup). I hate iPhone taps that slip a little and scrollable areas having queer interactions (causing usability/accessibility issues).

What's wrong with increasing the size of the button?

You can set a (pseudo) element as an invisible enlargement of that button but then you will get accidental taps.

Re: Android 16 is here

#123
post #43
post #14

Earlier quoted context omitted.

The same thing that happens to every OS, features and bloat. That said, Pixel devices all the way. No gross UI reskin, no having multiple copies of the same type of app (Samsung camera vs android camera, dialers, keyboards, etc.). Fast, stable, good features. If it's not a pixel device, you're probably going to have a "mid" experience.

pixel devices are nice when they work. but damn hardware quality is shoddy in terms of aging. my pixel 6a battery got swollen with less than 3 years. I have a first gen iphone se still in use. I also had a pixel 3a that I couldn't find a screen replacement for luckily for me -- google accepted a trade in when the 6a got released. the pixels have a overheating problem -- this you can google for. oh yeah, when automati…

>> the pixels have a overheating problem -- this you can google for.

People keep saying this, but that's been every phone I've ever had. They all get hot in hot weather and under heavy use.

Re: Android 16 is here

#125
post #87

If Android is getting desktop windowing, how long until I can just plug my phone into a monitor and keyboard and have a usable computer?

You can plug a keyboard and mouse into your Andriod phone for many years. I haven't had one work with a monitor yet, though.

It almost works. But the monitor just mirrors the phone, including its weird aspect ratio and font size.

It's almost usable for playing movies on a TV, but that's about it.

Re: Android 16 is here

#126
post #46

Ah, so the "Linux Terminal" app is not yet ready for any announcements. This app with 3D acceleration enabling running graphical linux systems is what I'm waiting for, but it looks like we'll wait another year..

How does it enable graphical Linux systems? I mean, I did already do this by running KDE Plasma on Termux, but why would Google allow this?

They did with "VmLauncherApp" and I was able to run Fedora, however GPU acceleration didn't work.

Now, of course they removed the app :) But there's a "linux terminal" app which at least in theory should allow something similar since GPU acceleration was mentioned, but the app is limited "on user builds"..

Note this uses kernel virtualization, so it's faster and more properly separated.

Re: Android 16 is here

#127

Earlier quoted context omitted.

For control surfaces, padding prevents misclicks. It's actually very important part of perceived interface quality when dealing with a handheld touchscreen device.

Yeah, but the icons and labels could use more of that padding and be larger so old folks like me can see them.

There's literally a setting for this. There are separate sliders for "display size" and "font size", the latter of which just makes the font larger

Re: Android 16 is here

#128
post #90
post #46

Ah, so the "Linux Terminal" app is not yet ready for any announcements. This app with 3D acceleration enabling running graphical linux systems is what I'm waiting for, but it looks like we'll wait another year..

Connectbot has a local terminal that I have always used for this purpose.

But what I was talking about was kernel virtualization where the guest OS performs at native speed and without any hacks.

Re: Android 16 is here

#129
post #92

Earlier quoted context omitted.

Different topic: CSS doesn't have a good way to manage nearby clicks? A tap just a few px outside a button should click the button? s can steal focus from nearby taps on Mobile Safari (which can also be a fuckup). I hate iPhone taps that slip a little and scrollable areas having queer interactions (causing usability/accessibility issues).

You could, but you don't want it to. Buttons are e.g. often floating above content, or adjacent to other buttons. It's just as bad to click a button you don't want to, when you're merely trying to scroll, or highlight text, or click another button. Making a button's clickable area larger than the button itself can be desirable in limited circumstances, but it's not a general-purpose solution.

> You could, but you don't want it to.

Argue with Apple because Mobile Safari makes a tap close to a button click the button (and it causes exactly the problems you've predicted, and workarounds are difficult). Do you do a lot of close testing?? Because the feature is quite noticeable.

Try it yourself on an iPhone (ideally use something that can do smaller taps than a finger, with zoom and without zoom): https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

I recall that similar features are more obvious on Android because you can make taps visible.

Virtual keyboards also have interesting responses to close taps on key buttons.

Re: Android 16 is here

#130
One extremely disappointing thing that Android has been getting under the hood with Google images is ... Play integrity. This used to be a relatively simplistic system with three tiers: 0 - you are not certified for anything 1 - basic integrity, you need to have a genuine android device running google play services 2 - device integrity, you need to have a genuine android device with core requirements on play and no rooting 3 - strong integrity, you need a locked bootloader and signed image with recent security update

This API/requirements set was uniquely put by pressure from various vendors(think banks and various "security-certification" obsessed parties), and was already quite unpleasant, as it excludes any form of rooting, even if your root-access is adb only. But it gets worse as now non-official images are getting excluded not only from strong integrity[0] but also device integrity. Numerous apps are now requiring device integrity and hence won't be usable even on a locked, signed android image if it's not google or vendor-official.

It actually gets worse. Google has been silently restricting the api results(as of may): - basic requires a certified device with an android platform key attestation - device now requires a hardware verified boot, with locked bootloader and recent security patch. This excludes lots of devices - strong requires security patch on all partitions

And it gets even worse. On recent play stores & android versions, as apps have to be installed or updated by google play to get a full integirty response. no more sideloading APKs or alternative stores.

This is nothing but a clear move to a full lock-in to play store, where the majority of vendors live, to end up with a fully locked a-la-apple ecosystem. This doesn't improve security, people that know still have ways to bypass those restrictions when needed. All it does is give the illusion of safety.

I would personally feel like: 1 - rooting should be allowed on a certified device with most apps still working. This could be done with a locked bootloader too if they provided such an image for debug. 2 - alternative os, like graphene, should be given a way to pass all attestations, as well as alternative stores, provided they follow a set of constraints.

With this in mind, I can't be positive about android 16 and new versions going down a grim locked future.

[0] https://discuss.grapheneos.org/d/6361-play-integrity-api-and...

Post reply on HN