The following sections describe types of bugs that are considered low severity because they have a limited impact on user security. We appreciate if they are reported so they can be fixed, but they are not eligible for rewards.

App crashes

If a bug does nothing but make an app crash, and doesn't prevent the app from restarting, it is not eligible, as it does not have a meaningful impact on users' security.

If, however, a bug leads to the app crashing every time it is started, the issue might be eligible for the VRP as an abuse-related Denial of Service attack, depending on the exact nature of the bug.

Phishing and social engineering attacks

Like on many platforms, it is possible to write apps that look similar to other apps on Android. Unless an attack involving social engineering uses unintended functionality and is very compelling, it will likely not qualify.

Logging sensitive data

We aim to keep Android logs free of personally identifiable information, but since debugging privileges are required to access logs, an app logging sensitive data is not considered a severe enough vulnerability to qualify.

Apps requesting excessive permissions

We sometimes receive reports that applications request permissions that they do not use, or use for minor functionality. While we sometimes remove permissions as a result of these reports, excessive permissions alone do not have enough of a security impact to qualify for a reward.

An app stores not-very-sensitive data as world-readable

It is a vulnerability if an app stores sensitive data in a world-readable file, but make sure the data is actually sensitive before you report. In addition, if the amount of information disclosed is tiny (for example, the length in seconds of the last media track played), it's probably not eligible for a reward.

Side-channel attacks

We receive many reports of side-channel attacks that allow data to be inferred from unrelated functionality. Two significant factors affect the eligibility and severity of a reported side-channel information leak: the type of information being leaked and the reliability of the side-channel.

See the Android Severity Guidelines for an indication of how different types of data leaks are assessed. Generally, the information being leaked must cross a security boundary. For example, if an Android Permission is required to obtain the data under under normal circumstances, then the leak is likely a security issue. However, in some cases, Permissions are used to prevent apps from calling certain System APIs, but the APIs themselves don't provide any security-critical information. In those cases, side-channels that leak that information would not be considered security issues.

Also, for a side-channel attack to be eligible, it needs to be reliable under real-world circumstances, not just in an isolated test environment. For example, many machine learning models perform well when supplied individual events, but they're unable to produce meaningful results when faced with the continuous stream of data you'd find on a device being used by a real person.

Hardware attacks

If an issue requires attacking the hardware of a device, for example removing a chip from the PCB or connecting to the device via JTAG, it is usually out of scope of VRP.

Developer mode bugs

Some bugs require the device to have developer options enabled. These options are not accessible on most devices without having physical access to the unlocked device, so related bugs are considered low severity and are not eligible for VRP.