I have posted the slides from my talk on Gradle at the October Google Developer Group Twin Cities meetup.
The vast majority of developers using Gradle use the Gradle Wrapper. This is great because using the Gradle Wrapper means that developers working on the project don’t need to manage their own Gradle installations. Being that the wrapper is so ubiquitous it is important to understand exactly what it does and what it does not do.
Read on Medium ›Hidden among the API changes for Android O is a new feature for Views called tooltips. Being curious about what they look like and how they behave, I dug in to find out more.
Read on Medium ›Slides from my 2017 DevFest MN Talk on making Actions for the Google Assistant are now up!
Marshmallow brought runtime permissions to the Android world, and by now most apps have started requesting their permissions at runtime instead of install time (you have, right?).
Permissions are grouped into buckets like “location” or “storage” to simplify the explanation of what a permission does for users. Hopefully this is all old news to you.
However there is an interesting situation that merits a little more explanation.
Let’s say your app currently requests ACCESS_COARSE_LOCATION
. Your requirements
have changed a little bit, and you now need ACCESS_FINE_LOCATION
. What happens might
not be quite what you expect.
The documentation provides this note:
Note: Your app still needs to explicitly request every permission it needs, even if the user has already granted another permission in the same group.
So we know we need to request the new fine location permission. But what does the user see?
ACCESS_COARSE_LOCATION
If a user hasn’t accepted the coarse location permission (and hasn’t said “don’t ask again”), your app behaves as you would expect it to on a fresh install. You can request the permission as usual and go on about your day.
ACCESS_COARSE_LOCATION
If your user has denied the coarse location permission and selected the “never ask again” option, you will not be allowed to ask for either permission. This is also generally what I would expect- the user clearly doesn’t want you using their location, so you don’t get the opportunity to ask again.
ACCESS_COARSE_LOCATION
Here’s where it gets a little more interesting.
checkSelfPermission()
you’ll still get PERMISSION_DENIED
.ACCESS_FINE_LOCATION
with requestPermissions()
, you will
automatically get a callback to onRequestPermissionsResult()
with the fine
location permission granted. This is transparent to your user- they will not
see a dialog.If your app already requests a permission in a particular permission group, you still need to explicitly request all other permissions in that group that you want to use. However, if your user has already accepted one of the other permissions in that group, they will not see another permission request dialog.