Android
is an operating system for a wide array of devices with different
form factors. The documentation and source code for Android is available to
anyone as the
Android Open Source Project (AOSP)
. You can use
AOSP to create custom variants of the Android OS for your own devices.
AOSP is designed so that there's no central point of failure, where one
industry player restricts or controls the innovations of another. Therefore,
AOSP is a full, production-quality developer product with source code open for
customization and porting.
This section of documentation helps new AOSP developers get started with the
platform and to perform essential development tasks.
Required terms
Following is a list of terms and definitions used throughout this get started
documentation. You should study each definition before continuing further.
- Android app developer
Android app developers writes
Android apps
or applications that run on
Android. There are two classification of app developers: first party (1p) and
third-party (3p) app developers.
- Android 1p app developer
- An Android app developer that has access to AOSP System APIs and writes
privileged and device manufacturer apps.
- Android 3p app developer
- An Android app developer who solely uses Android's public SDK to create
Android apps.
If you want to develop 3p apps for Android, refer to
developers.android.com
. The information on
this website is solely for those working directly with AOSP.
- Android debug bridge (ADB)
- A command-line tool (
adb
) that allows your workstation communicate with a
virtual, software-emulated, or physical device.
- Android-compatible device
- A device that can run any third-party app written by third-party developers
using the Android SDK and NDK. Android-compatible devices must adhere to the
requirements of the
Compatibility Definition Document (CDD)
and pass the
Compatibility Test Suite (CTS)
. Android-compatible
devices are eligible to participate in the Android ecosystem which includes
potential licensure of the Android Play Store, potential licensure the
Google Mobile Services (GMS)
suite of
applications and APIs, and use of the Android trademark. Anyone is welcome to
use the Android source code, but to be considered part of the Android ecosystem,
a device must be Android-compatible. For further information on compatibility
and CTS, see the
Android Compatibility Program overview
- Approver
- Experienced members of AOSP community who have made significant technical and
design contributions to the platform. In the code-review process, an approver
decides whether to include a change. Project leads (who are typically employed
by Google) choose the approvers, sometimes promoting verifiers to
approver positions when they demonstrate expertise on a specific part of AOSP.
- Compatibility Definition Document (CDD)
- A document that enumerates the software and hardware requirements for an
Android-compatible device.
- Contributor
A person who also makes contributions to the AOSP source code. Contributors
can be employees of Google, employees from other companies, and individuals
with no company affiliation. Every AOSP contributor uses the same tools, follows
the same code review process, and is subject to the same coding style. You
you don't have to be a contributor to use AOSP; you can download AOSP,
modify it for your own needs, and deploy it on a device without contributing
code for others to use.
There are limits to the type of code contributions Google accepts. For example,
you might want to contribute an alternative application API, such as a full
C++-based environment. Google would decline that contribution because Android
encourages applications to be run in the ART runtime. Similarly, Google doesn't
accept contributions such as GPL or LGPL libraries that are incompatible with
licensing goals.
If you are interested in contributing source code,
contact Google
prior to beginning work.
- Compatibility Test Suite (CTS)
A free, commercial-grade test suite, available for download as a binary or as
source in AOSP. The CTS is a set of unit tests designed to be integrated into
your daily workflow. CTS's intent is to reveal incompatibilities, and ensure
that the software remains compatible throughout the development process.
- Cuttlefish
A configurable virtual Android-powered device that can run remotely, using
third-party cloud offerings, such as Google Cloud Engine, and locally on Linux
x86 machines.
- Developer
In the context of AOSP, a developer is anyone who works with AOSP in any
way. The term "developer" is used to generically refer to the various people who
might read this documentation, such as original equipment manufacturers
(OEMs), handset makers, carriers, and System-on-a-Chip (SoC) creators.
- Google Mobile Services (GMS)
A collection of Google apps and APIs that can be pre-installed on devices.
- Target
A permutation of a device, such as a specific model or form factor. For
example,
aosp_cf_x86_64_phone-userdebug
represents a x86 65MB phone with
debugging information that is designed to run on the cuttlefish emulator.
- Verifier
A valued contributor in the Android community who downloads and verifies
changes to AOSP. After you have submitted a significant amount of high-quality
code to AOSP, the project leads might invite you to become a verifier.
Governance philosophy
A group of companies known as the Open Handset Alliance (OHA), led by Google,
originated Android. Today, many companies?both original members of the OHA and
others?have invested heavily in Android. These companies have allocated
significant engineering resources to improve Android and bring Android devices
to market.
The companies that have invested in Android have done so because they believe an
open platform is necessary. Android is intentionally and explicitly an open
source effort (as opposed to free software); a group of organizations with
shared needs has pooled resources to collaborate on a single implementation of a
shared product. First and foremost, the Android philosophy is pragmatic. The
objective is a shared product that each contributor can tailor and customize.
Of course, uncontrolled customization can lead to incompatible implementations.
To prevent incompatibility, the Android Open Source Project (AOSP) maintains
the
Android Compatibility program
,
which spells out what it means to be Android-compatible and what's required of
device builders to achieve that status. Anyone can use the Android source code
for any purpose, and Google welcomes all legitimate uses. However, to take part
in the shared ecosystem of applications OHA members are building around Android,
device builders must participate in the Android Compatibility program.
AOSP is led by Google, who maintains and further develops Android. Although
Android consists of multiple subprojects, AOSP is strictly project management.
Google views and manage Android as a single, holistic software product, not a
distribution, specification, or collection of replaceable parts. Google's intent
is that device builders port Android to a device; they don't implement a
specification or curate a distribution.
What's next?