Chapters
Chapters

Chapters

Hide chapters

Android App Distribution

First Edition · Android 12 · Kotlin 1.5 · Android Studio Bumblebee

Before You Begin

Section 0: 5 chapters
Show chapters Hide chapters

Section I: App Store Quick Start

Section 1: 4 chapters
Show chapters Hide chapters

Section II: Security & Optimization

Section 2: 6 chapters
Show chapters Hide chapters

Section III: Automation: Continuous Integration & Delivery

Section 3: 2 chapters
Show chapters Hide chapters

Section IV: Beyond Publication

Section 4: 3 chapters
Show chapters Hide chapters

5. Permissions
Written by Fuad Kamal

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

In the previous section, you learned how to distribute and release your app. When you distribute your app, you may find one of your app’s critical functionalities requires explicitly asking the user for permission to access certain hardware features. Furthermore, when you release your app into production, you need to ensure your users’ data is secure. In this chapter, you’ll learn about different types of permissions, how to gain access to features that rely on those permissions and how to secure your users’ data.

Permissions

For security, you have to declare or request permission before using certain features on Android devices. Permissions protect access to restricted data and restricted actions. You declare permissions in the app manifest file. Certain types of permissions also require asking the user to actively grant them so your app can use them.

Permissions that only need to be declared in the app manifest and are granted automatically when your app is installed are called install-time permissions. The user sees a list of the install-time permissions your app requires on its app details page in the Play Store, but they won’t get UI prompts from the app about them.

Play Store permissions listing for Google Maps.
Play Store permissions listing for Google Maps.

Permissions that require authorization from the user at runtime are known as runtime permissions, or dangerous permissions. When you request a dangerous permission from the user, the system prompts them with a popup permission request.

In-app permissions popup for Google Meets.
In-app permissions popup for Google Meets.

You need to keep some best practices and user experience design, or UXD, in mind when working with dangerous permissions. Also, while there are many types of permissions, the permissions ecosystem changes from version to version of Android OS. So, be sure to check the official documentation regularly.

Dangerous permissions

Android OS presents the user with a UI prompt whenever your app requests a runtime permission. You can ruin user experience by requesting permissions that don’t make sense to the user or at the wrong time. So it’s critical to follow Permissions best practices. To learn how, you’ll update Podplay with some interesting features.

App manifest permissions

There are some common types of permissions your app might need to request. For a complete and current list of all Android app permissions, refer to the permissions API reference https://developer.android.com/guide/topics/permissions/overview.

Location permissions

Apps that need to know a user’s location need location permissions. According to permissions best practices, you should minimize the data you collect from users.

Uhraq tulgxzeugv razaduob gosvagzuim
Uypit zehgbheilj widalaem mapsuwzuic

Asking for permission

Here’s the recommended code block for checking for permissions and requesting them if necessary:

Permissions best practices

Here are the best practices regarding permissions:

Requesting minimum permissions

Only use the permissions necessary for your app to work. Every time you ask users for permission, you require them to make a decision, increasing the burden on the user.

Asking for access in context

Ask for permissions only when your app needs to access it for the first time. Be transparent with your users about why you need the permission.

Planning for denied requests

There’s no guarantee the user will grant the permission you request. You should always write the logic of your permission request in a way that assumes the user may deny the request and act accordingly. If the user denies or revokes a permission that a feature needs, gracefully degrade your app so the user can continue using your app, possibly by disabling the feature that requires the permission.

One-time permissions

System dialog that appears when an app requests a one-time permission.
System dialog that appears when an app requests a one-time permission.

Don’t access private data unexpectedly

Pay attention to the time and frequency you’re accessing user data to ensure it aligns with what users expect. You must provide continuous indication for mic and camera whenever you access these sensitive capabilities.

Updating Podplay to search by location

Now that you understand the best practices and UX of requesting permissions, you’re ready to update Podplay to search for podcasts based on the user’s location.

iTunes Search API

Podplay uses the iTunes Search API to search for podcasts.

Implementing location service requests

As you know, you don’t want to access your user’s location until necessary. Hence, you don’t ask for location permissions as soon as the app starts. That would surprise the user and possibly lead them to deny the request outright.

Dizoogido qiurv fibtaze gakk dunf ju tusgisjk ezv.
Hecoeladu riuzf kaxdolo javv mawm lo jumtopsw iyh.

Fetching location

There’s only one piece left to this puzzle: determine the user’s country. First you’ll ask the system for the user’s last known location. You’ll then use that location to perform a technique known as reverse geocoding.

Finding background location use

Android 10 and 11 give users better privacy controls for fine-grain location permissions. One of the biggest changes is the separation of foreground location access, or while-in-use access, from background location access, or all-the-time access.

Updating your code

Find any location APIs in your code to determine if they’re used in the background.

Finding permissions required by third-party libraries

You inherit permissions every time you include a third-party library in your code. Users will generally attribute those permissions to your app, not to the library.

Simplifying multiple permission requests with Android Jetpack

The code and techniques you used so far are fine when you only need to request one or two permissions. But some apps need access to multiple permission types. Using requestPermissions() and then checking the request code in onRequestPermissionsResult() for many different types of permissions can start to make your code complex.

Key points

You covered quite a lot in this chapter! Here’s a quick recap of some of the salient points:

Where to go from here?

In this chapter, you got hands-on experience with some location services and the permissions around them. However, your app many need access to many other kinds. See Saving Data on Android for all the many ways you can access data on a device, including disk and database access, network access and SharedPreferences, which you’ll touch on from the security standpoint in the next chapter. You can find the book here: https://www.raywenderlich.com/books/saving-data-on-android/.

4. Strategies for Release
6. Security Best Practices
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now