See the list below to learn the basic terminology of the Android Open Source Project (AOSP). Here are other sources for definitions of key terms:
- Android Compatibility Definition Document (CDD) Build Parameters section
- Audio terminology
- USB Audio Terminology
- Automotive Terminology
- Automotive Dialer Terminology
- Automotive Instrument Cluster Terminology
- App Developer Vocabulary
- Camera Version Terminology
- Device Tree Overlay (DTO) Terminology
- Framework Compatibility Matrix (FCM) Lifecycle Terminology
- Health Terminology
- HIDL Terminology
- Hardware-backed Keystore Terminology
- Multi-Display Terminology
See Coding with respect for examples of terminology to use and avoid for a more inclusive ecosystem.
- .apk file
- Android application package file. Each
Android application is compiled and packaged in a single file that
includes all of the application's code (.dex files), resources, assets,
and manifest file. The application package file can have any name but
must use the
.apkextension. For example:
myExampleAppname.apk. For convenience, an application package file is often referred to as an ".apk".
- A description of something that an Intent sender wants done. An action
is a string value assigned to an Intent. Action strings can be defined by Android or by a
third-party developer. For example, android.intent.action.VIEW for a Web URL, or
com.example.rumbler.SHAKE_PHONE for a custom application to vibrate the phone.
- A single screen in an application, with supporting Java code, derived
Activityclass. Most commonly, an activity is visibly represented by a full screen window that can receive and handle UI events and perform complex tasks, because of the Window it uses to render its window. Though an Activity is typically full screen, it can also be floating or transparent.
- From a component perspective, an Android application consists of one or more activities, services, listeners, and intent receivers. From a source file perspective, an Android application consists of code, resources, assets, and a single manifest. During compilation, these files are packaged in a single file called an application package file (.apk).
- Broadcast Receiver
- An application class that listens for Intents that are broadcast, rather than being sent to a single target application/activity. The system delivers a broadcast Intent to all interested broadcast receivers, which handle the Intent sequentially.
- Content Provider
- A data-abstraction layer that you can use to safely expose your
application's data to other applications. A content provider is built on
ContentProviderclass, which handles content query strings of a specific format to return data in a specific format. See Content Providers topic for more information.
Related: URI Usage in Android
- A floating window that acts as a lightweight
form. A dialog can have button controls only and is intended to perform a
simple action (such as button choice) and perhaps return a value. A dialog
is not intended to persist in the history stack, contain complex layout,
or perform complex actions. Android provides a default simple dialog for
you with optional buttons, though you can define your own dialog layout.
The base class for dialogs is
- An message object that you can use to launch or communicate with other
applications/activities asynchronously. An Intent object is an instance of
Intent. It includes several criteria fields that you can supply, to determine what application/activity receives the Intent and what the receiver does when handling the Intent. Available criteria include the desired action, a category, a data string, the MIME type of the data, a handling class, and others. An application sends an Intent to the Android system, rather than sending it directly to another application/activity. The application can send the Intent to a single target application or it can send it as a broadcast, which can in turn be handled by multiple applications sequentially. The Android system is responsible for resolving the best-available receiver for each Intent, based on the criteria supplied in the Intent and the Intent Filters defined by other applications. For more information, see Intents and Intent Filters.
- Intent Filter
- A filter object that an application declares in its manifest file, to tell the system what types of Intents each of its components is willing to accept and with what criteria. Through an intent filter, an application can express interest in specific data types, Intent actions, URI formats, and so on. When resolving an Intent, the system evaluates all of the available intent filters in all applications and passes the Intent to the application/activity that best matches the Intent and criteria. For more information, see Intents and Intent Filters.
- Nonprogrammatic application components that are external to the
compiled application code, but which can be loaded from application code
using a well-known reference format. Android supports a variety of
resource types, but a typical application's resources would consist of UI
strings, UI layout components, graphics or other media files, and so on.
An application uses resources to efficiently support localization and
varied device profiles and states. For example, an application would
include a separate set of resources for each supported local or device
type, and it could include layout resources that are specific to the
current screen orientation (landscape or portrait). For more information
about resources, see Resources
and Assets. The resources of an application are always stored in the
res/*subfolders of the project.
- An object of class
Servicethat runs in the background (without any UI presence) to perform various persistent actions, such as playing music or monitoring network activity.
- URIs in Android
- Android uses URI (uniform resource identifier) strings as the basis for requesting data in a
content provider (such as to retrieve a list of contacts) and for requesting
actions in an Intent (such as opening a Web page in a browser). The URI
scheme and format is specialized according to the type of use, and an
application can handle specific URI schemes and strings in any way it
wants. Some URI schemes are reserved by system components. For example,
requests for data from a content provider must use the
content://. In an Intent, a URI using an
http://scheme will be handled by the browser.
- Android Debug Bridge, a command-line debugging application included with the SDK. It provides tools to browse the device, copy tools on the device, and forward ports for debugging. If you are developing in Android Studio, adb is integrated into your development environment. See Android Debug Bridge for more information.
- Android project
- A Git repository on an Android Gerrit host. See Source Control Tools > Gerrit for more information.
- Build fingerprint
- The build fingerprint is a unique, human-readable string containing manufacturer information issued to each build. See Understanding build fingerprints for more information.
- The source control tool used by Android that historically operated on a single Git repository. Used in conjunction with Repo for multiple Git repositories. See Source Control Tools > Git for more information.
- Git branch - canonical
- Distinct versions for each Git repository, such as
android-11.0.0_r1, found at cs.android.com/android/platform/superproject/+/android-11.0.0_r1. See Git Branching - Branches in a Nutshell for more information.
- Git branch - local
- A temporary branch in the current Repo client to make code changes, started with the
repo start branch-name .command. an active line of development. The most recent commit on a branch is referred to as the tip of that branch.
- Git repository
- Sometimes referred to as a project, this is a portion of the codebase representing a
particular component or type of device, such as
- Manifest file
- An XML file that describes a grouping of Git repositories per branch, the Git revisions at
which to check out those repositories, and their layout on a filesystem. This XML file,
default.xml, is associated with a Repo branch and describes the Git repositories and Git branches checked out when you initialize and sync the Repo branch. This file defines the various Git repositories the Repo tool should fetch into a Repo client checkout in order to build a product (such as Android Automotive OS). See all manifests at android.googlesource.com/platform/manifest/+refs. See the default manifest included in AndroidManifest files to pull in Android platform (AOSP) files at android.googlesource.com/platform/manifest/+/refs/heads/main/default.xml. See the AndroidManifest.xml file for app information and repo Manifest Format for platform development.
- Over-the-air (OTA) update
- Android devices in the field can receive and install over-the-air (OTA) updates to the system, application software, and time zone rules. See OTA Updates for more information.
- A wrapper around Git to allow easier operations on multiple Git repositories. It aggregates and manages the many Git repositories as a singular checkout or codebase. See Source Control Tools > Repo for more information.
- Repo branch
- A collection of Git repositories captured in an AndroidManifest file
that represents a version (build) of the Android codebase, such as
aosp-android-games-sdk, downloaded via
repo synccommands. See the Manifest file description for links to all manifest files and use https://cs.android.com/ to search for their builds.
- In general, uprev updates a constituent subproject of a larger project to a newer version. An uprev changes a revision level to either the next incremented version or to the latest available version. In the case of a HIDL package, to maintain the package-level backwards-compatible extensibility, a minor-version uprev updates the new package to a higher minor version while keeping the same name and major version as the old package. In the case of the Bootloader configuration, an uprev updates the boot header version support to the latest version.
- A drawing surface that handles compositing of the actual bits against
a Bitmap or a Surface object. It has methods for standard computer
drawing of bitmaps, lines, circles, rectangles, text, and so on, and is bound to a
Bitmap or Surface. Canvas is the simplest, easiest way to draw 2D objects
on the screen. The base class is
- A compiled visual resource that can be used as a background, title, or
other part of the screen. A drawable is typically loaded into another UI
element, for example as a background image. A drawable is not able to
receive events, but does assign various other properties such as "state"
and scheduling, to enable subclasses such as animation objects or image
libraries. Many drawable objects are loaded from drawable resource files
— xml or bitmap files that describe the image. Drawable resources
are compiled into subclasses of
android.graphics.drawable. For more information about drawables and other resources, see Resources.
- Layout Resource
- An XML file that describes the layout of an Activity screen.
- Nine-patch / 9-patch / Ninepatch image
- A resizeable bitmap resource that can be used for backgrounds or other
images on the device. See
Nine-Patch Stretchable Image for more information.
- OpenGL ES
- Android provides OpenGL ES libraries for hardware-accelerated 3D rendering. For 2D
rendering, Canvas is the simpler option." OpenGL ES is available in the
Android Native Development Kit (NDK)
for ease of use. The
javax.microedition.khronos.openglespackages expose OpenGL ES functionality.
- An object of type
Surfacerepresenting a block of memory that gets composited to the screen. A Surface holds a Canvas object for drawing, and provides various helper methods to draw layers and resize the surface. You should not use this class directly; use
- A View object that wraps a Surface for drawing, and exposes methods to
specify its size and format dynamically. A SurfaceView provides a way to
draw independently of the UI thread for resource-intensive operations
(such as games or camera previews), but it uses extra memory as a result.
SurfaceView supports both Canvas and OpenGL ES graphics. The base class is
- A set of properties (text size, background color, and so on) bundled
together to define various default display settings. Android provides a
few standard themes, listed in
R.style(starting with "Theme_").
- An object that draws to a rectangular area on the screen and handles
click, keystroke, and other interaction events. A view is a base class for
most layout components of an Activity or Dialog screen (text boxes,
windows, and so on). It receives calls from its parent object (see
ViewGroup) to draw itself, and informs its parent object about where
and how big it would like to be (which may or may not be respected by the
parent). For more information, see
- View Hierarchy
- An arrangement of View and ViewGroup objects that defines the user interface for each component of an app. The hierarchy consists of view groups that contain one or more child views or view groups. You can obtain a visual representation of a view hierarchy for debugging and optimization by using the Hierarchy Viewer that is supplied with the Android SDK.
- A container object that groups a set of child views. The view group is
responsible for deciding where child views are positioned and how large
they can be, as well as for calling each to draw itself when appropriate.
Some view groups are invisible and are for layout only, while others have
an intrinsic UI (for instance, a scrolling list box). View groups are all
widgetpackage, but extend
- One of a set of fully implemented View subclasses that render form
elements and other UI components, such as a text box or popup menu.
Because a widget is fully implemented, it handles measuring and drawing
itself and responding to screen events. Widgets are all in the
- In an Android application, an object derived from the abstract class
Windowthat specifies the elements of a generic window, such as the look and feel (title bar text, location and content of menus, and so on). Dialog and Activity use an implementation of this class to render a window. You do not need to implement this class or use windows in your application.
- Android Runtime (ART) and Dalvik
- The Android runtime (ART) is the managed runtime used by applications and some system services on Android. The Android runtime (ART) is the default runtime for devices running Android 5.0 (API level 21) and higher. ART and its predecessor Dalvik were originally created specifically for the Android Open Source Project. ART as the runtime executes the Dalvik Executable format and Dex bytecode specification. ART and Dalvik are compatible runtimes running Dex bytecode, so apps developed for Dalvik should work when running with ART.
- A codeline contains the release of a software product. It consists of one or more branches from one or more repositories, all of which are often under active development at once. The codeline is the aggregation point and target for the release. For more information about codelines, see Android Software Management.
- .dex file
- Compiled Android application code file.
Android programs are compiled into .dex (Dalvik Executable) files, which are in turn zipped into a single .apk file on the device. .dex files can be created by automatically translating compiled applications written in the Java programming language.
- Artifacts are build-related logs enabling local troubleshooting. These logs are accessible
directly from Gerrit
when viewing your changelist. Scroll down to Presubmit Status and click the
red Build link to view or download the associated
build_error.logfile. You can also get these artifacts from the central Android Continuous Integration server at ci.android.com/ by clicking the Download (down arrow) icon for the target and build. For more information on how to find artifacts, see Android Continuous Integration.
- The Android Compatibility Definition Document (CDD) enumerates the requirements that must be met for your devices to be compatible with the latest version of Android. To be considered compatible with Android, device implementations MUST meet the requirements presented in this Compatibility Definition, including any documents incorporated by reference. For more information on the CDD, see Android Compatibility Definition Document.
- The Compatibility Test Suite (CTS) is the test suite for ensuring API correctness and the specification laid out in the CDD. It is available as source within AOSP and for download as a binary. For more information, see Compatibility Test Suite.
- CTS Verifier
- The Compatibility Test Suite Verifier (CTS Verifier) is a supplement to the CTS. CTS Verifier provides tests for APIs and functions that cannot be tested on a stationary device without manual input (e.g. audio quality, accelerometer, etc). For more information, see Using CTS Verifier.
- Debugging requires finding and fixing errors in Android platform code, either in features or their tests. For more information, see Debugging Native Android Platform Code
- GoogleTest (GTest)
- GTest is Google’s C++ testing and mocking framework. GTest binaries typically access lower-level abstraction layers or perform raw IPC against various system services. Because of this, the testing approach for Gtest is usually tightly coupled with the service being tested. Find the code at github.com/google/googletest and documentation at google.github.io/googletest.
- Instrumentation test
- An instrumentation test provides a special test execution environment as launched by the
am instrumentcommand, where the targeted application process is restarted and initialized with basic application context, and an instrumentation thread is started inside the application process virtual machine. For more information, see Instrumentation Tests.
- Logcat is a command-line tool that dumps a log of system messages, including stack traces
when the device throws an error and messages that you have written from your app with the
Logclass. For more information, see Logcat command-line tool.
- Logging in Android is complex due to the mix of standards used that are combined in
logcat. For details on the main standards used, see Understanding Logging.
- Merge conflict
- A merge conflict occurs when two or more versions of the same file can no longer be merged automatically by the Android build server. These usually require manual editing of the file to resolve all conflicting updates.
- Presubmit and postsubmit tests
- Presubmit tests are used to prevent failures from being introduced into the
common kernels. Results aren't publicly available at this time.
Android postsubmit tests are performed when a new patch is committed to a common kernel branch. By entering
aosp_kernelas a partial branch name, you can see a list of kernel branches with results available. For example, results for `android-mainline` can be found here.
- The Trade Federation (Tradefed or TF for short) test harness is a continuous test framework designed for running tests on Android devices. For example, Tradefed is used to run the CTS and VTS. For more information, see Trade Federation Overview.
- The Android Vendor Test Suite (VTS) provides extensive functionality for Android testing, promotes a test-driven development process, and automates HAL and OS kernel testing. For more information, see Vendor Test Suite (VTS) and Infrastructure.