Some reports contain bugs that have a negligible security impact. The following sections describe types of bugs that do not have a meaningful security impact on Android and will not be accepted.

Decompiling/reverse engineering an app

Most applications (including Android apps) can be reverse engineered. While this can be a good technique for finding bugs, in itself, being able to determine internal information about how an application works is not a vulnerability.

SQL injection in content providers with no privilege boundary

It's not uncommon for unexpected input to cause SQL errors in content providers. However, this is only a security issue if it can be used to escalate privileges.

For example, if an application has permissions to read and write contacts and can use SQL injection to read and write contacts, it is not an issue because its permissions allow that access anyhow. However, if it has read permissions and can use SQL injection to write, this is a security issue.

Issues that only occur on rooted devices or the emulator

Rooted devices and emulators do not have the same security boundaries as regular devices. Bugs that only occur when a device is rooted are not eligible.

Triggering a local temporary Denial of Service

For example, you can write an app that causes the phone to crash and reboot. If you can resolve the crash by removing the app and rebooting the phone, then this issue is not eligible.

Apps that trigger the crash on boot are also not eligible, because they can be removed by booting the phone into safe mode, which prevents any third-party apps from running on boot (steps to do this on Pixel can be found under Pixel Phone Help).

If, on the other hand, you find an issue that requires a Factory Reset to fix, or if you can trigger the reboot remotely (e.g. via a malformed media file on a website), then it qualifies as a security issue.

Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen

Apps that have SYSTEM_ALERT_WINDOW permissions are generally able to create overlays over any screen, if that screen doesn't prevent them. Android system screens that deal with security-sensitive approvals are typically protected against overlays. Android R added additional restrictions so that, for most apps, users need to grant this permission manually and acknowledge that the app is able to overlay other screens. Because of this, overlays are generally considered to have been approved by the user and do not meet the bar as Android Platform security issues, but abusive apps may be reviewed and removed from the Play Store.

The exceptions to this that would meet the bar as security issues are for overlays that:

• Interfere with the user's ability to understand or approve a Permission.
• Interfere with App Installation approval.
• Hide a persistent sensor icon or equivalent privacy-sensitive notification (e.g. icons shown when recording audio/video).

There are ways to hide a device from Find My Location

There may be multiple ways to hide a device from Find My Location, such as waiting for the battery to run out, hiding the device in a building with no signal, and so on. This is why Factory Reset Protection will not allow devices to be reset without approval from the owner of the device. Reports that demonstrate ways to hide a device from Find My Device do not meet the bar as security issues.

If, however, you find a vulnerability that allows a Factory Reset without the owner's approval on a supported device, that would qualify as a security issue.

Unreachable bugs

It may appear that a piece of code is vulnerable, but further examination of the code paths that reach that code shows that they contain checks that would prevent the vulnerability. For example, a function may appear vulnerable to out-of-bounds reads or writes because it's missing length checks, but if you find that all functions in the Android platform that call into it already include those length checks, and there's no other way to call the vulnerable function, then that is not an exploitable security bug. Be especially careful if you're building a Proof of Concept (PoC) that links to a library and calls functions directly, if those functions would not be callable directly when using normal Android APIs. You might be able to demonstrate a crash or HWASAN memory violation within your own PoC, but it would not be reachable in the system processes that use that library using the APIs they provide.

If you're providing a report based on a code audit, without a PoC, please include enough information in the code audit to show that the code is reachable in a vulnerable way. That is, show that there's a code path that would be reached in normal operation where the parameters could be set to trigger the vulnerability.

Cellular bugs using a Test PLMN

For bug disclosures about cellular and/or modem vulnerabilities, they must be reproducible with a SIM that is not set up to a test Public Land Mobile Network (PLMN) code (for example: 01-001). Test PLMNs might bypass security checks that would protect the phone under normal usage.