Permissions on Android (Android Dev Summit '19)

[Music] my name is Sarah and I'm the product manager on Android permissions and I have here with me my colleague Phillip who's software engineer on permissions over the course of the last two days we've had a chance to meet a number of you and we truly appreciate you

taking the time to come here talk to us tell us your stories and experiences and give us feedback over the next 15 to 20 minutes Phillip and I will provide you with an overview of the permission changes that we introduced in Android 10 and we'll share with you

some of the best practices that guide our product development process on Android our goal is to give users more transparency and control to their own personal information that's being used by applications to that and we have been working to evolve Android to make it much more private in

Android 10 were introduced 50 over 50 our privacy features making it our most privacy friendly release to date just looking at permissions alone for example we made a number of changes we made privacy and location top-level settings menu we introduced location more granular location as well as added

background location reminders and we made activity recognition a dangerous runtime permission and as well we restricted access to on device screen content looking at device identifiers we restricted access to dangerous Hardware IDs as well we randomized MAC address by default and finally looking at background activity we have

restricted background at activities launching from background as well in Android 9 we restricted access to background mic and camera this is just a small flavor of some of the changes that we've made to Android but today we're actually here to just talk permissions so I'm going to hand

it over to Philip who's gonna go through more details about some of the changes in Android ten thanks Sara first with an attendee wanted to improve the users understanding of their current privacy configuration so we added a new top-level privacy setting that links the user to the permissions

management but also to privacy related information like for example their web activity and their settings another privacy related settings is this location setting integration settings you can find which ever recently used in locations but also private location proxies such as Bluetooth and Wi-Fi users are very sensitive about

sharing location data hence in android 10 we allow the user to choose if they share the location data all the time or only while using the app let's look at some use cases if the app wants to take a photo or take a social social media post with

location the user PD knows is using your app and knows how the house location is used navigation in vendee if the app provides navigation the user might choose to temporarily use a different app in this case the we acquire the app to show a notification remind your user

that unification component is still actually using location data as you can see I'm not showing any use cases for background location we believe that background location use cases should become quite rare even if the app has a background occasion feature the user might still be uncomfortable with sharing

the location all the time with this app and the user might deny the excess implementation wise if you feature requires back on location access you have to add an additional we call the modifier permission in your manifest and this permission is around information and went once it's granted

it grants background access to the additional foreground means in this case cause define location as you can see we considered second occasion something very special if your app accessing is accessing location in the background we eventually some day later show a notification reminder user that user has the

choice to deny their contacts s there's two additional changes in under ten I want to talk about in entered nine and before actively recognition was not considered user sensitive the hundred ten be considered user sensitive hence to get user consent you asked for a runtime permission and user

can say yes or no this is the name of runtime permission and you asked for it like any other one-time permission stream decoding is another very sensitive topic for the user hence we enforce user consent by requiring all apps to go through the media protection manager API let's

see how it looks like so in order users you have to create a foreign service with a specific specific type then you start a foreground service when the server falls and services connected you start the consent activity the user can then say yes or no once a user

says yes you start the projection let me hand it back to Sarah to talk talk about your motivations behind these changes Thanks I'll spend the rest of this session are talking about some of the research we've done in this space and describe how those insights actually drive a

lot of our product decisions and development so we know that most apps tend to request access to permissions usually all at once or upfront or during onboarding but users have continuously told us that they prefer when an app asks for permission when they understand they understand the reason

for that permission and we can see that when we pull or our users we see that only about only 18 percent of them have every single permission granted on their devices and when we asked them why they eventually and permission the top reason that this state is that

they want to use a specific feature of an app or they want to experience a feature so this demonstrates that users are more likely to share their data with applications when they understand and get to what the value of it is and they and it sounds very logical

to them and we also are seen that users are choosing to share less data so as we mentioned we introduced the new changes in location more granular location permission and now we're seeing in our data that over half the users are selecting while the app is in use

and through our studies we have learned that users actually understand what while in use means and they're making their choice intentionally and finally our data actually highlights really high sensitivity towards mic in camera so as I mentioned we actually removed access to baka and mic in camera but

we never really in Vic indicated that in the runtime permission so in our future release of Android will actually will change the wording to say while in use so the user doesn't have to worry about their data being accessed in the background as I mentioned earlier we have

a set of best practices that we like to share with developers I'll summarize some of them here today so first we ask that you review your permissions request the minimum permissions that your features need so for example check to see if there are alternative api's if there are

other alternative api's they give you the data you need please choose to use them instead of permissions they tend to be much narrower in scope and hence more privacy friendly we also asked to please review your permissions request permissions in context and for the use case so as

we've Illustrated users are willing to share data but they just need to understand the perceived value please pay attention to your permissions required by libraries your users don't distinguish between the data that your app is using and the third-party SDKs are so please understand the permissions that your

SDKs require and minimize use of location especially background location as Phillip has illustrated really access to foreground is generally enough for most location use cases and also design your app to work under the conditions that you will have only or wall in use because I've seen more than

half the users are selecting while in use and you may never actually have access to background and finally we ask that you're transparent about the data that you're using let your users know why you need access to that data these best practices are based on principles and values

that drive our product development process and they will continue to drive how we innovate in this space and we really hope that you continue to work with us and give us feedback in making our ecosystem safer for all of our users so that concludes our presentation today we'd

love to hear from you I think we're going back upstairs we also have a sandbox if you haven't stopped by yet we have another hour left so please do so and we'd love to hear your use cases especially if you have location use cases or whatever it is

let us know about them we just want to understand your applications a lot better thank you very much for spending the last few minutes with us and we really appreciate your time thank you [Music] you [Music]


See More Android:

Hãy bình luận đầu tiên

Để lại một phản hồi

Thư điện tử của bạn sẽ không được hiện thị công khai.