Hacker News new | past | comments | ask | show | jobs | submit login
Android Q Beta (googleblog.com)
229 points by skiman10 43 days ago | hide | past | web | favorite | 172 comments

They finally restricted access to clipboard (see https://developer.android.com/preview/privacy/data-identifie...).

I always thought it was insane that any app could just listen to everything that went to the clipboard, even while in the background and without any permission. I'm sure many people copy passwords, credit card numbers, bitcoin private keys, etc.

I'm still of the opinion that apps with focus should not be able to read the clipboard by default. iOS allows this too, but this means that apps can (and do!) read stuff like passwords, links, and other stuff you've been interacting with passively.

I have been highly concerned about this after I opened a certain iOS app, and was immediately greeted with a system alert saying "Pasting from Mac..." even though there was NO reason whatsoever for it to access the clipboard (it was basically the first-run splash screen.)

Thanks to Apple's Continuity feature [0], you can seamlessly copy/paste across iPhones, iPads and Macs, and indeed it can be handy.

But if my network (or something else) hadn't been laggy at that time, I would have never caught that app trying to obviously snoop my clipboard's contents. I'm sure many more apps do this and they must be exfiltrating it.

And yes, I often copy/paste sensitive data to avoid retyping it, so this is practically CROSS-PROCESS, CROSS-DEVICE SPYWARE in an innocuous way that very few people would even think of, or should ever have to worry about.

The solution is simple: Don't let any process read the clipboard unless the user explicitly chooses to paste.

Apps that need automatic clipboard access to offer added convenience (like autofilling certain forms) should require explicit permission, just like we have for camera/microphone/etc., and preferably only while the app is in focus.

After all, such "intent-based security" is the reasoning behind the existing macOS "PowerBox" [1] which lets apps access only the files that the user manually chooses in an open/save dialog. Extend it to the clipboard too.

[0] https://support.apple.com/kb/ph25168

[1] https://developer.apple.com/library/archive/documentation/Se...

> The solution is simple: Don't let any process read the clipboard unless the user explicitly pastes.

but how does an OS know that a particular key combination is meant to mean "paste"?

Couldn't the app just pretend that the user wanted to paste because their cursor is in the password field?

Or, you end up with the OS owning all of an app's interaction. Leaving very little room for app innovation or improvement. It's a bit of a rock and a hard place.

> how does an OS know that a particular key combination is meant to mean "paste"?

macOS and iOS can do that easily; every app has a standard menu provided by the system, as well as a mechanism for modifying default shortcuts.

The clipboard should be treated like a potentially sensitive file. There's no excuse not to include it in the explicit permissions we already require for other files, photos, camera, microphone, contacts, location, and so on.

That screenshot of the modal prompt re: device location is virtually identical to the iOS dialog.

Not trying to start a flame war here just interesting to see the striking resemblance.

Example: https://mackuba.eu/images/posts/ios11-location/ios11-always.... (taken from https://mackuba.eu/2017/07/13/changes-to-location-tracking-i...)

It makes me beyond annoyed that google seems to insist on radically changing the design of their apps every 6 months, for no discernible reason, with no unifying theme or thread or underlying rationale.

> every 6 months

How so? This is Material 2 compliant. The last "style" they had was Material 1, which was 5 years ago.

"material" itself doesn't support many things on android ie there are no android versions of things. it's crazy considering the same company is supposedly using the spec for their device designs.

You're not the only one. I got yet another update to Gmail on Android a couple of weeks ago - honestly, it looks familar... it's like they've changed it so many times it's back round to how it was at some point in the past!

I really wish they'd just stop .

Android's GMail update sucks for those that can't stand high values of white, it is like being at an interrogation room with a spotlight on the face.

I agree - there really is a lot of white in the latest update! I'd much prefer a bit of colour to help delineate different sections of the UI, such as the search bar and buttons.

So would everyone except Google's in house design team, which has lost the plot.

There seems to be some suggestion this was done for the purposes of enabling dark mode, which has never made the slightest bit of sense tbh.

This is the essence of Google. They’re too big to fail so they can pretty much do whatever they want. Kill huge apps (Reader, Picasa), major paradigm shifts in UI, abandoning projects, fragmented efforts... how many messenger platforms do they have again?

Pretty much any other company would die from this kind of wheel spinning and frantic behavior, they’re fortunate to get away with it.

Or creating their own recommended design principals and then never implement them into their own flagship apps.

That's practically tradition by now, when you consider Office or iTunes, especially in older times (when people cared more).

Good ideas have flowed in both directions - such as iOS's notification center having a "striking resemblance" to Android's notification shade.

Both of them are actually converging to look and behave like webOS 10 years ago

Makes sense in the case of Android.


I wish the text was bigger on the Android version, similar to how much more space it takes up on the Apple one. Boosting readability is important, and the font is a little small for my taste.

Agree. This looks like the kind of UI that was designed in Photoshop or perhaps a device simulator and then never vetted on a real device by a real person. It's not great.

Most likely can be made a lot bigger using both font and display size settings in Android

I thought you were exaggerating until I went to look. That does look just like the notifications that I get on the ipad. I'm surprised to see them match it so closely, but I'm glad to see improvements in this area on Android anyway.

Convergent evolution occurs when independent traits evolve as a result of having to adapt to similar environments or ecological niches.

Other times an adaptation of one animal so radically changes the environment that other animals adapt similar traits because of it. When one poisonous insect becomes red and birds learn to avoid red insects, red is a useful color for other insects to be as well. Innovation is good, but copying good innovation isn't bad; variation let's us explore, convergence let's us carry experiences from one platform onto another. I like that the two dialogs look so similar, though I wish Google would copy Apple's text formatting a bit more closely, and I feel like Apple should copy the location marker at the top of Google's dialog.

Its a white dialog with blue clickable text. The text length makes standard blue buttons impossible. This is just what state of the art "developer ugly" looks like.

iOS and Android design seems to be converging more and more lately.

Starting with material 2, Google has decided to center align a log more elements on the screen (text, icons, etc). Google has also shifted to a lot more white and gray with blue used for actionable items.

In both cases it seems like apple got it right the first time, Google tried to pioneer the opposite and has now gone back and copied Apple.

Meanwhile a bunch of designers at Google have gotten promoted for their diligent work.

Looks like designers at Google are more used to iOS than to Android...

That dialog has little to do with Material principles...

To the point that the Material design files are only available in Sketch, screw Android designers that happen to use other platforms.

It is pretty striking how similar the UI is starting to look compared to iOS. And I say that as someone largely on the Android side of the Android-iOS debate. Also add to that the shift recently to move navigation to the bottom of the screen in the form of tabs.

I guess ultimately there's plenty of examples of this happening both ways, though.

Convergence of UX for the same context and expectations is a Good Thing. This is symmetric to expecting cmd + X and cmd + Z to do the same thing on different OSs and apps. No reason for it to be considered a bad thing.

The design looks the same. The idea makes sense but the design is strikingly similar. I think that’s what OP was getting at.

The iOS one is still better IMO because they can/have (?) to say what they're using it for in the dialog.

Very Surprised if Apple don't have a patent for a modal box :-)

They do, but you have to double-click to dismiss it because Amazon has a patent on single clicking.

They have a patent for single click buying. Not “single click” that I’m aware of...

This is shameful. I have no words. It's practically a verbatim copy. Of course, getting the font sizes wrong, because it's Android. But other than that, just shameful. It doesn't even look like Material design. I seriously hope they change it before release.

It's like the engineer in charge of the feature couldn't get a hold of a designer and so had to make the design himself... so he just took if off his own phone.

> Android was designed with security and privacy at the center.

Right. That's why ostensibly local apps can make unfettered connections to the internet without my having any knowledge or way of stopping it, right?

This is relative to desktop where traditional apps don't even run in a sandbox and app permissions weren't a thing.

A Linux app can not only create Internet connections, it can read and write all your personal files. (But we thought that was pretty secure since it didn't run as root.)

This feels almost obligatory: https://xkcd.com/1200/

What harm does exposing $HOME to the world anyway. /s

Linux apps aren't infested with malware and tracking trojans though, if the threat doesn't exist then there's no reason to protect from it. With android collecting this sort of data is it's very reason for existence.

We don't usually see widespread infections, but Linux malware does exist.

Also, many apps do send telemetry by default, though there are usually instructions to disable it.

Sure it exists, but it's not an infestation. Even then I'm not aware of it or telemetry enabled apps in any trusted sources like the debian repositories (if you're aware of any please let me know), they'll even disable it from organisations like Mozilla that don't care about privacy. The play store cannot reasonably be considered a trusted source.

If your going to download stuff from random places, which is how most telemetry enabled apps end up on linux systems then no sandboxing will work anyway, it will simply be disabled as part of the installation process. It's not a technological problem, you can't fix it with technology.

Yes, a Linux distro like Debian has some security advantages since they won't ship just any app. But relying on code review isn't the same as having sandboxing in the OS.

There's two successful systems I know of out in the real world, Linux distros that rely on code review and iOS that relies on code review and sand boxing. There's two failures, android that relies purely on sandboxing and windows, which was too gimped by sandboxing to take off.

> But relying on code review

It's not just code review, it's having a degree of seperation between the developer and the packager/authorizer.

Some things are more successful than others, but it's not a one-bit distinction. Arguing over whether to set the "success" bit would be silly. But it seems arbitrary to say that Android is a failure when it has more users than iOS or Linux.

Browsers are another important example of sandboxing.

> But it seems arbitrary to say that Android is a failure when it has more users than iOS or Linux.

I'm not saying android is a failure, I'm saying it's sandboxing has not prevented malware and spyware being ubiquitous. This was a problem way back before android itself was a huge success.

> Browsers are another important example of sandboxing.

This has been pretty effective at preventing malware, but the web is a privacy nightmare and constantly getting worse.

Ok, I see what you mean. Caveats: Android doesn't rely solely on sandboxing. They also do automatic scanning and do often find stuff [1]. I also wouldn't say malware is so bad it's "ubiquitous" on Android since it's in the news quite often but I don't think the average user is likely to encounter it?

My take on it is that current-generation sandboxes have permissions designed for security (preventing takeover by hackers), not privacy. In particular, preventing an app from phoning home isn't something they try to do. You can't have privacy without security so sandboxing is a prerequisite, though.

[1] https://android-developers.googleblog.com/2019/02/how-we-fou...

Of course not, given the failure of the year of desktop GNU/Linux, there is hardly any money to be made.

That's just because few people use Linux, not because Linux has some inherent ability to stop people downloading malware. In fact it has less than any other major OS. Mobile OSes have vaguely curated app stores and proper permission systems. And Mac and Windows have at least attempted to help with their code signing systems (even if they are pointless and annoying).

Linux has "run this `curl | exec` command as root".

> Linux has "run this `curl | exec` command as root".

You've clearly not used Linux much of you think that's the normal software installation method. That's the normal installation method on windows, minus the GUI to download and run for you.

> That's just because few people use Linux, not because Linux has some inherent ability to stop people downloading malware

You can't stop them downloading it, you have to direct them to trusted sources to get software, that's where Linux and iOS work, they have same approach but different implementations, it's where windows and Android fail.

> Windows have at least attempted to help with their code signing systems

Their best attempt so far is the windows store, but that was still born because they went for the sandboxing instead of verifying approach.

> That's just because few people use Linux

And all those servers aren't high value targets? We'd be seeing a lot more issues if "curl | Sudo exec" was how things were done.

And furthermore, "privacy" against everyone except Google, which has a lot more access than just unfettered internet connections.

> Android was designed with security and privacy at the center.

iOS does enforces code signing to avoid app modification since it was last signed while Android allows the code to be modified even after installation.

Under a lot of aspects I do agree Android was built as a secure by design system, but the aforementioned problem seems to be in the opposite direction, at least IMHO.

Can someone up on current Android tell me how things like this are still common?

Personal interest: I’ve been using Linux since the early 90s, and was psyched to see what the Danger HipTop people could do with Google backing. The first time I looked closely at Android phones I ran into multiple articles on the topic “what anti-virus software should you run on your new Android phone”, and I haven’t done more than play with Android since then.

Based off of the actual research ( https://research.checkpoint.com/simbad-a-rogue-adware-campai... ) it looks like TechChrunch just got critical details very wrong. The adware didn't "install itself" at all, it was just bundled into the app up-front.

But the overwhelming majority of this attack, popping open URLs & showing ads, is something Q is looking to put a stop to wholesale: https://developer.android.com/preview/privacy/background-act...

It's just apps including tracking code to make money. These days that's how apps monetize. They upload whatever amount of data they can get in exchange for pennies. There's not much you can do short of not allowing apps to do literally anything.

Adwares are just that, ads. Sadly, the mobile app economy runs on ads.

>Starting in Android Q, apps must have the READ_PRIVILEGED_PHONE_STATE signature permission in order to access the device's non-resettable identifiers, which include both IMEI and serial number.

While I welcome this improvement, I can't help but think that app developers will respond by refusing access to the app unless the user grants the permission. Both android and ios need to be able to "silently deny" permissions.

> I can't help but think that app developers will respond by refusing access to the app unless the user grants the permission. Both android and ios need to be able to "silently deny" permissions.

iOS doesn't need this because Apple rejects apps that demand access unnecessarily.

> Apps must respect the user’s permission settings and not attempt to manipulate, trick, or force people to consent to unnecessary data access. For example, apps that include the ability to post photos to a social network must not also require microphone access before allowing the user to upload photos. Where possible, provide alternative solutions for users who don’t grant consent. For example, if a user declines to share Location, offer the ability to manually enter an address.


>iOS doesn't need this because Apple rejects apps that demand access unnecessarily.

In my experience, that doesn't seem to be working. I've so far encountered a food pickup app that refuses to let me order without location permission (their website works fine without location, however), and a finance app that refuses to process a transaction unless I give them access to location for "fraud prevention".

Those accesses can be more or less justified. Accessing IMEI "just because" isn't a good enough reason.

I can't think of any issues in revoking app permissions on Android, going back to Android 4.something at least.

I think google is carefully saying "non-resettable identifiers", because App developers will still be able to access the Google Advertising ID, for example, which is resettable. My guess is 99.9% or more of users never actually reset it, though. I just reset mine for the first time recently (Settings -> Google -> Ads -> Reset advertising ID).

App developers can't access that ID. The closest they can get is the ad-exchange id which resets automatically every 30 days.

So they just need to store the old one and poll it every time the app is opened or so, and if it changed, they know the old and new one?

Not sure Apple allows this kind of thing, but changing it regularly, I'm not sure it helps much by itself.

That won't happen because 3rd party apps cannot have the READ_PRIVILEGED_PHONE_STATE permission.

Correct: https://android.googlesource.com/platform/frameworks/base/+/...

The permission is signature|privileged. Only apps signed with the same keys as the OS itself or pre-installed in /system/priv-app can get the permission at all.

In iOS you can't access any hardware identifier AFAIK.

Apps can only access an app installation UUID.

On Android there's a great Xposed module called XPrivacy that can do this - produce an empty contact list, block network connections, zero out location, etc.

Cryptographically strong, secure identification coming from the ProtectedAPIs are a double edged sword. On one hand, these APIs let you build critical real world apps like ones required to remote control a medical assistance device or act as a electoral vote casting machine, but on the other hand provide very strong tracking cookie to data hungry ecosystems (Mac addresses could be spoofed but not these).

I have been thinking a Linux/Desktop fork similar to elementaryOS needs to exist for Android. ChromeheadOS was close enough, may be e.foundation would be that, may be Daniel Micay will restart his crusade again.

Serial number is useless on half the devices I've seen anyways. A crapload of devices just report 12345678ADBCDEF for a serial number.

Unless I screwed up and it's deliberately feeding me garbage because I asked the wrong permission.

IIRC, signature permission means that 3p apps can't request it at all. They have to be signed with the same key as the OS, so practically only your handset manufacturer can use it.

Of course. Google's own apps already do something similar by popping up warnings. Why do I need location, Mic, and camera preferences to use gmail or other Google play services apps that shouldn't be using any of those features? That's obviously a rhetorical question when talking about Google.

Gmail does not require location, mic, or camera access. In fact, the Gmail app does not even request any of those permissions, so I'm not sure what you're talking about.

Turn off those preferences in Google play services and see how annoying the errors are for yourself when using Gmail.

So, Vulkan is now compulsory, most likely given the way OEMs cared about supporting it and keeping up with Vulkan updates.


More sandboxing of Android APIs, permissions and introduction of roles.

They added a C++ MIDI API, but searching for plugged devices can only be done at Java layer.

Speaking of which, it is going to be the usual partial Java 8 variant, and Java 12 is going live next week.

> So, Vulkan is now compulsory

There is nothing to suggest that Vulkan is now required.

> Speaking of which, it is going to be the usual partial Java 8 variant, and Java 12 is going live next week.

Java's version number has been hijacked to mean OpenJDK's runtime version & handful of non-core library updates that don't exist on Android anyway.

It has vanishingly little to do with the actual language or core libraries these days.

The only thing of interest at all between Java 9, 10, and 11 are var handles (compiler-only, no runtime support needed - should work fine on Android), and the Flow class. Which is unfortunately missing, yes, but not particularly significant. Might work better as an AndroidX addition anyway.

Since Twirrim already tackled Vulkan, I will only answer on the Java part.

The only thing of interest for Java developers, is being able to use any standard Java library out of Maven central, instead of having two versions or minimal common code, and not excusing Google for having successfully created a fork in the Java eco-system, aka Android J++.

Rest assured when Valhalla and Panama finally land, it will only get worse.

The only thing that matters for library interop is the bytecode version, not the "Java" version. Binary version & source version have been different attributes in Java going all the way back to the J2ME days.

> Rest assured when Valhalla and Panama finally land, it will only get worse.

You're assuming that Android won't have support for those, but that assumption is unfounded. Android has so far gotten support for all the bytecode-level changes that have happened like invoke-dynamic.

Java 9, 10, and 11 have not changed the bytecode. Nothing about the compiled binary has changed to require support. And outside of Flow none of the core libraries have changed, either.

There's no forking or hijacking in play here. Oracle just hasn't done anything that needs support from a runtime since Java 8.

> Java 9, 10, and 11 have not changed the bytecode

Off the top of my head, JEP 309, implemented in Java 11, introduces a new instruction called `constantdynamic`

JEP309 "constantdynamic" for the uninitiated: https://openjdk.java.net/jeps/309

Ah my mistake then. Is there any way to actually use that instruction from Java though? Or is this just bytecode support for a potential future feature?

It gets used by the compiler, so unless ART gets to understand it, those nice Java 11 libraries at Maven central that might make use of it are a no go on Android.

And yes, it is also related to the ongoing Valhala efforts.


So where is Android support for constant pools or nested class changes?

Of the complete Java standard library for that matter.

Of course I am assuming the worse from a company that insists in getting away with Android J++, while having fanboys supporting their agenda, many of which were even on the first row against the old J++.

But I get it, the "Do no evil" company has lots of SV love.

> support for constant pools

Are you thinking of Java 11's Dynamic Class-File Constants or Java 12's JVM Constants API?

> nested class changes

What nested class changes?

> Of the complete Java standard library for that matter.

What is missing other than the few new additions (like Flow) in recent versions?

Or are you mistakenly considering javax.* part of the Java standard library? Because it's not, which Java 9 reinforced as part of Project Jigsaw.

> What nested class changes?


> What is missing other than the few new additions (like Flow) in recent versions?

A big chunck of what is listed here.


https://docs.oracle.com/en/java/javase/11/docs/specs/jni/ind... (Android supports up to Java 6 JNI)

> There is nothing to suggest that Vulkan is now required.

From the article:

"We're working together with our device manufacturer partners to make Vulkan 1.1 a requirement on all 64-bit devices running Android Q and higher, and a recommendation for all 32-bit devices."

Which means it's not required as long as 32-bit devices are allowed to ship as well. It will be a large percentage, like GLES 3 is, but not required, like GLES 3 isn't.

I googled around and honestly can't find a single phone introduced in 2019 that's still 32-bit.

Sure, embedded non-phone Android devices could still be built with 32-bit CPUs to cut costs, but those devices typically don't let user install 3rd party apps in the first places so they're not relevant to the discussion.

Nearly every Android TV is 32-bit, and many low-end Android devices ship in 32-bit configuration even if the hardware is 64-bit for RAM reasons.

Both of them run arbitrary 3rd party apps. They also form basically the entirety of the GLES 2.0 portion of this pie chart: https://developer.android.com/about/dashboards/index.html#Op...

Which means they won't run much new apps in 2020.

I wonder what those 32-bit devices would be good for.

> We're also moving the ecosystem toward readiness for 64-bit devices. Later this year, Google Play will require 64-bit support in all apps

-- https://android-developers.googleblog.com//2019/03/introduci...

Preliminary VarHandle support in Android start in P. The API is hidden, but it had to start ahead of the Java 9 libraries because it's a lot of work.

All code needs to be capable of being interpreted as that's the fallback when compilation invariants are violated (and also when stepping through code with the debugger).

A large number of operations combined with different vartypes and backing store types (fields, static fields, arrays, Buffers, etc) makes for a lot of work, even though this is just the slow path.

There is no compiler support yet for VarHandles, or MethodHandles, on Android, but there are bugs on these.

I thought that Native MIDI API would be something that places NDK as first class citizen, but as you mentioned it's a bit constrained. But it's more that Native MIDI is first class, than whole of NDK.

Nice to see that the original Pixel and PixelXL will be getting Q. It's always struck me as weird that Google sells that line of phones ostensibly for people who care about their OSes more than normal, and then only offers a couple of years of new OSes on them. Maybe we're seeing them turn the corner on that.

Despite launching with Nougat, Pixel 1 devices were the testbed for Project Treble.


I was just watching a video a couple minutes ago about changes to system navigation in Android Q [0].

Oddly, I don't see any mention of it in this blog post.

Can someone explain how (1) switching buttons into gestures and (2) changing the recent apps screen from a list of all apps on 1 screen to a full screen for each app...how are these good ideas? What is the design philosophy for these changes?

They seem like gargantuan steps back in ease-of-use and intuitive design.

I'm looking forward to jumping to a Pine64 or Purism phone before I am compelled to use this mindless ripoff of stupid Apple interface design.

[0] https://www.youtube.com/watch?v=PCM2SR5pDn4

> changing the recent apps screen from a list of all apps on 1 screen to a full screen for each app...how are these good ideas? What is the design philosophy for these changes?

If you mean how the "cards" are now side-by-side instead of "stacked", I can assure you this is a HUGE improvement. I use this already on my Oneplus 6T.

The likelihood of requiring a recent app decreases enormously the further back in time you go. 95% of the time, you want the the previous app. 4% of the time, you want the next most recent app. 0.5% of the time, you want the third one... (all figures made up by me on the spot).

My point is, swiping left-to-right to expose cards in the past is FAR better than pulling down and shuffling through this crazy infinite deck of cards that flies by top-to-bottom.

Android P on Pixels already works like that. The video shows a prototype of changing the appearance of the cards to make them larger.

To get back to your last open app you double-press the "last app" button on android P. Way better than swiping.

Android P on Pixels actually has the option to double tap on the recents icon or flick right from the home button. Flick right should be just as easy as double tap in theory, but I haven't learned how to make it work 100% of the time yet.


But in that stack you could see titles, and directly switch to the one you want, if it was one of last N.

Exactly. The new interface, even if it makes logical/quantitative sense, is functionally worse. I don't ever need to see the whole screen of an app to before deciding if I want to switch to it or not. Having all the titles and windows of open apps in 1 tidy list is way more functional, even if I only rarely access old apps.

> Oddly, I don't see any mention of it in this blog post.

From my experience, gestures and navigation changes quite wildly between beta builds, as they test different things to get feedback, so what you see here may be very different from what we get on release. I'm guessing the blog post covers the more stable features.

Huge steps back in UI to rip off Apple are par for the course in Android now.

Pie was an enormous step backwards.

Just a nitpick, but the two changes referenced in the parent comment (whole screen 'cards' for multitasking view and using gestures for such) are straight from WebOS for both Apple and Android. Being a step back in UI is also a bit subjective, I personally find it a lot easier to navigate between the apps I regularly use now.

Edit: Just installed the android Q beta and the back button is still present, I was not aware of the potential loss of the back button. I can see why that would be considered such a step back in usability.

I think you're going to be in for a big ol' frothy glass of reality check juice if you're thinking Purism is going to have better usability than Android or iOS...

> The back button is vestigial tech debt. Gestures are the future.

I don't necessarily think that the back button will remain, but I think it SHOULD remain. Gestures are cool, but the back button is like the undo feature: it gives user a visible, clear button to correct a mistake or cancel an action. Gestures are not immediately visible/discoverable, so while for a tech savvy it might not be a problem, for the average consumer (think of your dad, or aunt, or grandpa) it is a usability regression.

Devils advocate: the iPhone has never had a physical back button and it's a wildly successful device with people across all walks of life and levels of technical experience.

I think a lot of Android users feel this way but it is clear that Android is moving away from physical buttons. It's a crutch that Google is finally getting rid of.

On the other hand, most ordinary non-technical folk I know of don't know about about iOS swipe-to-go-back gestures, as iOS has largely moved from buttons to non-discovered swipes, special presses that most people won't know about unless they RTFM which they never do.

How many people know about Shake-to-Undo?

The swipe to go back gesture only applies to navigation controllers in which case there will always be a back button in the top left corner.

And yes they removed the home button and replaced it with a swipe up. But they have an annoying dark black line to indicate this. And you literally can’t use your phone without this one, simple gesture.

Another devil's advocate: undo on iOS is nigh-undiscoverable.

In the early iPhone-versions almost all apps had a back-button on the top-left corner during nested navigation.

I miss it.

All apps that use UINavigationController i.e. nested still have the back button in the top left corner. Nothing has changed.

More a case that apps have moved away from this UI style in favour of other conventions e.g. burger menu.

Sorry I wasn’t trying to say the UI button is bad, I was referring to the physical button.

> The back button is vestigial tech debt. Gestures are the future.

The back button is discoverable. Gestures are not.

My iPhone is full of magic gestures I dont know or care about, but suddenly they get triggered and ruin whatever I worked with.

And I can’t simply disable the infuriating madness either. It’s not an option. Why?!?

Please, pretty please, give me my buttons back. They are simple. They work. They don’t need documentation, tutorials and instructional YouTube videos.

TLDR: Buttons are real hot stuff. You should have buttons.

I think basic usability and user-friendliness on iOS has been going backwards since iOS7. I still think the platform overall's preferable to Android (hobbyist interests aside) mainly because Android started so far behind and, despite improvements, continues to bumble about, but I miss having an OS that I liked using but that I'd also unhesitatingly recommend as a primary device for my tech-confused relatives.

> Please, pretty please, give me my buttons back.

The problem is you have very loud early adopters who are abrasive and forcefully tell everyone that X is the new hotness and you're an old grandpa for wanting old-X and, ha, by they way, I'm pissing on your lawn. So, the rational majority get tired of trying to be heard and give up. Google and Apple, thus, never hear from them.

Apple never got rid of the buttons though.

They just removed the border but you can easily add them back in by going to Accessibility and enabling Button Shapes.

> if you're thinking Purism is going to have better usability than Android or iOS

Luckily, I don't think that. It's not what I thought of Linux on my laptop when I moved to it full-time either. But here I am a year later, loving it.

I think this basically kills a large chunk of the KDE Connect functionality I rely on. No more background clipboard access means no more clipboard sync, and closing off SD card access means it can no longer act as a wireless alternative to USB file transfer (which is terribly unreliable on Linux).

Are you saying they restricted SD card access further? Because I am able to use FolderSync to do wireless file transfer at very high speeds. I am not a developer or associated, http://www.tacit.dk/foldersync/faq/#how-can-i-access-externa...

Yeah, the external storage permissions are going away altogether according to https://developer.android.com/preview/privacy/scoped-storage - apps will no longer be able to get access to them.

What is external storage for if the apps can't access it?

Android will soon be so large that the OS won't fit in the 16GB of internal memory most phones have and will use some of the external too.

They can still access their own private area within external storage, which is fine for apps that just want to store large amounts of their own data, and they can use it for photos, video and music. There's just not any kind of general access to it anymore.

Yes, my interpretation is that that apps that simply used to use the READ/WRITE_EXTERNAL_STORAGE (runtime) permissions (which, if granted, implicitly give access to the whole storage, albeit possibly with some write access restrictions on removable SD cards) now instead need to explicitly ask the user to pick an allowed directory tree (or trees) using ACTION_OPEN_DOCUMENT_TREE. So nothing that used to work should have become totally impossible now and instead of a simple yes/no choice users now could also answer "Yes, but only this directory", which should be nice, although it also means a slightly more complicated UX.

Of course Google also prefers you to use content://-URIs instead anyway. Those do indeed have the advantage that the receiving app doesn't require any special permissions because it simply uses the permissions granted by the app sending that intent, but at the same time they also have a number of issues that Google chooses to ignore. I've ranted about some of those here (https://hg.mozilla.org/mozilla-central/rev/9175cafb84bd), and the most important in my view is that content://-URIs as currently implemented totally break opening of locally stored HTML files (https://issuetracker.google.com/issues/77406791) and other similar content that implicitly depends on more than the one file that can be transmitted through the content://-URI intent.

Blog post isn't up yet, but you can get the factory images here: https://developer.android.com/preview/download.

Sign up for the OTA should be here: https://g.co/androidbeta when Google decides to update everything.

It's up now.

I need one feature and one feature only:

Control the apps internet connectivity.

When your flashlight app needs a constant internet connection to function properly we have a problem.

The article mentioned something about connectivity, but I read 3 times and I still don't know what it means.

I use Netguard for this. Works well.


No root required, open source etc.

That's a good option, although unfortunately it prevents the concurrent use of VPNs.

My honor already does this: https://vgy.me/mSUFiV.jpg

Is this feature only found on honor/huawei phones?

Yes, that's Huawei-only.

Is it just me, this seems to be dripping with marketing schtick?

: rant on :

> Android is right at the center of this innovation cycle

> Android was designed with security and privacy at the center.

[ Ok. I get we're reading about Android¡ I disagree completely about this last point - it was always about advertising]

> One thing that's particularly sensitive is apps' access to location while the app is not in use (in the background).

[No mention that, by default, apps can phone home... which is a far greater privacy concern imho]

> If your app is in the background and needs to get the user's attention quickly -- such as for incoming calls or alarms -- you can use a high-priority notification and provide a full-screen intent.

So now my phone is no longer a phone, but a high priority notification device? They still don't give us inbuilt firewall/ adblocker, and they seem to continue the trend of making & receiving calls more obtuse by allowing every aspect of my 'phone' bleep, vibrate or blink at me.

: rant off :

What's the use case of allowing location access in the background for the user of the cellphone. I understand the use case for advertisers and other companies whose revenue model is based on spying and collecting data, but I can't imagine any application I'd be running on the background that would need location while it's in the background. Do people put map apps in the background? What other legitimate uses are there for location data?

> I can't imagine any application I'd be running on the background that would need location while it's in the background. Do people put map apps in the background?

Many Uber and Lyft drivers run Waze in the foreground and the Uber/Lyft driver app in the background.

I used that approach in a custom app for a family to track a person with MCI in case they got lost. (MCI=Mild Cognitive Impairment - memory problems basically)

- Some people like to track their own movements

- Automation

- Location-based reminders

Just three use cases that came to my mind immediately.

Installed this, seems to mostly work okay. Looks like they broke Go on Android for now though [1] - unfortunately Syncthing is written in Go. Amusingly this bug was posted (by a Googler) about 7 weeks ago.

[1] - https://github.com/shadowsocks/v2ray-plugin-android/issues/6

Seems privacy has increased, in a way and maybe I can finally switch from iOS. Will try buy a $150 Pixel 1 on ebay and install AQ on it

Has it? Does it afford me 'contextual' permissions, rather than an app just requesting contacts for no reason? Does it let me know _what_ data it's requesting (long/lat coordinates, state/county, country, continent?)? What about the data it's requesting about my contacts, does it tell me which contact's data was accessed, and what data that was (first/last name, DOB, email, phone number)? Does the app make a request to a server after getting that data, does it store it on a server? Are apps compliant with the GDPR, do they respond to privacy requests, such as what data they store, or whether they delete data when asked to do so?

Everything you see about privacy is an illusion, designed to do the bare minimum to make people think Google respects your privacy. But there's a reason Facebook likes Android simply due to how much information it gives developers with or without permission. You can hope the user allows that location permission (accidentally just once is all it takes).

Without actually detailing what information they want, why they want it, how they'll use it and how it'll be stored and processed and deleted (LOL) then no, privacy has not increased.

And this isn't exclusive to Android, but operating systems and 'apps' as a whole.

"privacy has not increased as much as you would prefer" and "privacy has not increased" are two distinct statements. You appear to be making the former, but asserting that it's the latter.

This beta has nothing exciting and just shows that both iOS & Android copy the best ideas. e.g.: Sharing shortcuts - it looks very similar to iOS sharing sheet with AirDrop users around you.

I hope with the wifi connectivity changes, we'll be able to connect wifi to IOT devices without losing the 3G/4G connection at the same time.

"We could not enroll your device at this time. Please try again later." This after listing my eligible device.

Will it have a way to prevent sending my location to Google without having to disable Location Services?

Was really hoping to see they brought back Smart NFC Unlock. No cigar.

After upgraded my Pixel XL to Android Q, found weixin crashed.

Do these new versions even matter at this point? We keep getting new ones while the last one barely gets past 10% adoption. Android is mess.

The last one is the one that was a "new version" last year. Now it's past 10% adoption. So yes, you pretty much explained that it matters.


Actually 8.x is at 21% and 7.x at 28%. That's half the people on the last 2 versions. Older ones will soon get replaced as those phones start dying.

So, 15%? Doesn't seem to matter. The last 3 or 4 android versions really haven't changed much, except useless design updates that confuse users.

That's a mix of subjective stuff (you don't like UI changes, I do), and simply missing things like the big platform change in 8.0 which actually speeds up the adoption/updates (project treble). Please don't troll.

Project Treble relies on OEMs to actually bother to deliver updates, sofar they have cared so much that Google is finally adding some kind of update clause to Google Play Services access contract.

A part of that dragging feet was that they had to port all their (imo unnecessary) "value add" every time. This approach from Google actually works from both ends: incentive - you have a portable/stable base, and enforcement - now that you have it, stop doing stupid things.

Fact is that Project Treble does not sell more phones and still requires OEMs to spend money on development efforts.

So unless they are forced to do it, you might get a Project Treble compliant phone, yet get zero updates.

Q as, Q from StarTrek? While I enjoyed the character on the screen, I'd rather not be bothered by a "real q"..

No, Q as in the letter after P.

Nah, this is Google, Q will be the omnipotent one.


Woosh what? He was making a not funny irrelevant comment about Q from Star Trek.

> Android Q


Basically this is iOS 12

Another example of Android learning from Apple.

And with this, Android as an open system is dying yet again.

It’s sad we won’t even have an option to give apps full filesystem access. At least make it optional.

The filesystem issue is going to be a problem for me. I have an app that writes about 1000 images a day from user photographs which should certainly not be mixed into the general images pool! And I want to be able to browse my filesystem. It sounds like that's basically out without rooting now.

Instead, I was waiting for an understanding that phones and tablets are becoming ever more general purpose devices, which means having a lot of niche applications which should have more control over their use of resources, including memory and cpu use. Notify, warn, make a lot of noise - but let the user decide if the app is making the right choices for their device, not the ideal device in the sky. It's not that hard to have minimum/low/standard/high/maximum use flags for cpu, ram, network, etc. And then make them actually mean something significant.

> The filesystem issue is going to be a problem for me. I have an app that writes about 1000 images a day from user photographs which should certainly not be mixed into the general images pool!

The app doesn't need to contribute the photos to the shared media store. It can if it wants to allow other apps to also have access, but it can also write them to its own private directory.

> And I want to be able to browse my filesystem. It sounds like that's basically out without rooting now.

The scoped storage changes are something that app developers must handle, but you, as a user, will still be able to browse the entire SD card. (I'm a member of developer relations on Android and wrote a proof of concept file browser that works just fine on Android Q. :)

Any chance this PoC file browser is open source and available? I've been looking at these changes and I'm not sure how I should handle discovery of new devices, e.g. insertion of a new SD card, or an OTG USB device.

How does it work if I want to be able to browse that private directory with a file browser?

Generally, an app can ask the user to grant it access to other directories on the device, including the actual SD card root. (The user can also decide to only give the app access to a subset.)

Specifically, the API one uses is ACTION_OPEN_DOCUMENT_TREE.

I feel the same. I've been using Termux a lot recently and I love that it has the ability to access local storage. I can just run a sshd from termux and rsync music and photo files to my phone. This is the mail reason I like android better than iOS. Easy access to shared file storage.

I'm also wondering what will happen to all of those File Manager apps on PlayStore.

The app can always open the system "Directory open" dialog though storage access framework and it'll get full access to that directory without being able to read all your other private data.

So for your use case it's still fine.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact