Glosario de la plataforma de Android

Consulta la lista que se encuentra más abajo para conocer la terminología básica del Proyecto de código abierto de Android (AOSP). A continuación, se incluyen otras fuentes para las definiciones de términos clave:

Consulta Codificación respetuosa para ver algunos ejemplos de términos que se deben usar o evitar con el objetivo de lograr un ecosistema más inclusivo.

Apps

Archivo .apk: Archivo de paquete de aplicación para Android. Cada aplicación de Android se compila y empaqueta en un solo archivo que incluye todo el código (archivos .dex) de la aplicación, los recursos, elementos y el archivo de manifiesto. El archivo del paquete de la aplicación puede tener cualquier nombre, pero debe usar la extensión .apk. Por ejemplo:myExampleAppname.apk. Por motivos prácticos, a menudo los archivos de paquetes de aplicación se denominan ".apk".
Términos relacionados: aplicación
Acción: Descripción de una tarea que un remitente de intent quiere que se realice. Una acción es un valor de string asignado a un intent. Android o un desarrollador externo pueden definir strings de acción. Por ejemplo, android.intent.action.VIEW para una URL web, o com.example.rumbler.SHAKE_PHONE para una aplicación personalizada que hace vibrar el teléfono.
Términos relacionados: intent
Actividad: Una única pantalla en una aplicación, con código Java compatible, derivada de la clase Activity. Por lo general, una actividad se representa de forma visible mediante una ventana de pantalla completa que puede recibir y controlar eventos de la IU y realizar tareas complejas gracias a la ventana que usa para renderizar su propia ventana. Aunque las actividades suelen ser de pantalla completa, también pueden ser flotantes o transparentes.
Aplicación: Desde la perspectiva de un componente, una aplicación de Android consta de una o más actividades, servicios, objetos de escucha y receptores de intents. Desde la perspectiva del archivo fuente, una aplicación de Android consta de código, recursos, activos y un único manifiesto. Durante la compilación, estos archivos se empaquetan en un único archivo denominado archivo de paquete de la aplicación (.apk).
Términos relacionados: .apk, actividad
Receptor de emisión: Clase de aplicación que escucha los intents que se emiten, en lugar de enviarlos a una única aplicación/actividad de destino. El sistema entrega un intent de emisión a todos los receptores de emisión interesados que controlan el intent de forma secuencial.
Términos relacionados: intent, filtro de intents
Proveedor de contenido: Capa de abstracción de datos que puedes usar para exponer de manera segura los datos de tu aplicación a otras aplicaciones. Un proveedor de contenido se basa en la clase ContentProvider, que controla las cadenas de consulta de contenido de un formato específico para mostrar datos en un formato determinado. Consulta el tema Proveedores de contenido para obtener más información.
Términos relacionados: uso de URI en Android
Diálogo: Ventana flotante que actúa como un formulario liviano. Un diálogo puede tener solo controles de botones y está destinado a realizar una acción simple (como la elección del botón) y tal vez mostrar un valor. Un diálogo no persiste en la pila del historial, no contiene un diseño complejo ni realiza acciones complejas. Android proporciona un diálogo simple predeterminado con botones opcionales, aunque puedes definir tu propio diseño de diálogo. La clase de base para los diálogos es Dialog.
Términos relacionados: actividad
Intent: Objeto de mensaje que puedes usar para lanzar otras aplicaciones o actividades de manera asíncrona a fin de comunicarte con ellas. Un objeto de intent es una instancia de Intent. Incluye varios campos de criterios que puedes proporcionar para determinar qué aplicación o actividad recibe el intent y qué hace el receptor cuando controla el intent. Los criterios disponibles incluyen la acción deseada, una categoría, una string de datos, el tipo de MIME de los datos, una clase de control y otros. Una aplicación envía un intent al sistema Android, en lugar de enviarlo directamente a otra aplicación o actividad. La aplicación puede enviar el intent a una sola aplicación de destino o puede enviarlo como una transmisión, que a su vez puede ser controlada por varias aplicaciones de forma secuencial. El sistema Android es responsable de resolver el mejor receptor disponible para cada intent según los criterios proporcionados en el intent y los filtros de intent definidos por otras aplicaciones. Para obtener más información, consulta Intents y filtros de intents.
Términos relacionados: filtro de intents, receptor de emisión
Filtro de intents: Objeto de filtro que una aplicación declara en su archivo de manifiesto para indicarle al sistema qué tipos de intents está dispuesto a aceptar cada uno de sus componentes y con qué criterios. A través de un filtro de intents, una aplicación puede expresar interés en tipos de datos específicos, acciones de intents, formatos de URI, etc. Cuando se resuelve un intent, el sistema evalúa todos los filtros de intents disponibles en todas las aplicaciones y pasa el intent a la aplicación o actividad que mejor coincida con el intent y los criterios. Para obtener más información, consulta Intents y filtros de intents.
Términos relacionados: intent , receptor de emisión
Recursos: Componentes de aplicación no programáticos que son externos al código de aplicación compilado, pero que se pueden cargar desde el código de aplicación utilizando un formato de referencia conocido. Android admite una variedad de tipos de recursos, pero los recursos de una aplicación típica consisten en strings de IU, componentes de diseño de IU, gráficos u otros archivos multimedia, etc. Una aplicación utiliza recursos para admitir de manera eficaz la localización y diversos perfiles y estados de dispositivos. Por ejemplo, una aplicación incluiría un conjunto separado de recursos para cada tipo local o de dispositivo admitido, y puede incluir recursos de diseño específicos de la orientación de pantalla actual (horizontal o vertical). Para obtener más información acerca de los recursos, consulta Recursos y elementos. Los recursos de una aplicación siempre se almacenan en las subcarpetas res/* del proyecto.
Servicio: Objeto de la clase Service que se ejecuta en segundo plano (sin presencia de una IU) para realizar varias acciones persistentes, como reproducir música o supervisar la actividad de la red.
Términos relacionados: actividad
URI en Android: Android utiliza strings de URI (identificador uniforme de recursos) como base a fin de solicitar datos en un proveedor de contenido (como para recuperar una lista de contactos) y para solicitar acciones en un intent (por ejemplo, abrir una página web en un navegador). El esquema y el formato de URI se especializan según el tipo de uso, y una aplicación puede controlar esquemas y strings de URI específicos como desee. Algunos esquemas de URI están reservados por los componentes del sistema. Por ejemplo, las solicitudes de datos de un proveedor de contenido deben usar content://. En un intent, el navegador controlará un URI que use un esquema http://.

Compilación

adb: Android Debug Bridge, una aplicación de depuración de línea de comandos incluida con el SDK. Proporciona herramientas a fin de explorar el dispositivo, copiar herramientas en el dispositivo y desviar puertos para depuración. Si estás desarrollando en Android Studio, adb está integrado en el entorno de desarrollo. Consulta Android Debug Bridge para obtener más información.
Proyecto de Android: Un repositorio de Git en un host de Gerrit de Android. Consulta Herramientas de control de código fuente > Gerrit para obtener más información.
Huella digital de compilación: Una string única y legible que contiene la información del fabricante que se emitió para cada compilación. Consulta Cómo interpretar las huellas digitales de compilación para obtener más información.
Git: Herramienta de control de código fuente que usa Android y que antes operaba en un solo repositorio de Git. Se usa en conjunto con Repo para administrar varios repositorios de Git. Consulta Herramientas de control de código fuente > Git para obtener más información.
Rama de Git: canónica: Diferentes versiones de cada repositorio de Git, como android-11.0.0_r1, que se encuentran en cs.android.com/android/platform/superproject/+/android-11.0.0_r1. Consulta Git Branching - Branches in a Nutshell para obtener más información.
Rama de Git: local: Rama temporal en el cliente de Repo actual para realizar cambios en el código. Se inicia con el comando repo start branch-name ., que es una línea de desarrollo activa. La confirmación más reciente se denomina la punta de la rama.
Repositorio de Git: Parte de la base de código que, a veces, se conoce como proyecto y que representa un componente o un tipo de dispositivo en particular, como frameworks/base o platform/packages/apps/Car/Media.
Archivo de manifiesto: Archivo en formato XML que describe una agrupación de repositorios de Git por rama, las revisiones de Git que se usan para obtener esos repositorios y su diseño en un sistema de archivos. Ese archivo en formato XML, generalmente llamado default.xml, está asociado a una rama de Repo y describe los repositorios de Git y las ramas de Git revisadas cuando inicializas y sincronizas la rama de Repo. Este archivo define los distintos repositorios de Git que debe usar la herramienta Repo para recuperar el resultado de un cliente de Repo a fin de compilar un producto (por ejemplo, el SO Android Automotive). Consulta todos los manifiestos en android.googlesource.com/platform/manifest/+refs. Consulta el manifiesto predeterminado que se incluye en los archivos AndroidManifest para extraer archivos de la plataforma de Android (AOSP) en android.googlesource.com/platform/manifest/+/refs/heads/master/default.xm. Consulta el archivo AndroidManifest.xml a fin de obtener información sobre la app y el formato de manifiesto del repositorio para el desarrollo de la plataforma.
Actualización inalámbrica: Los dispositivos Android en el campo pueden recibir e instalar actualizaciones inalámbricas del sistema, el software de aplicaciones y las reglas de zona horaria. Consulta Actualizaciones inalámbricas para obtener más información.
Repo: Wrapper de Git que permite realizar operaciones más sencillas en varios repositorios de Git. Agrega y administra los distintos repositorios de Git como una base de código o un resultado únicos. Consulta Herramientas de control de código fuente > Repo para obtener más información.
Rama de Repo: Colección de repositorios de Git capturada en un archivo AndroidManifest que representa una versión (compilación) de la base de código de Android, como android11-gsi o aosp-android-games-sdk. Se descarga mediante los comandos repo init y repo sync. Consulta la descripción del archivo de manifiesto para obtener vínculos a todos los archivos de manifiesto y usa https://cs.android.com/ a fin de buscar las compilaciones.
uprev: En general, uprev actualiza un subproyecto constituyente de un proyecto más grande a una versión más reciente. Un uprev cambia un nivel de revisión a la siguiente versión incrementada o a la última versión disponible. En el caso de un paquete HIDL, para mantener el nivel del paquete de retrocompatibilidad con extensibilidad, un uprev de versión secundaria actualiza el paquete nuevo a una versión secundaria superior y, al mismo tiempo, mantiene el mismo nombre y versión principal que el paquete anterior. En el caso de la configuración del bootloader, un uprev actualiza la compatibilidad de la versión del encabezado de inicio a la última versión.

Gráficos

Lienzo: Superficie de dibujo que controla la composición de los bits reales en un mapa de bits o un objeto de tipo Surface. Tiene métodos para el dibujo estándar por computadora de mapas de bits, líneas, círculos, rectángulos, texto, etc., y está vinculada a un mapa de bits o una superficie. El lienzo es la manera más sencilla de dibujar objetos en 2D en la pantalla. La clase base es Canvas.
Términos relacionados: elemento de diseño, OpenGL ES, superficie
Elemento de diseño: Recurso visual compilado que se puede usar como fondo, título u otra parte de la pantalla. Los elementos de diseño se cargan normalmente en otro elemento de la IU, por ejemplo, como imagen de fondo. Un elemento de diseño no puede recibir eventos, pero asigna varias otras propiedades, como "estado" y programación, para habilitar subclases como objetos de animación o bibliotecas de imágenes. Muchos objetos de diseño se cargan desde archivos de recursos de elementos de diseño: archivos xml o de mapa de bits que describen la imagen. Los recursos de los elementos de diseño se compilan en subclases de android.graphics.drawable. Para obtener más información sobre los elementos de diseño y otros recursos, consulta Recursos.
Términos relacionados: recursos, lienzo
Recurso de diseño: Archivo en formato XML que describe el diseño de una pantalla de actividad.
Términos relacionados: recursos
Imagen de Nine-patch/9-patch/Ninepatch: Recurso de mapa de bits de tamaño ajustable que se puede usar para fondos u otras imágenes en el dispositivo. Consulta Imagen de Nine-Patch extensible para obtener más información.
Términos relacionados: recursos
OpenGL ES: Android proporciona bibliotecas de OpenGL ES para el procesamiento en 3D acelerado por hardware. En el caso del procesamiento en 2D, lienzo es la opción más simple. OpenGL ES está disponible en el kit de desarrollo nativo (NDK) de Android para facilitar su uso. Los paquetes android.opengl y javax.microedition.khronos.opengles exponen la funcionalidad de OpenGL ES.
Términos relacionados: lienzo, superficie
Superficie: Objeto de tipo Surface que representa un bloque de memoria que se compone en la pantalla. Una superficie contiene un objeto de lienzo para dibujar y proporciona varios métodos que ayudan a dibujar capas y cambiar el tamaño de la superficie. No debes usar esta clase directamente; usa SurfaceView en su lugar.
Términos relacionados: lienzo
SurfaceView: Objeto de visualización que une una superficie para dibujar y expone métodos que permiten especificar su tamaño y su formato dinámicamente. SurfaceView proporciona una forma de dibujar independientemente del subproceso de la IU para operaciones que requieren un uso intensivo de los recursos (como juegos o vistas previas de cámara), pero, como resultado, utiliza memoria adicional. SurfaceView admite gráficos de lienzo y OpenGL ES. La clase base es SurfaceView.
Términos relacionados: superficie
Tema: Conjunto de propiedades (tamaño del texto, color de fondo, etc.) que se agrupan para definir varias opciones de configuración de visualización predeterminadas. Android proporciona algunos temas estándar, que se enumeran en R.style (comenzando por "Theme_").
Ver: Un objeto que se dibuja en un área rectangular en la pantalla y controla los clics, las combinaciones de teclas y otros eventos de interacción. Una vista es una clase base para la mayoría de los componentes de diseño de una pantalla de actividad o diálogo (cuadros de texto, ventanas, etc.). Recibe llamadas del objeto principal (consulta ViewGroup) para dibujar e informa al objeto principal sobre el lugar y el tamaño deseados (que el objeto principal puede respetar o no). Para obtener más información, consulta View.
Términos relacionados: jerarquía de vistas, ViewGroup, widget
Jerarquía de vistas: Disposición de los objetos Vista y ViewGroup que define la interfaz del usuario para cada componente de una app. La jerarquía consiste en grupos de vistas que contienen uno o más elementos secundarios o grupos de vistas. Puedes obtener una representación visual de una jerarquía de vistas para la depuración y optimización mediante el Visor de jerarquías que se proporciona con el SDK de Android.
Términos relacionados: vista, ViewGroup
ViewGroup: Objeto contenedor que agrupa un conjunto de vistas secundarias. El grupo de vistas es responsable de decidir dónde se ubican las vistas secundarias y qué tan grandes pueden ser, así como de llamar a cada una para que se genere cuando sea apropiado. Algunos grupos de vistas son invisibles y son solo para diseño, mientras que otros tienen una IU intrínseca (por ejemplo, un cuadro de lista de desplazamiento). Los grupos de vistas se encuentran en el paquete widget, pero se extienden a ViewGroup.
Términos relacionados: vista , jerarquía de vistas
Widget: Conjunto de subclases de Vista completamente implementados que procesan los elementos de forma y otros componentes de la IU, como cuadros de texto o menús emergentes. Dado que un widget se implementa por completo, controla la medición y la generación, y responde a los eventos de la pantalla. Los widgets se encuentran en el paquete android.widget.
Ventana: En una aplicación para Android, es un objeto derivado de la clase abstracta Window que especifica los elementos de una ventana genérica, como el estilo (texto de la barra de título, ubicación y contenido de los menús, etc.). El diálogo y la actividad utilizan una implementación de esta clase para renderizar una ventana. No necesitas implementar esta clase ni usar ventanas en tu aplicación.

Plataforma

Android Runtime (ART) y Dalvik: Android Runtime (ART) es el entorno de ejecución administrado que usan las aplicaciones y algunos servicios del sistema en Android. Además, es el entorno de ejecución predeterminado para dispositivos con Android 5.0 (API nivel 21) y versiones posteriores. ART y su predecesor, Dalvik, se crearon originalmente para el proyecto de código abierto de Android. ART como entorno de ejecución ejecuta el formato Dalvik Executable y la especificación de código de bytes Dex. ART y Dalvik son entornos de ejecución compatibles que ejecutan el código de bytes Dex, por lo que las apps desarrolladas para Dalvik deberían funcionar cuando se ejecuten con ART.
Línea de código: Una línea de código contiene el lanzamiento de un producto de software. Se compone de una o más ramas de uno o más repositorios, los cuales suelen estar en desarrollo activo a la vez. La línea de código es el punto de agregación y el destino de la versión. Para obtener más información sobre las líneas de código, consulta Administración del software de Android.
Archivo .dex: Archivo de código de aplicación de Android compilado.
Los programas de Android se compilan en archivos .dex (Dalvik ejecutables), que a su vez se comprimen en un solo archivo .apk en el dispositivo. Los archivos .dex se pueden crear traduciendo automáticamente las aplicaciones compiladas escritas en el lenguaje de programación Java.

Prueba

Artefactos: Los artefactos son registros relacionados con compilaciones que permiten solucionar problemas locales. Se puede acceder a estos registros directamente desde Gerrit en la vista de la lista de cambios. Desplázate hacia abajo hasta Presubmit Status y haz clic en el vínculo rojo Build para ver o descargar el archivo build_error.log asociado. También puedes obtener estos artefactos en el servidor central de integración continua de Android, en ci.android.com/. Para ello, haz clic en el ícono Descargar (flecha hacia abajo) del destino y la compilación. Puedes obtener más información para encontrar artefactos en el artículo sobre Integración continua de Android.
CDD: En el Documento de definición de compatibilidad de Android (CDD), se enumeran los requisitos que deben cumplir tus dispositivos para admitir las versiones más recientes de Android. Para que se consideren compatibles con Android, las implementaciones del dispositivo DEBEN cumplir con los requisitos que se presentan en esta definición de compatibilidad, incluidos los documentos que se incorporan como referencia. Para obtener más información sobre el CDD, consulta el documento de definición de compatibilidad de Android.
CTS: El conjunto de pruebas de compatibilidad (CTS) es un conjunto de pruebas para garantizar la corrección de la API y la especificación establecida en el CDD. Está disponible como fuente dentro de AOSP y se puede descargar como objeto binario. Para obtener más información, consulta el Conjunto de pruebas de compatibilidad.
Verificador del CTS: El verificador del Conjunto de pruebas de compatibilidad (verificador del CTS) es un complemento del CTS. El verificador del CTS proporciona pruebas para las API y las funciones que no se pueden probar en un dispositivo fijo sin entradas manuales (p. ej., calidad de audio, acelerómetro, etcétera). Para obtener más información, consulta Cómo usar el verificador del CTS.
Depuración: La depuración requiere encontrar y corregir errores en el código de la plataforma de Android, ya sea en las funciones o sus pruebas. Para obtener más información, consulta Cómo depurar código nativo en la plataforma de Android.
GoogleTest (GTest): GTest es el framework de prueba y simulación de C++ de Google. Por lo general, los objetos binarios de GTest acceden a capas de abstracción de nivel inferior o realizan IPC sin procesar con varios servicios del sistema. Debido a esto, el enfoque de prueba para Gtest suele estar estrechamente relacionado con el servicio que se prueba. Encuentra el código en github.com/google/googletest y en la documentación de google.github.io/googletest.
Prueba de instrumentación: Una prueba de instrumentación proporciona un entorno de ejecución de prueba especial, que inicia el comando am instrument, en el que el proceso de la aplicación de destino se reinicia y se inicializa con el contexto de aplicación básico, y se inicia un subproceso de instrumentación dentro la máquina virtual del proceso de aplicación. Para obtener más información, consulta Pruebas de instrumentación.
Logcat: Logcat es una herramienta de línea de comandos que vuelca un registro de mensajes del sistema, incluidos los seguimientos de pila cuando el sistema muestra un error y los mensajes que escribes desde tu app con la clase Log. Para obtener más información, consulta la herramienta de línea de comandos Logcat.
Registro: El proceso de registro en Android es complejo debido a la combinación de estándares que se combinan en logcat. Para obtener detalles sobre los estándares principales que se usan, consulta Cómo comprender el registro.
Conflicto de combinación: Un conflicto de combinación se produce cuando el servidor de compilaciones de Android ya no puede combinar automáticamente dos o más versiones del mismo archivo. Por lo general, debes editar manualmente el archivo para resolver todas las actualizaciones en conflicto.
Pruebas antes y después del envío: Las pruebas antes del envío se usan para evitar que se introduzcan fallas en los kernels comunes. Los resultados no están disponibles para el público en este momento.

Las pruebas después del envío de Android se realizan cuando se confirma un nuevo parche en una rama de kernel común. Si ingresas aosp_kernel como nombre de rama parcial, podrás ver una lista de ramas de kernel con resultados disponibles. Por ejemplo, los resultados de "android-mainline" se pueden encontrar aquí.
Tradefed: El agente de prueba Trade Federation (Tradefed o TF para abreviar) es un framework de pruebas continuas diseñado para ejecutar pruebas en dispositivos Android. Por ejemplo, Tradefed se usa para ejecutar CTS y VTS. Para obtener más información, consulta Descripción general de Trade Federation.
VTS: El Conjunto de pruebas de proveedores de Android (VTS) ofrece una amplia funcionalidad para las pruebas de Android, promueve un proceso de desarrollo basado en pruebas y automatiza las pruebas del kernel de HAL y OS. Para obtener más información, consulta Conjunto de pruebas de proveedores (VTS) e infraestructura.