Improving app security and performance on Google Play for years to come(android-developers.googleblog.com)
android-developers.googleblog.com
Improving app security and performance on Google Play for years to come
http://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html
33 コメント
> you didn't have to ask users for permissions to access contacts, sms, SD card and other data
This isn't true. Android 6.0 introduced runtime permissions, where permissions could be granted in the context of the application. Previously, the permissions still had to be granted, but they were granted before the application was installed.
This isn't true. Android 6.0 introduced runtime permissions, where permissions could be granted in the context of the application. Previously, the permissions still had to be granted, but they were granted before the application was installed.
You get asked when you install the app but nobody looks at that huge list of permissions, especially if not accepting means you don't get to use the app
There's a huge difference between apps being able to do stuff without ever asking permission and apps asking permission but users choosing to ignore it and just say yes to everything.
While I agree with permission overload at install time, users pay more attention when permission prompts come up one at a time at first-use. It also gives the app a reason to stagger in permissions only when the feature is used, lest the user loses interest and drops off.
Actually really big news.
Apart from the security implications it will also decrease fragmentation of Android versions and encourage manufacturers to update their OS versions.
Apart from the security implications it will also decrease fragmentation of Android versions and encourage manufacturers to update their OS versions.
Technically snapchat and scummy apps can keep collecting private data indefinitely. Demands for API levels only apply for either new apps or new updates to existing apps. They could simply leave a version in the app store, use that for collecting, and have new versions have their own play entry like an unlocker app currently does it.
Not even the August 2019 deadline prevents that.
So really, there's nothing in here that stops personal data collection.
Not even the August 2019 deadline prevents that.
So really, there's nothing in here that stops personal data collection.
That's good, but it's almost a year ahead (November 2018), and I wonder how many Snapchat users care about permissions at all.
Yeah this is definitely the biggest point of the article, thanks for highlighting that!
> This is finally great news for Android security
Yea, now only Google is collecting an absurd amount of information on you. They don't like competition, so I'm surprised it took this long for them to implement this.
Yea, now only Google is collecting an absurd amount of information on you. They don't like competition, so I'm surprised it took this long for them to implement this.
This just seems unnecessarily harsh on Google. Just because they haven't solved security / privacy in its entirety, they shouldn't be lambasted for taking a step forward!
Google shouldn't wait till Nov to fix the loophole of apps bypassing some permissions by declaring an older target SDK version. Give developers a quarter's notice, and update Android and Google Play services to enforce these permissions starting March 2018.
Developers who don't prioritise their users' privacy even after being given a quarter's notice can have their apps break.
Developers who don't prioritise their users' privacy even after being given a quarter's notice can have their apps break.
But what if my phone manufacturer refuses to provide Android Oreo? My phone (LG v20) was released in late 2016 and was the first to support Nougat (7.0).
What about others in this situation where stupid manufacturers refuse to upgrade their Android software?
What about others in this situation where stupid manufacturers refuse to upgrade their Android software?
Pick a phone next time that is from a manufacturer who has a reputation for staying up to date with Android.
But, the sad reality is that no manufacturers anywhere will provide OS updates for more than 2 years, and many are MUCH less than that. They expect you to throw them away and buy new ones. Or, they expect you to not notice since they don't want to 'burn cash' on porting new updates.
Nevermind that the 'android device support model' is a dumpster fire. Android (specifically AOSP, but google's spin too) needs to be a rolling distro to make it easier for manufacturers to support older devices (but no guarrantee they will care..). Shitting a monolithic update on them once a year doesn't work.
The 'smartphone industry' is an incredibly wasteful industry.
But, the sad reality is that no manufacturers anywhere will provide OS updates for more than 2 years, and many are MUCH less than that. They expect you to throw them away and buy new ones. Or, they expect you to not notice since they don't want to 'burn cash' on porting new updates.
Nevermind that the 'android device support model' is a dumpster fire. Android (specifically AOSP, but google's spin too) needs to be a rolling distro to make it easier for manufacturers to support older devices (but no guarrantee they will care..). Shitting a monolithic update on them once a year doesn't work.
The 'smartphone industry' is an incredibly wasteful industry.
Project Treble[0] is a good 80% solution which makes it much easier to run mainline AOSP on new devices [1]. Ports still need to fix device-specific bugs, and camera image processing optimizations won't work unless they're implemented beneath the HAL (or hacked into a custom ROM). You'll also need a modern (8.0) unlocked device. Besides those caveats, it's a big improvement.
[0]: https://source.android.com/devices/architecture/treble [1]: https://forum.xda-developers.com/project-treble/trebleenable...
[0]: https://source.android.com/devices/architecture/treble [1]: https://forum.xda-developers.com/project-treble/trebleenable...
Developers are free to continue targeting a minSdkVersion as low as they want. It’s only the targetSdkVersion which must be recent.
Android apps get tagged with two API levels. minSdkVersion is a way for the developer to say "my app requires this version of Android or higher". targetSdkVersion lets them say "opt me in to breaking changes you've made to the APIs on newer OS versions, because I've built and tested it to handle that".
So with this change, a developer can still release a brand new app that runs on Android phones which are 5 years old if they want. They just have to make sure that app is aware of how the newer releases work too.
So with this change, a developer can still release a brand new app that runs on Android phones which are 5 years old if they want. They just have to make sure that app is aware of how the newer releases work too.
This affects target API version, not minimum API version. Meaning that developers can still support your phone and you'll get benefits from them not opting into the unsecure compatiblity modes.
Install LineageOS if there's a maintainer for your model. It's a good way to extend the life of orphaned devices. (And next time, vote with your wallet and pick a different vendor. Some are better than others.)
Awesome news !
I have been hoping to see this happen for a while.
No point in adding new optimizations and security requirements in the new Android releases if devs can opt out of them by targeting a very old Android version.
As a dev, I feel vindicated for having pushed the organizations I worked at to closely follow the new releases.
As a user, I am happy I soon won't have to check the manifest of the apps I install
I have been hoping to see this happen for a while.
No point in adding new optimizations and security requirements in the new Android releases if devs can opt out of them by targeting a very old Android version.
As a dev, I feel vindicated for having pushed the organizations I worked at to closely follow the new releases.
As a user, I am happy I soon won't have to check the manifest of the apps I install
Anyone know what the "security metadata" is? Just Google signing the APK in addition to the developer signing it? Not sure how that helps, but not sure what else it would be.
More info further down the article:
> ... adding a small amount of security metadata on top of each APK to verify that it was officially distributed by Google Play. ... The metadata we're adding to APKs is like a Play badge of authenticity for your Android app. > > ... the small metadata addition, which is inserted into the APK Signing Block ...
Yes it looks like an additional signature.
> ... this metadata will enable new distribution opportunities for developers in the future and help more people keep their apps up to date.
This suggests that you may be able to distribute signed APKs outside the Play store (e.g. host the APK yourself and email a link to beta testers?).
> ... adding a small amount of security metadata on top of each APK to verify that it was officially distributed by Google Play. ... The metadata we're adding to APKs is like a Play badge of authenticity for your Android app. > > ... the small metadata addition, which is inserted into the APK Signing Block ...
Yes it looks like an additional signature.
> ... this metadata will enable new distribution opportunities for developers in the future and help more people keep their apps up to date.
This suggests that you may be able to distribute signed APKs outside the Play store (e.g. host the APK yourself and email a link to beta testers?).
Torrent-style P2P updates? Installation over Bluetooth for users without connectivity or with expensive plans? I might be in the same room and already have this app I just recommended to you...
It could also just be HTTP/S from the developer's site, which already happens.
And that could be a way to circumvent the GFW.
I'm curious why the first required version is Android 8.0 (API version 26), instead of Android 8.1 (API version 27)...
From what I remember, 27 does not change the security model in any way, it just adds a couple of small features.
Their point is that you should target the latest major release. Ideally you should target the latest release, period.
I don't really care if an app targets 26 instead of 27 though. if an app targets 20 though, I definitely resent that a lot.
Their point is that you should target the latest major release. Ideally you should target the latest release, period.
I don't really care if an app targets 26 instead of 27 though. if an app targets 20 though, I definitely resent that a lot.
Android Studio tells me API 20 targets about 70 percent of android devices. API 26 targets less than one percent of android devices. What apps are you using that target API 26? I had to develop an app for a customer in Mexico two years ago and the customer made us target API 15 because they wanted to maximize app compatibility.
targetSdkVersion != minSdkVersion
You can target the very latest API version, while still being compatible with whatever API version you want.
You can target the very latest API version, while still being compatible with whatever API version you want.
Probably because they are reaching backwards by some internally defined amount of time.
From a users perspective: This is great.
If you targeted APIs before Android 6.0 (e.g. you targeted API Level 21 - Lollipop), you didn't have to ask users for permissions to access contacts, sms, SD card and other data. Which made all the new security improvements in Android rather moot - scummy apps (like Snapchat :P) just didn't update their API levels, kept collecting personal data without asking for permission... AND didn't implement improvements of new OSes because they wanted to keep collecting data without restriction.
This is finally great news for Android security.