Androidiots Podcast 2: Changes in Android P

Anupam Singh
Jul 6, 2018 · 5 min read

In today's episode, we are joined by himanshu saluja. He is to be a Bitcoin billionaire, a non-philanthropist plus a Senior Android Dev at UrbanClap. He is our #SME (Subject Matter Expert) today. He will shed light on the changes brought into Android P by google and how does they affect the life of an android developer.

Show Notes

Job scheduler :

Jobs can now declare their estimated data size, signal prefetching, and specify detailed network requirements — carriers can report networks as being congested or unmetered.

JobScheduler then manages work according to the network status. For example, when a network is congested, JobScheduler might defer large network requests. When on an unmetered network, JobScheduler can run prefetch jobs to improve the user experience, such as by prefetching headlines.
When adding jobs, make sure to use setEstimatedNetworkBytes(), setIsPrefetch(), and setRequiredNetwork() when appropriate to help JobScheduler handle the work properly. When your job executes, be sure to use the Network object returned by JobParameters.getNetwork(). Otherwise you’ll implicitly use the device’s default network which may not meet your requirements, causing unintended data usage.

Autofill :

Android 8.0 (API level 26) introduced the autofill framework,

As the container is scrolled, views in the layout get reused while their contents change. If the initial contents of the view are filled out, the autofill service retains the logical meaning for the views, which are identified by their autofill ID. As the contents of the views in the layout are reused, its logical IDs remain the same, which causes the wrong autofill user data to be associated with the autofill ID.

The autofill framework provides sanitizer APIs that services can use to clean a field value before a save request is triggered.
The autofill service has credit card datasets in which the credit card number is stored in the nnnnnnnnnnnnnnnn format (where n is a digit of the credit card number).
The service fills out the field with the data mentioned in the previous step.
The client app has formatting logic that adds a space every four digits of the credit card number. As a result, the field contains the data in the format nnnn nnnn nnnn nnnn.
The formatting of the data triggers a save request and the save UI is shown for no reason.


Android P enables encryption of Android backups with a client-side secret. Because of this privacy measure, the device’s PIN, pattern, or password is required to restore data from the backups made by the user’s device. To learn more about the technology behind this new feature, see the Google Cloud Key Vault Service white paper.

Fingerprint dialog

If your app uses FingerprintManager to display a fingerprint authentication dialog to users, you can now use a more flexible interface that responds to various types of biometric authentication. Migrate your app’s logic to use BiometricPrompt. BiometricPrompt relies on the system to display the authentication dialog. It changes its behaviour based on the biometric interface the user has selected.

Apk Signature Scheme

Android P adds support for APK Signature Scheme v3. This scheme has the option to include a proof-of-rotation record in its signing block for each signing certificate. This capability enables your app to be signed with a new signing certificate by linking the APK file’s past signing certificates to the one with which it is now signed.

Supported devices that launch with Android P installed give you the ability to use the Protected Confirmation API. By using this new API, your app can use an instance of ConfirmationPrompt to display a prompt to the user, asking them to approve a short statement. This statement allows the app to reaffirm that the user would like to complete a sensitive transaction, such as making a payment.

Limitations on background info

Android P limits the ability for background apps to access user input and sensor data. If your app is running in the background on a device running Android P, the system applies the following restrictions to your app:

Your app cannot access the microphone or camera.Sensors that use the continuous reporting mode, such as accelerometers and gyroscopes, don’t receive events.Sensors that use the on-change or one-shot reporting modes don’t receive events.If your app needs to detect sensor events on devices running Android P, use a foreground service.


Android P moves the CALL_LOG, READ_CALL_LOG, WRITE_CALL_LOG, and PROCESS_OUTGOING_CALLS permissions from the PHONE permission group to the new CALL_LOG permission group.

This group gives users better control and visibility to apps that need access to sensitive information about phone calls, such as reading phone call records and identifying phone numbers.

If your app requires access to call logs or needs to process outgoing calls, it must now explicitly request their permissions from the CALL_LOG permission group. Otherwise, a SecurityException is thrown.

Permissions for Wi-Fi scans

When your app accesses scan results and connection information, it must have the ACCESS_COARSE_LOCATION permission or the ACCESS_FINE_LOCATION permission.

When triggering Wi-Fi scans, your app must have one of these location permissions, as well as either ACCESS_WIFI_STATE or CHANGE_WIFI_STATE.

Foreground Service Permission

Apps that target Android P or higher and use foreground services must request the FOREGROUND_SERVICE permission. This is a normal permission, so the system automatically grants it to the requesting app.

If an app that targets Android P attempts to create a foreground service without requesting FOREGROUND_SERVICE, the system throws a SecurityException.

Work Manager : New Arch component introduced in I/O 2018

If WorkManager executes one of your tasks while the app is running, WorkManager can run your task in a new thread in your app’s process. If your app is not running, WorkManager chooses an appropriate way to schedule a background task — depending on the device API level and included dependencies, WorkManager might use JobScheduler, Firebase JobDispatcher, or AlarmManager. You don’t need to write device logic to figure out what capabilities the device has and choose an appropriate API; instead, you can just hand your task off to WorkManager and let it choose the best option.



Himanshu saluja , Tushar gupta , Anupam Singh

Feel free to leave your questions/suggestions/feedback in the comments.

Cheers !!

Anupam Singh

Written by

1/2 of


An android developer publication to stay updated with whats new in android, best practices and how to become a better android developer

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade