This section contains recommendations to ensure the security of apps on
Android devices.
Source code review
Source code review can detect a broad range of security issues, including
those identified in this document. Android strongly encourages both manual
and automated source code review.
- Follow comprehensive security guidance when conducting reviews to ensure
coverage. Utilize relevant internal or external standards to ensure
consistent and complete reviews.
- Run a linter, such as the
Android Studio linter
, on all app code using the
Android SDK and correct any identified issues.
- Analyze native code using an automated tool that can detect memory
management issues, such as buffer overflows and off-by-one errors.
- The Android build system supports many of the LLVM sanitizers, such as
AddressSanitizer
and
UndefinedBehaviorSanitizer
,
which can be used for runtime analysis of memory-related issues. Combined
with fuzzing, supported in Android through
libFuzzer
, sanitizers can
uncover unusual edge cases requiring further investigation.
- A knowledgeable security assessor should review higher risk code, such as
crypto, payment processing, and PII processing.
Automated testing
Automated testing can help detect a broad range of security issues and
should be performed regularly.
- Run the latest version of
CTS
regularly
throughout the development process to detect problems early and reduce time
to correction. Android uses CTS as part of continuous integration in our
automated build process, which builds multiple times per day.
- Automate security testing of interfaces, including testing with malformed
inputs (fuzz testing). Android's build system supports
libFuzzer
for writing fuzz
tests.
Vulnerability scanning
Vulnerability scanning can help ensure that pre-installed apps are free of
known security vulnerabilities. Advanced detection can reduce the time and
cost required with addressing these vulnerabilities and preventing risk to
users and devices.
- Scan all pre-installed apps using an industry-recognized app
vulnerability scanning tool and address detected vulnerabilities.
Potentially Harmful Applications
It is important to ensure that the pre-installed apps on your device aren't
Potentially
Harmful Applications
(PHAs). You are responsible for the behavior of all
apps that are included on your devices. Prior to device launch, scan all
pre-loaded apps for vulnerabilities.
For more information about PHAs and how Google is combating them in the
Play store see the
Google Play Protect
developer documentation
.
App installation and permissions
Excessive permissions for pre-installed apps can create a security risk.
Restrict pre-installed apps to the minimum necessary permissions and ensure they
don't have access to unnecessary permissions or privileges. App permissions are
described in the
AndroidManifest.xml
.
- Do not grant unnecessary permissions or privileges to pre-installed
apps. Thoroughly review apps with system privileges as they may have very
sensitive permissions.
- Ensure that all permissions requested are relevant and necessary for the
functionality of that specific app.
- Ensure there is user disclosure for all pre-installed apps that use the
INSTALL_PACKAGES
permission.
- Ensure that the developer is contractually obligated not to install any apps
as UID 0.
- Evaluate permissions declared in the manifest of all apps to be installed
through the developer's network.
- Ensure that the developer is contractually obligated to scan all download
URLs of auto-updater and installer apps with
Google Safe Browsing API
before serving apps to the device.
App signing
App signatures play an important role in device security and are used for
permissions checks and software updates. When selecting a key to use for
signing apps, it is important to consider whether an app will be available
only on a single device or common across multiple devices.
- Ensure that apps are not signed with a key that is publicly known, such
as the AOSP developer key.
- Ensure that keys used to sign apps are managed in a manner consistent
with industry-standard practices for handling sensitive keys, including an
hardware security module (HSM) that provides limited, auditable access.
- Ensure that apps are not signed with the platform key. Doing so gives an
app access to platform signature permissions, which are very powerful and
only intended to be used by components of the operating system. System apps
should use privileged permissions.
- Ensure that apps with the same package name are not signed with different
keys. This often occurs when creating an app for different devices,
especially when using the platform key. If the app is device-independent,
use the same key across devices. If the app is device-specific, create
unique package names per device and key.
Isolating apps and processes
The Android
sandboxing model
provides extra security around apps and processes when used correctly.
Isolating root processes
Root processes are the most frequent target of privilege escalation attacks;
reducing the number of root processes reduces risk of privilege escalation.
- Ensure that devices run the minimum necessary code as root. Where
possible, use a regular Android process rather than a root process. If a
process must run as root on a device, document the process in an AOSP
feature request so it can be publicly reviewed.
- Where possible, root code should be isolated from untrusted data and
accessed via interprocess communication (IPC). For example, reduce root
functionality to a small Service accessible via Binder and expose the
Service with signature permission to an app with low or no privileges to
handle network traffic.
- Root processes must not listen on a network socket.
- Root processes must not include a general-purpose runtime, such as a Java
VM).
Isolating system apps
In general, pre-installed apps should not run with the shared system unique
identifier (UID). If it is necessary for an app to use the shared UID of
system or another privileged service (e.g., phone), the app should not export
any services, broadcast receivers, or content providers that can be accessed
by third-party apps installed by users.
- Ensure devices run the minimum necessary code as system. Where possible,
use an Android process with its own UID rather than reusing the system UID.
- Where possible, system code should be isolated from untrusted data and
expose IPC only to other trusted processes.
- System processes must not listen on a network socket. This is a CTS
requirement.
Isolating processes
The Android Application Sandbox provides apps with an expectation of
isolation from other processes on the system, including root processes and
debuggers. Unless debugging is specifically enabled by the app and the user,
no app should violate that expectation.
- Ensure root processes do not access data within individual app data
folders, unless using a documented Android debugging method.
- Ensure root processes do not access memory of apps, unless using a
documented Android debugging method.
- Ensure devices do not include any app that accesses data or memory of
other apps or processes.