Android Q Beta
android-developers.googleblog.com
android-developers.googleblog.com
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.
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...
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.
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.
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...)
I guess ultimately there's plenty of examples of this happening both ways, though.
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.
I really wish they'd just stop .
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.
Pretty much any other company would die from this kind of wheel spinning and frantic behavior, they’re fortunate to get away with it.
How so? This is Material 2 compliant. The last "style" they had was Material 1, which was 5 years ago.
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.
That dialog has little to do with Material principles...
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?
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.)
Also, many apps do send telemetry by default, though there are usually instructions to disable it.
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.
> 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.
Browsers are another important example of sandboxing.
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.
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...
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.
https://news.ycombinator.com/item?id=19380012
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...
Adwares are just that, ads. Sadly, the mobile app economy runs on ads.
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.
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 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).
Not sure Apple allows this kind of thing, but changing it regularly, I'm not sure it helps much by itself.
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...
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".
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.
Apps can only access an app installation UUID.
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.
Unless I screwed up and it's deliberately feeding me garbage because I asked the wrong permission.
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.
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.
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."
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.
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...
> 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...
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.
> 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.
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.
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.
https://openjdk.java.net/jeps/181~
> 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/api/index.htm...
https://docs.oracle.com/en/java/javase/11/docs/specs/jni/ind... (Android supports up to Java 6 JNI)
Off the top of my head, JEP 309, implemented in Java 11, introduces a new instruction called `constantdynamic`
And yes, it is also related to the ongoing Valhala efforts.
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.
https://www.androidpolice.com/2017/05/18/current-google-pixe...
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.
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.
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.
I miss it.
More a case that apps have moved away from this UI style in favour of other conventions e.g. burger menu.
How many people know about Shake-to-Undo?
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.
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.
They just removed the border but you can easily add them back in by going to Accessibility and enabling Button Shapes.
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.
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.
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.
https://m.androidcentral.com/how-enable-android-p-gesture-na...
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.
Pie was an enormous step backwards.
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.
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.
Sign up for the OTA should be here: https://g.co/androidbeta when Google decides to update everything.
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.
No root required, open source etc.
Is this feature only found on honor/huawei phones?
: 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 :
Many Uber and Lyft drivers run Waze in the foreground and the Uber/Lyft driver app in the background.
- Automation
- Location-based reminders
Just three use cases that came to my mind immediately.
[1] - https://github.com/shadowsocks/v2ray-plugin-android/issues/6
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.
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.
So unless they are forced to do it, you might get a Project Treble compliant phone, yet get zero updates.
Quiche?
It’s sad we won’t even have an option to give apps full filesystem access. At least make it optional.
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 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. :)
Specifically, the API one uses is ACTION_OPEN_DOCUMENT_TREE.
I'm also wondering what will happen to all of those File Manager apps on PlayStore.
So for your use case it's still fine.