Google Play Policy Update -Regarding Sensitive Information
Mobile applications in mobile devices are empowered by the user according to their unique functions and roles. For example, map apps ask for permission to collect location information, voice recording apps ask for microphone access, and calling apps to ask for permission to access contact information. However, if the user incorrectly allows these rights, it is dangerous because there is a risk of personal information exposure and becoming a target for hacking.
To learn more about application 'permissions,' including this QUERY_ALL_PACKAGES, we will cover the 'permissions' policy regarding APIs and access rights to sensitive information among Google Play's Developer Program policies. First, let's take a closer look at the permissions Google restricts and what requirements are required to use them.
Google Play has published an updated Developer Program Policy effective May 11, 2022. Unless otherwise specified, a grace period will apply to all new and existing apps for at least 30 days from May 11 to ensure compliance with the changes (except for policies with an otherwise stated effective date). Applications that do not meet the policy requirements or fail to submit the permission request form may result in removal from Google Play. So let's take a closer look at the permissions restricted by Google and the requirements required to use them.
SMS and call log permission cannot be acquired unless the app has the main function of calling or texting. This is because it has a possibility to be abused your authorization to make voice calls or access phone records, you can eavesdrop on users' calls or make calls at will. Therefore, SMS and call logging rights are considered personal and sensitive user data and are subject to the following restrictions.
- If you no longer need the app's current functions or services, the app should not access data(example: ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_BACKGROUND_LOCATION) protected by location information access to information access.
- Do not ask users to access location information only for advertising or analysis purposes. If your app extends the acceptable use of location data for advertising, you must comply with Google's advertising policy.
- The app should request the minimum range (i.e., the foreground instead of the background, etc.) required to provide the current function or service that requires a location. The user should reasonably expect the location level requested for the function or service. For example, Google can request a background location without solid evidence or reject an app that accesses it.
- Background location access is helpful to users and can only be used to provide functions relevant to the app's core functionality.
An app can access a location using a foreground service (If the app has only foreground access, ex: 'Only during use') permission to access the location.
- The use of a location started as an extension of the user-initiated in-app operation.
- The use of the location ends immediately after the user-initiated action in the application has been completed for its intended purpose.
Your access to files and directories contains sensitive personal information. You need to set permissions by subdividing permissions such as app control and READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STRAGE for access to photos, videos, and audios.
- Apps should only request access to device storage, which is essential for operation, and cannot request access to device storage on behalf of a third party for purposes that are not relevant to the critical features displayed to users.
- To manage access to shared storage, Android devices running R (Android 11, API level 30) or higher require the MANAGE_EXTERNAL_STORAGE permission. Any app that targets R and requests extensive access to shared storage ('All File Access') must pass the appropriate access review before publishing. Apps that are allowed to use this privilege should clearly prompt users to enable 'All File Access' for the app according to the 'Special App Access' setting.
Accessibility API
The following describes when the Accessibility API cannot be used.
- Block features that allow users to change user settings or disable or remove apps or services without their permission (except when approved by parents or guardians through a child protection app or by an authorized administrator through corporate management software).
- Bypassing Android's built-in privacy settings and notifications.
- Change or use the user interface in a manner that is deceptive or otherwise in violation of Google Play developer policies.
In addition, the Accessibility API is not created for remote call recording and cannot be requested for this purpose, and the use of the Accessibility API must be specified in the Google Play properties.
If an app with direct support for the disabled is a key feature, you can use the IsAccessibility Tool to specify that it is a direct accessibility app using an open and appropriate method. If you can provide the features you need without using the Accessibility API, you need to narrow down and use limited APIs and authority. (Effective date: 11 July 2022)
Package (App) Visibility Permission (QUERY_ALL_PACKAGES)
Starting with Android 11, a new permission called 'Wide App Visibility (QUERY_ALL_PACKAGES)' has been added. This is the authority to see a list of all applications installed on your device. Usually, if you run an app and need other apps to interact with each other, you will be granted this privilege to ensure that other apps are installed. For example, when you run a bank app, the virus vaccine turns on together.
However, these authorities may have to be included depending on the application. Still, if the app's core function does not require these privileges, you should limit the ability to verify the apps installed on the device.
The following is a list of permissions that Google Play allows.
- Apps that search for devices
- An anti-virus vaccine
- File Management App
- An Internet browser
Financial applications related to banks and digital wallets have also been given temporary exceptions, allowing some permission to check for installation only on a list of apps installed for security purposes, such as vaccines. This is because the financial application can be used normally only when the vaccine is installed on the device and then executed.
This authority must submit a declaration of app usage rights as below, or you will not be able to submit an app update from July 12th. Therefore, we need to update the app by July 12th.
Access sensitive information when applying LIAPP
Looking at this 'Permissions' update policy, you might think that LIAPP must be declared to use permission to detect application security threats. Recently, services that offer most app security features have announced the use of rights through the Play Console due to Google's policy changes. They recommend the use of the QUERY_ALL_PACKAGES permission to prevent apps from running in dangerous environments by detecting the installation of blacklisted cheat apps as one of the ways to block app tampering/attacking.
However, since the QUERY_ALL_PACKAGES permission contains quite sensitive information, it limits the ability to check the installed apps on the device unless the app's core function requires this permission. Furthermore, even if you request to use this permission, if Google refuses it, the app will not be registered, or the existing app will be deleted.
In order to use this permission, security procedures such as form filling, screening, and refusal of application site registration are required. However, unlike these existing security apps, LIAPP can detect and block application hacking, tampering, and threats in advance without using limited permissions, according to Google Play's policy. Currently, LIAPP detects threat behaviors that are not in the way of inquiring about installed apps and responds so that security is not threatened even if the QUERY_ALL_PACKAGES permission is deleted.
LIAPP detects apps based on threat behavior rather than checking installed apps, therefore it protects them without using the QUERY_ALL_PACKAGES permission.
Now, it’s time to meet LIAPP's advanced security features that works based on the behavior. LIAPP adheres to Google Play's restrictive policies to protect mobile apps from hackers.
If you are thinking about implementing a security service to your mobile app, or if you have difficulties using permissions related to security features due to Google policy updates, please feel free to contact the TEAM LIAPP and we will properly guide you with details.
