This page contains Help content for SDK providers using Google Play SDK Console.
If you're an app developer looking for Google Play Console Help content, use the search bar or return to the homepage.
You can use SDK Console to stay on top of potential policy issues or security vulnerabilities affecting your SDK versions. It's important to stay on top of these kinds of issues to keep Google Play safe, and to avoid potential negative consequences for your SDKs. These can include the removal of its registration badge or restricted access to features in Google Play SDK Console.
SDK versions with potential policy issues
If you have SDK versions that are known to cause apps using them to violate our SDK Requirements policy or other Google Play Developer Program policies, these versions will be labeled in SDK Console. New app versions published on Google Play using these versions will be rejected, and developers will be instructed to find a compliant version before resubmitting their app.
The screenshot below shows an example of an SDK version with a policy violation highlighted:
The screenshot below shows an example of the expanded SDK version, which details the reported issue:
In accordance with the SDK Console Terms of Service, if a policy issue is found in your SDK, you will be notified and guided on how to fix it and submit a new SDK version for review. Once the enforcement process on existing apps is complete, SDK Console will label the problematic SDK versions as non-policy-compliant, and new app versions that contain it won’t be able to be released until they switch to a compliant version.
Potential consequences for repeated SDK-related policy violations
Google Play is committed to fostering a safe and trusted ecosystem for both developers and users. As part of this commitment, we’re implementing an enhanced approach to curtail repeat violations of Google Play policies caused by SDKs:
Depending on the severity and the frequency of the violations, consequences may include, but are not limited to:
- Removal of registration badge: Repeat violations and/or the severity of the violation may lead to removal of the registration badge displayed on Google Play SDK Index. The badge indicates that the SDK is registered in Google Play SDK Console and the provider of this SDK has accepted the Google Play SDK Console Terms of Service, which includes a commitment that their SDKs will not cause apps to violate Google Play policies.
- Restricted access to features in Google Play SDK Console: In cases of SDKs causing repeated policy violations by app developers or the severity of the violation by the SDK, we reserve the right to remove access to key features in SDK Console.
Note: SDK providers can still inquire about any decision. To find out more, read this Help Center article on using SDKs safely and securely and Google Play's Developer Program Policy.
SDK versions with potential security vulnerabilities
A vulnerability is a weakness or flaw within the code that could be exploited by a malicious actor. SDK Console informs you about potential security vulnerabilities affecting your SDK versions. Below you can find information about vulnerabilities that may affect your SDK, and how to fix them.
How to fix SDKs that contain unsafe encryption patterns
Your SDK contains unsafe encryption patterns. That is, a ciphertext is generated with a statically computed secret key, salt, or initialization vector (IV).
If an app uses your SDK, it will receive an alert in Play Console. To prevent apps that use your SDK from getting alerts, you must fix the vulnerability in your SDK.
Review the steps below to fix the issue in your SDK. You can find the unsafe encryption code locations in the SDK Console notification for your SDK.
Additional details
Review your SDK for statically computed keys, initialization vectors, and/or salts that are used in encryption operations and ensure that these values are constructed safely. For example, the following code uses a statically computable secret key and a statically computable initialization vector:
// Console alert refers to this method
public byte[] encryptionUtil(String key, String iv, byte[] plainText) {
Cipher cipher = Cipher.getInstance(“AES/GCM/NoPadding”);
SecretKeySpec keySpec = new SecretKeySpec(key.getBytes(), “AES”);
GCMParameterSpec paramSpec = new GCMParameterSpec(256, iv.getBytes());
cipher.init(Cipher.ENCRYPT_MODE, keySpec, paramSpec);
return cipher.doFinal(plainText);
}
// The unsafe key and initialization vector are here and should be changed
byte[] cipherText = encryptionUtil(“abcdef...”, “010203040506”, plainText);
Statically Computed Values
A statically computed value is a value that is the same on every execution of a function. Statically computed values can be extracted from your SDK and used to attack an app’s encrypted data. Even if you manipulate keys, initialization vectors, and salts in complex ways before use, they remain unsafe if these manipulations are the same for every program execution.
Android Best Practices
We recommend that you utilize Jetpack Security for symmetric cryptography. If your SDK encrypts API keys, personally identifiable information (PII), or other sensitive data, EncryptedSharedPreferences can be used to securely store this data without worrying about the implementation of secret keys, initialization vectors, and salts. Further best practices and examples are available on this page. For securely transmitting data to other systems, developers should use TLS/SSL to secure data in transmission.
Jetpack Security utilizes the Google open source project Tink to handle symmetric authenticated encryption. For advanced use cases concerning lower level operations, we suggest using Tink directly.
If the aforementioned Android best practices do not meet your use case, and you are required to explicitly manage keys, initialization vectors, and salts, then we recommend following these standards:
- Secret Keys: Symmetric secret keys must be unpredictable and secret. For encrypting local data, developers should construct secret keys using cryptographically secure randomness (or from user generated data, if using PBEKeySpecs) and store the secret keys using the AndroidKeystore.
- Initialization Vectors: Initialization vectors must be unique and unpredictable across multiple messages but do not need to be secret. Developers should construct initialization vectors using cryptographically secure randomness. Developers should store or transmit the initialization vectors along with the associated ciphertext.
- Salts: Salts must be unique and unpredictable across multiple hashes but do not need to be secret. Developers should construct salts using cryptographically secure randomness. Developers should store or transmit the salts along with the associated hashes.
How to fix SDKs that use less secure encryption modes
Your SDK contains encryption employing the less secure mode AES/ECB. Encrypting content using this weak mode can lead to weak ciphertexts, and potentially put user data at risk.
If an app uses your SDK, it will receive an alert on Play Console.To prevent apps that use your SDK from getting alerts, you must fix the vulnerability in your SDK.
Review the steps below to fix the issue in your SDK. You can find the code locations of the less secure encryption modes in the SDK Console notification for your SDK.
Additional details
Review your SDK for the location where a Cipher is instantiated. The following configuration modes will imply the usage of insecure AES/ECB:
"AES"
"AES/ECB/NoPadding"
"AES/ECB/PKCS5Padding"
"AES/ECB/ISO10126Padding"
For example the following code uses AES/ECB mode by default because "AES" was provided:
// Console alert refers to this method
public byte[] encryptionUtil(String key, String iv, byte[] plainText) {// Employs AES/ECB mode by default
Cipher cipher = Cipher.getInstance(“AES”);
SecretKeySpec keySpec = new SecretKeySpec(key.getBytes(), “AES”);
cipher.init(Cipher.ENCRYPT_MODE, keySpec, paramSpec);
cipher.init(Cipher.ENCRYPT_MODE, keySpec, paramSpec);
return cipher.doFinal(plainText);
}
Google recommends that developers use “AES/GCM/NoPadding” instead of the aforementioned insecure mode.
How to fix SDKs containing code that is vulnerable to Zip Path Traversal
Code in your SDK contains unsafe unzipping patterns, which may lead to a Zip Path Traversal attack.
If an app uses your SDK, it will receive an alert on Play Console. To prevent apps that use your SDK from getting alerts, you must fix the vulnerability in your SDK.
Review the detailed steps below to fix the issue in your SDK. You can find the unsafe zipping patterns code locations in the SDK Console notification for your SDK.
Additional details
Zip files can contain an entry (file or directory) that contains path traversal characters (“../”) in its name. If developers unzip such zip file entries without validating their name, it can potentially cause a path traversal attack, leading to writes in arbitrary directories or even overwriting the files in an app's private folders.
We recommend fixing this issue in your SDK by checking if canonical paths to unzipped files are underneath an expected directory. Specifically, before using a File object created using the return value of ZipEntry's getName() method, always check if the return value of File.GetCanonicalPath() belongs to the intended directory path. For example:
InputStream is = new InputStream(untrustedFileName);// SecurityException
ZipInputStream zis = new ZipInputStream(new BufferedInputStream(is));
while((ZipEntry ze = zis.getNextEntry()) != null) {
File f = new File(DIR, ze.getName());
String canonicalPath = f.getCanonicalPath();
if (!canonicalPath.startsWith(DIR)) {
}// Finish unzipping...
}
How to fix SDKs that contain an Implicit PendingIntent vulnerability
Your SDK contains an Implicit PendingIntent issue which may cause security threats in the form of denial-of-service, private data theft, and privilege escalation.
If an app uses your SDK, it will receive an alert on Play Console.To prevent apps that use your SDK from getting alerts, you must fix the vulnerability in your SDK.
Please review the detailed steps below to fix the issue in your SDK. You can find code locations of Implicit PendingIntent usages in the SDK Console notification for your SDK.
Additional details
Android apps send messages between components using Intents. Intents can either specify the target component (Explicit Intent) or list a general action and let the operating system deliver the Intent to any component on the device that registers an Intent Filter matching that action (Implicit Intent).
PendingIntents are Intents delegated to another app to be delivered at some future time. Creating an implicit intent wrapped under a PendingIntent is a security vulnerability that might lead to denial-of-service, private data theft, and privilege escalation.
Review your SDK for the location where a PendingIntent is created. For example, the following code creates a PendingIntent wrapping an implicit Intent:
// Create an implicit base Intent and wrap it in a PendingIntent
Intent base = new Intent("ACTION_FOO");
base.setPackage("some_package");
PendingIntent pi = PendingIntent.getService(this, 0, base, 0);
Google recommends that developers fix the vulnerability by applying any (or even better, all) of the following:
- Ensuring that the action, package, and component fields of the base Intent are set;
- Ensuring that the PendingIntent is only delivered to trusted components;
- Using FLAG_IMMUTABLE (added in SDK 23) to create PendingIntents. This prevents apps that receive the PendingIntent from filling in unpopulated properties. In case the app also runs on devices running SDK 22 or older, we recommend developers to apply the previous options while strengthening the PendingIntent creation with the pattern:
if (android.os.Build.VERSION.SDK_INT >= 23) {
// Create a PendingIntent using FLAG_IMMUTABLE
} else {
// Existing code that creates a PendingIntent
}
How to fix SDKs that contain an Implicit Internal Intent vulnerability
Your SDK contains an Implicit Internal Intent issue. Implicit Intents used to reach an internal component allow attackers to intercept the message and either drop it, read its contents, or even replace its contents.
If an app uses your vulnerable SDK, it will receive an alert on Play Console.To prevent apps that use your SDK from getting alerts, you must fix the vulnerability in your SDK.
Review the detailed steps below to fix the issue in your SDK. You can find the location(s) of the Implicit Intent usage(s) in your SDK can be found in the SDK Console notification for your SDK.
Additional details
Review your SDK for the location where an Implicit Intent is used. For example the following code uses Implicit Intents to reach an internal component:
//The app has a component that registers MY_CUSTOM_ACTION, which is only
//registered by this app, indicating that the dev intends for this Intent;
//to be delivered to the internal component safely.
Intent intent = new Intent("MY_CUSTOM_ACTION");
//Add potentially sensitive content to 'intent'
intent.putExtra("message", sensitive_content);
startActivity(intent);
Google recommends that developers use Explicit Intents to reach their internal components either by:
- Use Intent.setComponent to explicitly set the component to handle the Intent.
- Use Intent.setClass or Intent.setClassName to explicitly set the target component.
- Use Intent.setPackage to limit the components this Intent will resolve to.
How to fix SDKs that contain vulnerable JavaScript libraries
Your SDK contains one or more JavaScript libraries with known security issues (for example, common vulnerabilities and exposures — CVEs). Including such vulnerable libraries in your SDK can put app users at risk.
If an app uses your vulnerable SDK, it will receive an alert on Play Console. To prevent apps that use your SDK from getting alerts, you must fix the issue in your SDK.
Review the detailed steps below to fix the issue in your SDK. You can find a list of detected unsafe libraries and their versions used in your SDK in the SDK Console notification for your SDK.
Additional details
To resolve this issue, you can take one of the following three actions for each detected unsafe library:
- Use an up-to-date version of the library: If your SDK has a direct dependency on the detected unsafe version of a library, and the security issue has been resolved in the latest version of that library, rebuilding the SDK with the latest version will resolve the issue.
- Contact the library developer: Possibly the library is still maintained but the security issue has not yet been fixed. It is also possible that your SDK has a transitive dependency on the detected unsafe library (that is, the SDK directly depends on a library, which in turn depends on the unsafe library). Under such circumstances, contact the library developer to fix the issue.
- Find an alternative: If the unsafe library with one or more security issues is no longer maintained, please find and use a safe alternative library.
How to fix SDKs that use WebViews for authentication
Your SDK uses WebView for authentication, which is not recommended. Using WebViews for OAuth 2.0 requests negatively affects both the security and usability of apps that use your SDK. Review the steps below to fix the issue in your SDK.
If an app uses your SDK, it will receive an alert on Play Console. To prevent apps that use your SDK from getting alerts, you must fix the vulnerability in your SDK.
You can find code locations of OAuth 2.0 requests via WebViews in your SDK in the SDK Console notification for your SDK.
Additional details
Since the release of Chrome Custom Tabs, Google has recommended that developers move away from using WebViews for authentication. Using OAuth for authentication in a WebView can make apps that use your SDK susceptible to security problems and hurt usability by disconnecting the user from single sign-on sessions. Chrome Custom Tabs mitigate these issues.
- Review your SDK for the location where an OAuth 2.0 request is done via WebView.
- Google recommends that developers replace this WebView with a Chrome Custom Tab. Follow the steps in the Chrome Custom Tabs implementation guide to add a Chrome Custom Tab to your SDK.
- Use the added Chrome Custom Tab to now perform the OAuth 2.0 request.
How to fix SDKs that leak GCP API keys
Your SDK contains exposed Google Cloud Platform (GCP) API key(s). If you embed GCP API keys in your SDK, those keys will become publicly available. This exposure of your API keys could lead to unexpected charges and quota changes in your SDK’s GCP account.
If an app uses your vulnerable SDK, it will receive an alert on Play Console. To prevent apps that use your SDK from getting alerts, you must fix the vulnerability in your SDK.
Review the detailed steps below to fix the issue in your SDK. You can find locations of exposed GCP API keys in your SDK in the SDK Console notification for your SDK.
Additional Details
We recommend fixing this issue in your SDK using one of the following ways:
- If possible, use GCP service accounts instead of GCP API keys for authenticating your app. A GCP service account is a Google account associated with your GCP project. More details on creating and using service accounts can be found here.
- Add restrictions to your API key so that only your SDKs/apps are allowed to use the API key. More details on adding restrictions to API keys can be found here. (Please Note: If you have already added restrictions to your API key, you can ignore this warning.)