Android 17 and Contact Picker: the Google Play Permission Revolution that redefines your privacy and security of your apps

Google has announced this week a series of changes in its Play policies that seek, on the one hand, to strengthen people's privacy and, on the other, to give companies greater protection from unsafe application fraud and transfers. At the same time the company made public its last numbers of moderation: in 2025 it blocked or eliminated more than 8.3 billion ads and suspended almost 24.9 million accounts, figures that reflect Google's effort to contain abuses in its advertising ecosystem and in the app store.

Among the most relevant developments are changes in how the apps will access the contact agenda and user location. In terms of contacts, Google promotes a standardized and more restricted use by Contact Picker which acts as a safe and searchable access door for an app to receive only the contact data that the user authorizes at that time. This replaces the previous practice, in which many apps requested READ _ CONTACTS and with it they could see the complete list and all the associated fields. Official documentation for developers on how to treat permissions and contact providers is a good starting point for understanding changes: Android Permissions Guide and Contact Provider.

With Android 17 - the version that introduces these tools - applications will be able to declare exactly which field they need from a contact, for example a phone or a mail address, rather than requesting access to the entire registry. Google asks that, whenever applicable, apps use the Contact Picker or Android Sharesheet as the main mechanism for accessing contacts; READ _ CONTACTS would be reserved only for those applications that cannot really work without continuous and complete access. If an app points to Android 17 or later, the practical recommendation is to remove the READ _ CONTACTS permit from the manifest when it is not necessary. In addition, if the app requires permanent access to the contact book, it will need to be justified by a developer statement form on the Play Console.

With regard to location, Android 17 incorporates a simplified button to request timely access to the precise location. The idea is to make it easier for the user to give limited and temporary permits for specific actions, preventing the apps from asking for more information than necessary. In addition to this, a persistent indicator is activated that warns the user whenever a non-system application accesses its location, a measure designed to provide transparency and control in real time. Google has published practical guides on good practices and location permissions that developers should review: Location Permissions on Android.

To meet these updates, developers must review the use they make of the location in their applications and order only the minimum required level. In the case of specific actions that require precise location, Google suggests implementing the button using the onlyForLocationButton flag in the manifesto when the app points to Android 17 or above. If an application needs precise location persistently, the Play Developer Declaration will have to be completed to explain why the central function of the app requires such access. Google has announced that the declaration form will be available before October 2026 and that, in addition, preventive controls will be launched at the Play Console, with prior reviews starting from October 27 (according to the official calendar reported).

Another important change serves commercial security: Google will integrate a native functionality in Play Console to transfer the ownership of applications between accounts safely. The company recommends using this official route from May 27, 2026 to avoid informal transfers - such as sharing credentials or buying accounts on third-party markets - that increase the risk of fraud and loss of business control. If you need more details on how to transfer an app between developer accounts, Play's official help explains the procedure: Transfer apps to another developer account.

These privacy and control measures come in parallel to Google's investment in automated systems to detect advertising abuses. The company has emphasized that it is taking advantage of the capabilities of Gemini, its IA model, to improve the detection of malicious ads and prevent them from reaching users. According to Google, more than 99% of ads that violated policies were intercepted by their systems before they were shown, and detection based on language models and understanding of intentions allows to identify content designed to avoid traditional filters. For a context on Google's initiatives in IA and Gemini, see the official information: Introduction to Gemini, and for data on its security work in advertising, the Google security page collects relevant reports and statistics: Security in Google ads.

The figures published by Google illustrate the scale of the problem and the mitigation effort: in addition to the 8.3 billion ads blocked or deleted in 2025, the company reported the withdrawal of 602 million ads related to scams and the suspension of 4 million accounts linked to fraudulent activities in the same period. He also reported billions of restricted ads for containing or empowering content such as explicit sexual material, weapons promotion, gambling and malware. These numbers highlight how bad actors are taking advantage of automated techniques, including generation with IA, to create malicious content on a scale, and that's why Google is betting on models that detect intention as well as keywords.

What does all this mean for users and developers? For people who install apps, the change promises a more thin control over what data are shared and when, with visible signals such as the location indicator and a transparent interface for choosing contacts. For application creators, the changes involve work: reviewing permissions, updating manifests and, in certain cases, preparing and presenting justifications to Play Console if the app requires continuous access. It is also appropriate to adopt the native app transfer process to protect the business from unofficial sales and transfers. In the end, it is a transition to more limited permits and more integrated security mechanisms, designed to balance functionality and protection in an increasingly automated and complex ecosystem.