Glossário da plataforma Android

Veja a lista abaixo para saber mais sobre a terminologia básica do Android Open Source Project (AOSP). Veja outras fontes para definições de termos-chave:

Seção Parâmetros de compilação do Documento para definição de compatibilidade do Android (CDD, na sigla em inglês)
Terminologia de áudio
Terminologia de áudio USB
Terminologia automotiva
Terminologia do Telefone automotivo
Terminologia de cluster de instrumento automotivo
Vocabulário do desenvolvedor de apps
Terminologia da versão da câmera
Terminologia de Sobreposição da árvore de dispositivos (DTO, na sigla em inglês)
Terminologia de ciclo de vida para a Matriz de compatibilidade de framework (FCM, na sigla em inglês)
Terminologia de integridade
Terminologia de HIDL
Terminologia de keystore protegido por hardware
Terminologia de várias telas

Consulte Programar com respeito para ver exemplos de terminologia a serem usados ou evitados para manter um ecossistema mais inclusivo.

Apps

Arquivo .apk: Arquivo de pacote de apps para Android. Cada aplicativo para Android é compilado e empacotado em um único arquivo que inclui todo o código (arquivos .dex), recursos e o arquivo de manifesto do app. O arquivo de pacote pode ter qualquer nome, mas precisa usar a extensão .apk. Exemplo: myExampleAppname.apk. Por conveniência, o arquivo de pacote de um app é geralmente denominado ".apk".
Relacionado: Aplicativo.
Ação: Descrição de algo que quem envia uma intent quer que seja feito. Uma ação é um valor de string atribuído a uma intent. As strings de ação podem ser definidas pelo Android ou por um desenvolvedor terceiro. Por exemplo, android.intent.action.VIEW para um URL da Web ou com.example.rumbler.SHAKE_PHONE para que um app personalizado faça o smartphone vibrar.
Relacionado: intent.
Atividade: Uma única tela em um app compatível com código Java e derivada da classe Activity. Geralmente, uma atividade é visivelmente representada por uma janela em tela cheia que pode receber e processar eventos de UI e realizar tarefas complexas, devido ao Windows usado na renderização. Embora uma atividade seja tipicamente exibida em tela cheia, ela também pode flutuar ou ser transparente.
Aplicativo: Da perspectiva de um componente, um aplicativo para Android consiste em um ou mais receptores de atividades, serviços, listeners e recebedores de intents. Da perspectiva do arquivo de origem, um aplicativo para Android consiste em códigos, recursos e um único manifesto. Durante a compilação, esses arquivos são empacotados em um único arquivo denominado arquivo de pacote de apps (.apk).
Relacionados: .apk, Atividade
Broadcast Receiver: Uma classe de apps que ouve intents que são transmitidas em vez de enviadas a um único app/atividade de destino. O sistema envia uma intent de transmissão para todos os broadcast receivers interessados, que processam a intent em sequência.
Relacionados: Intent, Filtro de intent.
Provedor de conteúdo: Uma camada de abstração de dados que pode ser usada para expor com segurança os dados do seu app para outros. Um provedor de conteúdo é criado na classe ContentProvider, que processa strings de consulta de conteúdo de um formato específico para retornar dados em um determinado formato. Consulte o tópico Provedores de conteúdo para saber mais.
Relacionado: uso do URI no Android
Caixa de diálogo: Uma janela flutuante que funciona como uma formulário leve. Uma caixa de diálogo pode ter apenas controles de botões e tem o objetivo de realizar uma ação simples (por exemplo, a escolha de um botão) e, talvez, retornar um valor. O objetivo de uma caixa de diálogo não é persistir na pilha de histórico, conter layout complexo ou realizar ações complexas. O Android oferece uma caixa de diálogo simples padrão com botões opcionais, embora você possa definir o próprio layout de caixa de diálogo. A classe básica para caixas de diálogos é Dialog.
Relacionado: Atividade.
Intent: Um objeto de mensagem que pode ser usado para iniciar ou se comunicar com outros apps e atividades de maneira assíncrona. Um objeto de intent é uma instância de Intent. Ele inclui vários campos de critérios que podem ser oferecidos para determinar que app ou atividade receberá a intent e o que o receptor fará quando processar a intent. Os critérios disponíveis incluem a ação visada, uma categoria, uma string de dados, o tipo MIME dos dados, uma classe de gerenciamento, entre outros. Um app envia uma intent para o sistema Android em vez de diretamente para outro app ou atividade. O app pode enviar a intent para um único app de destino ou como uma transmissão, que, por sua vez, pode ser processada por vários apps em sequência. O sistema Android é responsável por resolver o melhor receptor disponível para cada intent, com base nos critérios oferecidos e nos filtros de intent definidos por outros apps. Para saber mais, consulte Intents e filtros de intent.
Relacionados: Filtro de intent, Broadcast Receiver.
Filtro de intent: Um objeto de filtro que um app declara no arquivo de manifesto para informar ao sistema quais tipos de intent cada um dos componentes está disposto a aceitar e com quais critérios. Usando um filtro de intent, um app pode expressar interesse em tipos de dados específicos, ações de intent, formatos de URI e assim por diante. Ao resolver uma intent, o sistema avalia todos os filtros de intent disponíveis em todos os apps e transmite a intent ao app/atividade que melhor atende aos critérios. Para saber mais, consulte Intents e filtros de intent.
Relacionados: Intent, Broadcast receiver.
Recursos: Componentes de app não programáticos externos ao código compilado do app, mas que podem ser carregados do código por um formato de referência conhecido. O Android é compatível com vários tipos de recurso, mas os recursos comuns de um app consistem em strings de IU, componentes de layout de IU, gráficos ou outros arquivos de mídia etc. Um app usa recursos para oferecer compatibilidade com localização e perfis e estados variados de dispositivo. Por exemplo, um app incluiria um conjunto separado de recursos para cada tipo de local ou de dispositivo compatível e poderia incluir recursos de layout específicos para a orientação de tela atual (paisagem ou retrato). Para saber mais sobre recursos, consulte Recursos. Os recursos de um app são sempre armazenados nas subpastas res/* do projeto.
Serviço: Um objeto de classe Service que é executado em segundo plano (sem uma presença de IU) para realizar várias ações persistentes, como tocar música ou monitorar a atividade de rede.
Relacionado: Atividade
URIs no Android: O Android se baseia em strings de URI (Uniform Resource Identifier) para solicitar dados em um provedor de conteúdo (por exemplo, para recuperar uma lista de contatos) e ações em uma intent (por exemplo, abrir uma página da Web em um navegador). O formato e o esquema do URI são especializados de acordo com o tipo de uso, e um app pode processar strings e esquemas de URI específicos da maneira que quiser. Alguns esquemas de URI são reservados pelos componentes do sistema. Por exemplo, solicitações de dados de um provedor de conteúdo precisam usar o content://. Em uma intent, um URI que usa um esquema http:// será processado pelo navegador.

Build

adb: Android Debug Bridge, um app de depuração de linha de comando incluído no SDK. Ele oferece ferramentas para navegar pelo dispositivo, copiar ferramentas e encaminhar portas para depuração. Se você está desenvolvendo no Android Studio, o adb está integrado no seu ambiente para desenvolvedores. Consulte Android Debug Bridge para saber mais.
Projeto Android: Um repositório Git em um host do Android Gerrit. Consulte Ferramentas de controle de origem > Gerrit para ver mais informações.
Impressão digital da versão: A impressão digital da versão é uma string exclusiva legível por humanos que contém informações do fabricante emitidas para cada build. Consulte Noções básicas sobre impressões digitais da versão para ver mais informações.
Git: A ferramenta de controle de origem usada pelo Android que operava historicamente em um único repositório do Git. Usado em conjunto com Repo para vários repositórios Git. Consulte Ferramentas de controle de origem > Git para ver mais informações.
Ramificação Git - canônica: Versões distintas para cada repositório Git, como android-11.0.0_r1, encontradas em cs.android.com/android/platform/superproject/+/android-11.0.0_r1. Para ver mais informações, consulte Ramificações Git - Resumo de Ramificações (link em inglês).
Ramificação Git - local: Uma ramificação temporária no cliente Repo atual para fazer alterações no código, começando com o comando repo start branch-name .. Uma linha de desenvolvimento ativa. A confirmação mais recente em uma ramificação é chamada de "ponta" da ramificação.
Repositório do Git: Anteriormente chamado de projeto, ele faz parte da base do código que representa um componente ou tipo de dispositivo específico, como frameworks/base ou platform/packages/apps/Car/Media.
Arquivo de manifesto: Um arquivo XML que descreve um conjunto de repositórios Git por ramificação, as revisões do Git em que esses repositórios são conferidos e o layout deles em um sistema de arquivos. Esse arquivo XML, normalmente chamado de default.xml, está associado a uma ramificação do Repo e descreve os repositórios e ramificações Git verificados quando você inicializa e sincroniza a ramificação do Repo. Esse arquivo define os vários repositórios Git que a ferramenta Repo precisa buscar em uma finalização do cliente Repo para criar um produto (como o Android Automotive OS). Veja todos os manifestos em android.googlesource.com/platform/manifest/+refs. Veja o manifesto padrão incluído nos arquivos AndroidManifest para extrair os arquivos da Plataforma Android (AOSP) em android.googlesource.com/platform/manifest/+/refs/heads/master/default.xml. Consulte o arquivo AndroidManifest.xml para ver informações sobre o app e formato do manifesto do repo para desenvolvimento de plataformas.
Atualização over-the-air (OTA): Os dispositivos Android em uso podem receber e instalar atualizações OTA (over-the-air) no sistema, software de aplicativo e regras de fuso horário. Consulte Atualizações OTA para saber mais.
Repo: Um wrapper Git para facilitar operações em vários repositórios Git. Ele agrega e gerencia os muitos repositórios Git como uma finalização ou uma base de código única. Consulte Ferramentas de controle de origem > Repo para ver mais informações.

Ramificação repo

Uma coleção de repositórios Git capturados em um arquivo AndroidManifest que representa uma versão (build) da base do código do Android, como android11-gsi ouaosp-android-games-sdk, transferido por download por comandos repo init erepo sync. Consulte a descrição do arquivo de manifesto para ver links de todos os arquivos de manifesto e use https://cs.android.com/ para pesquisar builds deles.

Gráficos

Tela: Superfície de desenho que processa a composição dos bits reais de acordo com um objeto Bitmap ou Surface. Ela tem métodos para desenhos computacionais padrão de bitmaps, linhas, círculos, retângulos, texto e muito mais, além de ser vinculada a um Bitmap ou Surface. A tela é a maneira mais simples e fácil de desenhar objetos 2D na tela. A classe básica é Canvas.
Relacionados: Drawable, OpenGL ES, Surface.
Drawable: Um recurso visual compilado que pode ser usado como segundo plano, título ou outra parte da tela. Normalmente, um drawable é carregado em outro elemento da IU, como uma imagem de plano de fundo. Um drawable não pode receber eventos, mas atribui várias outras propriedades, como “estado” e programação, para ativar subclasses, como objetos de animação ou bibliotecas de imagens. Muitos objetos drawable são carregados de arquivos de recurso de drawable: arquivos xml ou bitmap que descrevem a imagem. Recursos de drawable são compilados em subclasses de android.graphics.drawable. Para saber mais sobre drawables e outros recursos, consulte Recursos.
Relacionados: Recursos, Canvas
Recurso de layout: Um arquivo XML que descreve o layout de uma tela de atividade.
Relacionado: Recursos
Imagem Nine-patch / 9-patch / Ninepatch: Um recurso de bitmap redimensionável que pode ser usado para planos de fundo ou outras imagens no dispositivo. Consulte Imagem expansível Nine-patch para saber mais.
Relacionado: Recursos.
OpenGL ES: O Android oferece bibliotecas OpenGL ES para renderização 3D acelerada por hardware. Para renderização 2D, Canvas é a opção mais simples. O OpenGL ES está disponível no Kit de desenvolvimento nativo do Android (NDK) para facilitar o uso. Os pacotes android.opengl e javax.microedition.khronos.opengles expõem a funcionalidade do OpenGL ES.
Relacionados: Canvas, Surface
Superfície: Um objeto de tipo Surface que representa um bloco de memória composto na tela. Um objeto Superfície evita que um objeto Canvas desenhe e oferece vários métodos auxiliares para desenhar camadas e redimensionar a superfície. Não use essa classe diretamente. Use SurfaceView.
Relacionado: Canvas
SurfaceView: Um objeto View que une um objeto Surface para fazer desenhos e expõe métodos para especificar o tamanho e o formato dinamicamente. Um SurfaceView permite desenhar de maneira independente da linha de execução de IU para operações com uso intenso de recursos, como jogos ou visualizações de câmera. No entanto, essa opção consome mais memória. O SurfaceView é compatível com gráficos Canvas e OpenGL ES. A classe básica é SurfaceView.
Relacionado: Surface
Tema: Um conjunto de propriedades (tamanho de texto, cor de plano de fundo etc.) agrupadas para definir várias configurações padrão de exibição. O Android oferece poucos temas padrão, que estão listados em R.style (começam com "Theme_").
Ver: Um objeto que é desenhado em uma área retangular na tela e processa cliques, pressionamento de teclas e outros eventos de interação. Um view é uma classe básica para a maioria dos componentes de layout em uma tela de atividade ou caixa de diálogo (caixas de texto, janelas etc.). Ele recebe chamadas do objeto pai (consulte ViewGroup) para desenhar a si mesmo e informa ao objeto pai onde quer estar e qual tamanho quer ter (o que pode ou não ser respeitado). Para saber mais, consulte View.
Relacionados: Hierarquia de visualizações, ViewGroup, Widget
Hierarquia de visualização: Uma organização de objetos View e ViewGroup que define a interface do usuário para cada componente de um app. A hierarquia consiste em grupos de visualizações que contêm uma ou mais visualizações filhas ou grupos de visualizações. Você pode conseguir uma representação visual de uma hierarquia de visualizações para depuração e otimização usando o Hierarchy Viewer, que é fornecido com o SDK Android.
Relacionados: View, ViewGroup
ViewGroup: Um objeto contêiner que agrupa um conjunto de visualizações filhas. O grupo de visualizações é responsável por decidir onde as visualizações filhas são posicionadas e qual pode ser o tamanho delas, bem como por chamar cada uma para fazer o próprio desenho quando apropriado. Alguns grupos de visualizações são invisíveis e servem apenas para layout, enquanto outros têm uma IU intrínseca (por exemplo, uma caixa de listagem de rolagem). Os grupos estão todos no pacote widget, mas estendem ViewGroup.
Relacionados: View, Hierarquia de visualização
Widget: Um dos conjuntos de subclasses View totalmente implementadas que renderizam elementos de formulário e outros componentes de IU, como caixa de texto ou menu pop-up. Como um widget é totalmente implementado, ele processa a medição e o desenho por conta própria e responde a eventos de tela. Os widgets estão todos no pacote android.widget.
Janela: Em um app Android, um objeto derivado da classe abstrata Window que especifica os elementos de uma janela genérica, como aparência (texto da barra de título, local e conteúdo dos menus etc.). A caixa de diálogo e a atividade usam uma implementação dessa classe para renderizar uma janela. Você não precisa implementar essa classe ou usar janelas no seu app.

Plataforma

Android Runtime (ART) e Dalvik: O Android Runtime (ART) é o tempo de execução gerenciado usado por apps e alguns serviços do sistema no Android. O Android Runtime (ART) é o tempo de execução padrão para dispositivos que executam o Android 5.0 (API de nível 21) e versões mais recentes. O ART e seu antecessor, Dalvik, foram originalmente criados especificamente para o Android Open Soure Project. O ART como ambiente de execução executa o formato Dalvik Executable e a especificação de bytecode do Dex. ART e Dalvik são ambientes de execução compatíveis com bytecode do Dex. Por isso, os apps desenvolvidos para o Dalvik funcionarão com o ART.
Linha de código: Uma linha de código contém o lançamento de um produto de software. Ela consiste em uma ou mais ramificações de um ou mais repositórios, todos frequentemente em desenvolvimento ativo simultâneo. A linha de código é o ponto de agregação e o destino da versão. Para mais informações sobre linhas de código, consulte Gerenciamento de software Android.
Arquivo .dex: Arquivo de código de aplicativo para Android compilado.
Os programas do Android são compilados em arquivos .dex (Dalvik Executable) que, por sua vez, são compactados em um único arquivo .apk no dispositivo. Os arquivos .dex podem ser criados usando a tradução automática de aplicativos compilados programados na linguagem Java.

Teste

Artefatos: Os artefatos são registros relacionados a builds, o que possibilita a solução local de problemas. Esses registros podem ser acessados diretamente do Gerrit ao visualizar a lista de mudanças. Role para baixo até Presubmit Status e clique no link vermelho Build para ver ou fazer o download do arquivo build_error.log associado. Você também pode ver esses artefatos no servidor central de integração contínua do Android em ci.android.com/ clicando no ícone de download (seta para baixo) para o destino e o build. Para mais informações sobre como encontrar artefatos, consulte Integração contínua do Android.
CDD: O Documento de definição de compatibilidade do Android (CDD, na sigla em inglês) enumera os requisitos que precisam ser atendidos para que os dispositivos sejam compatíveis com a versão mais recente do Android. Para serem consideradas compatíveis com o Android, as implementações de dispositivos PRECISAM atender aos requisitos apresentados nesta definição de compatibilidade, incluindo todos os documentos incorporados por referência. Para mais informações sobre o CDD, consulte o Documento de definição de compatibilidade do Android.
CTS: O conjunto de teste de compatibilidade (CTS, na sigla em inglês) é o conjunto de testes para garantir a precisão da API e a especificação apresentada no CDD. Está disponível como fonte no AOSP e para download como um binário. Para mais informações, consulte Conjunto de teste de compatibilidade.
Verificador do CTS: O Verificador do conjunto de teste de compatibilidade (Verificador do CTS) é um complemento do CTS. O Verificador do CTS oferece testes para APIs e funções que não podem ser testadas em um dispositivo fixo sem entrada manual (por exemplo, qualidade de áudio, acelerômetro etc.). Para mais informações, consulte Como usar o Verificador do CTS.
Depurar: A depuração exige localizar e corrigir erros no código da plataforma Android, seja em recursos ou nos testes. Para mais informações, consulte Depuração de código nativo da Plataforma Android
gtest: O GoogleTest é o framework de teste e simulação C++ do Google. Veja o código em github.com/google/googletest e a documentação em google.github.io/googletest (links em inglês).
Teste de instrumentação: Um teste de instrumentação oferece um ambiente de execução de teste especial, iniciado pelo comando am instrument, em que o processo do aplicativo de destino é reiniciado e inicializado com o contexto básico do aplicativo, e uma linha de execução de instrumentação é iniciada dentro da máquina virtual do processo do aplicativo. Para ver mais informações, consulte Testes de instrumentação.
Logcat: O Logcat é uma ferramenta de linha de comando que cria um registro de mensagens do sistema, incluindo stack traces, quando o dispositivo gera um erro e mensagens que você escreveu no app com a classe Log. Para ver mais informações, consulte Ferramenta de linha de comando Logcat.
Geração de registros: A geração de registro no Android é complexa devido à combinação de padrões usados no logcat. Para detalhes sobre os principais padrões usados, consulte Noções básicas sobre a geração de registros.
Conflitos de mesclagem: Um conflito de mesclagem ocorre quando duas ou mais versões do mesmo arquivo não podem mais ser mescladas automaticamente pelo servidor de compilação do Android. Isso geralmente exige a edição manual do arquivo para resolver todas as atualizações conflitantes.
Teste nativo: Um teste nativo para a plataforma geralmente acessa camadas de abstração de nível inferior ou realiza IPC bruta em vários serviços do sistema. Portanto, a abordagem de teste geralmente está rigidamente acoplada ao serviço em teste. Para mais informações, consulte Testes nativos.
Tradefed: O arcabouço de testes Trade Federation (Tradefed ou TF, na sigla em inglês) é um framework de testes contínuo e projetado para executar testes em dispositivos Android. Por exemplo, o Tradefed é usado para executar o CTS e VTS. Para mais informações, consulte a Visão geral do Trade Federation.
VTS: O Conjunto de teste de fornecedor do Android (VTS, na sigla em inglês) oferece ampla funcionalidade para testes do Android, promove um processo de desenvolvimento orientado por teste e automatiza os testes do kernel de HAL e do SO. Para mais informações, consulte Conjunto de teste de fornecedor e infraestrutura.