
Android Q Beta - skiman10
https://android-developers.googleblog.com/2019/03/introducing-android-q-beta.html
======
opayen
They finally restricted access to clipboard (see
[https://developer.android.com/preview/privacy/data-
identifie...](https://developer.android.com/preview/privacy/data-
identifiers#clipboard-data)).

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.

~~~
saagarjha
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.

~~~
Razengan
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](https://support.apple.com/kb/ph25168)

[1]
[https://developer.apple.com/library/archive/documentation/Se...](https://developer.apple.com/library/archive/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html)

~~~
chii
> 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.

~~~
Razengan
> _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.

------
whalesalad
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....](https://mackuba.eu/images/posts/ios11-location/ios11-always.png)
(taken from [https://mackuba.eu/2017/07/13/changes-to-location-
tracking-i...](https://mackuba.eu/2017/07/13/changes-to-location-tracking-in-
ios-11/))

~~~
andrepd
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.

~~~
ehsankia
> every 6 months

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

~~~
kkarakk
"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.

------
AdmiralAsshat
> 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?

~~~
skybrian
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.)

~~~
flukus
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.

~~~
skybrian
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.

~~~
flukus
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.

~~~
skybrian
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.

~~~
flukus
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.

~~~
skybrian
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.

~~~
flukus
> 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.

~~~
skybrian
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...](https://android-developers.googleblog.com/2019/02/how-we-fought-bad-
apps-and-malicious.html)

------
gruez
>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.

~~~
JimDabell
> 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.

— [https://developer.apple.com/app-
store/review/guidelines/#pri...](https://developer.apple.com/app-
store/review/guidelines/#privacy)

~~~
gruez
>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".

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

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

[https://vulkan.gpuinfo.org/vulkansupport.php#android_devices](https://vulkan.gpuinfo.org/vulkansupport.php#android_devices)

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.

~~~
kllrnohj
> 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.

~~~
pjmlp
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.

~~~
kllrnohj
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.

~~~
half-kh-hacker
> 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`

~~~
kllrnohj
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?

~~~
pjmlp
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.

[https://openjdk.java.net/jeps/303](https://openjdk.java.net/jeps/303)

------
onychomys
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.

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

[https://www.androidpolice.com/2017/05/18/current-google-
pixe...](https://www.androidpolice.com/2017/05/18/current-google-pixelpixel-
xl-will-support-project-treble-possibly-meaning-longer-support/)

------
m52go
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](https://www.youtube.com/watch?v=PCM2SR5pDn4)

~~~
2bitencryption
> 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.

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

~~~
mikelward
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.

[https://m.androidcentral.com/how-enable-android-p-gesture-
na...](https://m.androidcentral.com/how-enable-android-p-gesture-navigation-
system)

------
makomk
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).

~~~
knaik94
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...](http://www.tacit.dk/foldersync/faq/#how-can-i-access-
external-sd-card-on-android-5-0-and-newer)

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

~~~
ggm
What is external storage _for_ if the apps can't access it?

~~~
Y_Y
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.

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

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

~~~
el_duderino
It's up now.

------
foxfired
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.

~~~
pisky
I use Netguard for this. Works well.

[https://www.netguard.me](https://www.netguard.me)

No root required, open source etc.

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

------
cmroanirgo
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 :

------
mnm1
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?

~~~
JoshTriplett
> 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.

------
bpye
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](https://github.com/shadowsocks/v2ray-plugin-
android/issues/6)

------
dzonga
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

~~~
tcd
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.

~~~
joshuamorton
"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.

------
xhruso00
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.

------
mingabunga
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.

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

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

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

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

------
matchbok
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.

~~~
viraptor
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.

[https://developer.android.com/about/dashboards](https://developer.android.com/about/dashboards)

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.

~~~
matchbok
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.

~~~
viraptor
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.

~~~
pjmlp
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.

~~~
viraptor
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.

~~~
pjmlp
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.

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

~~~
IshKebab
No, Q as in the letter after P.

~~~
0-_-0
whooosh!

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

------
excalibur
> Android Q

Quiche?

------
m3kw9
Basically this is iOS 12

------
mlindner
Another example of Android learning from Apple.

------
kuschku
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.

~~~
sgc
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.

~~~
LadyNike
> 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. :)

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

~~~
LadyNike
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.

