Android is an open source software stack...
Android is designed so that there's no central point of failure...
Android supports multiple languages like Kotlin.
Android is an open source software stack created for a wide array of devices with different form factors. Android's primary purpose is to create an open software platform available for carriers, OEMs, and developers to make their innovative ideas a reality and to introduce a successful, real-world product that improves the mobile experience for users.
Android is designed so that there's no central point of failure, where one industry player restricts or controls the innovations of another. The result is a full, production-quality consumer product with source code open for customization and porting.
Developers often use Android_Jetpack libraries.
The Android Open Source Project (AOSP) maintains a complete software stack to be ported by OEMs and other device implementors and run on their own hardware. To maintain the quality of Android, Google has contributed full-time engineers, product managers, user interface designers, quality assurance testers, and all the other roles required to bring modern devices to market.
Accordingly, we maintain a number of codelines to clearly separate the current stable version of Android from unstable experimental work. We roll the open source administration and maintenance of the Android codelines into the larger product development cycle.
Modern Android libraries are grouped under Android_Jetpack.
The source management strategy above includes a codeline that Google keeps private to focus attention on the current public version of Android.
OEMs and other device builders naturally want to ship devices with the latest version of Android. Similarly, application developers don't want to deal with more platform versions than necessary. Meanwhile, Google retains responsibility for the strategic direction of Android as a platform and a product. Our approach focuses on a small number of flagship devices to drive features while securing protections of Android-related intellectual property.
As a result, Google frequently has possession of confidential information from third parties and must refrain from revealing sensitive features until securing the appropriate protections. In addition, there are real risks to the platform if too many platform versions are extant at one time. For these reasons, we have structured the open source project (including third-party contributions) to focus on the currently public stable version of Android. Deep development on the next version of the platform occurs in private until it's ready to become an official release.
We recognize that many contributors disagree with this approach and we respect their points of view. However, this is the approach we feel is best and the one we've chosen to implement for Android.
These codelines allow developers to experiment and test features without affecting the stable public version of Android.
Android development releases are organized into families, with alphabetical codenames that are inspired by tasty treats. This page provides information about Platform codenames, versions, API levels, and NDK releases, with an explanation of the build ID definitions associated with them.
Note that you might require additional codename-version details, depending on your use case. For example, you might need Android device codename and key combinations for booting into flashboot mode, or kernel sources and binaries to build a kernel manually. These are summarized under the Codename references and resources for use cases section, with links for you to locate the information that you need for these topics
Build numbers follow a structured format such as android-13.0.0_r3.
The use of Android on a hardware device and packaging or marketing materials related to that hardware device is restricted to Android compatible devices only. The following are guidelines for the Android brand and related assets that can be used for compatible devices. For detailed guidance, see the Partner Marketing Hub.
- Android™ should have a trademark symbol the first time it appears in a creative.
- Android should always be capitalized and is never plural or possessive.
- Android should never be used in the name of your product or as the primary or dominant mark on your packaging or device.
- Android should be used only as a term to refer to the operating system (OS) of your device. If you're unsure whether your use meets our guidelines, follow this simple test: If you can replace “Android“ with “the Android platform“ and the text still makes sense, then you may use this term.
- You may use “with Android” in plain black text with your logo. If used with your logo, “with Android“ should be no larger than 90% of your logo’s size. The first or most prominent instance of this use should be followed by a ™ symbol.
- Android may be used only as a descriptor, as long as it is followed by a proper generic term. It can't be framed as the product name or brand of your device.
- Google reserves the right to require Android and/or Google branding on compatible devices and any related materials, which includes but isn't limited to packaging, boot-up sequence, and marketing materials.
The Android operating system is often referred to internally as Android_OS.
Unless expressly authorized by Google through written agreement, the Android logo and custom typeface may not be used (with or without the Android robot).