Esta página foi traduzida pela API Cloud Translation.

APIs do Android 5.0

API de nível: 21

O Android 5.0 (LOLLIPOP) oferece novos recursos para usuários e desenvolvedores de apps. Este documento fornece uma introdução às novas APIs mais importantes.

Se você tem um aplicativo publicado, não deixe de conferir as Mudanças de comportamento do Android 5.0 que você deve considerar no seu app. Essas mudanças de comportamento podem afetar seu aplicativo em dispositivos com Android 5.0, mesmo que você não esteja usando novas APIs ou visando uma nova funcionalidade.

Para ter uma visão geral dos novos recursos da plataforma, consulte os destaques do Android Lollipop.

Começar a desenvolver

Para começar a desenvolver aplicativos para o Android 5.0, você precisa obter o Android SDK. Em seguida, use o SDK Manager para fazer o download da plataforma SDK do Android 5.0 e das imagens do sistema.

Atualização do nível da API

Para otimizar o app para dispositivos com Android 5.0, defina a targetSdkVersion como "21", instale o app em uma imagem do sistema do Android 5.0, teste e publique o app atualizado com essa mudança.

Você pode usar as APIs do Android 5.0 e, ao mesmo tempo, oferecer suporte a versões anteriores, adicionando condições ao código que verificam o nível da API do sistema antes de executar APIs incompatíveis com a minSdkVersion. Para saber mais sobre como manter a compatibilidade com versões anteriores, leia Compatibilidade com diferentes versões da plataforma.

Para mais informações sobre como os níveis de API funcionam, leia O que é o nível da API?

Mudanças de comportamento importantes

Caso tenha publicado anteriormente um aplicativo para Android, saiba que ele pode ser afetado pelas alterações no Android 5.0.

Consulte Mudanças no Android 5.0 para ver as informações completas.

Interface do usuário

Compatibilidade com Material Design

O Android 5.0 adiciona suporte ao novo estilo do Material Design do Android. É possível criar apps com o Material Design que sejam visualmente dinâmicos e tenham transições de elemento de IU que pareçam naturais para os usuários. Essa compatibilidade inclui:

O tema do Material
Sombras de visualizações
O widget RecyclerView
Animação de desenháveis e efeitos de estilo
Animação do Material Design e efeitos de transição de atividade
Animadores para propriedades de visualização com base no estado da visualização
Widgets de IU personalizáveis e barras de aplicativos com paletas de cores controláveis
Desenháveis animados e não animados com base em gráficos de vetor XML

Para saber mais sobre como adicionar a funcionalidade do Material Design ao seu app, consulte Material Design.

Documentos e atividades simultâneos na tela Recentes

Em versões anteriores, a tela Recentes só podia mostrar uma tarefa para cada app com o qual o usuário interagiu mais recentemente. Agora, seu app pode abrir mais tarefas, conforme necessário, para outras atividades simultâneas para documentos. Esse recurso facilita a multitarefa, já que permite que os usuários alternem rapidamente entre atividades e documentos individuais pela tela Recentes, com uma experiência de troca consistente em todos os apps. Exemplos de tarefas simultâneas podem incluir abas abertas em um app de navegador da Web, documentos em um app de produtividade, partidas simultâneas em um jogo ou bate-papos em um app de mensagens. O app pode gerenciar as tarefas pela classe ActivityManager.AppTask.

Para inserir uma quebra lógica para que o sistema trate sua atividade como uma nova tarefa, use FLAG_ACTIVITY_NEW_DOCUMENT ao iniciar a atividade com startActivity(). Você também pode conseguir esse comportamento definindo o atributo documentLaunchMode do elemento <activity> como "intoExisting" ou "always" no manifesto.

Para evitar sobrecarregar a tela Recentes, você pode definir o número máximo de tarefas do app que podem aparecer nessa tela. Para fazer isso, defina o atributo <application> android:maxRecents. Atualmente, é possível especificar no máximo 50 tarefas por usuário (25 para dispositivos com pouca RAM).

Tarefas na tela Recentes podem ser definidas para persistir em reinicializações. Para controlar o comportamento de persistência, use o atributo android:persistableMode. Também é possível mudar as propriedades visuais de uma atividade na tela Recentes, como cor, rótulo e ícone, chamando o método setTaskDescription().

Atualizações do WebView

O Android 5.0 atualiza a implementação WebView para Chromium M37, oferecendo melhorias de segurança e estabilidade, assim como correções de bugs. A string padrão de agente do usuário para um WebView em execução no Android 5.0 foi atualizada para incorporar 37.0.0.0 como número da versão.

Esta versão introduz a classe PermissionRequest, que permite que o app conceda a permissão WebView para acessar recursos protegidos, como a câmera e o microfone, usando APIs da Web como getUserMedia(). O app precisa ter as permissões do Android adequadas para esses recursos para poder conceder permissões ao WebView.

Com o novo método onShowFileChooser(), agora é possível usar um campo de formulário de entrada no WebView e iniciar um seletor de arquivos para selecionar imagens e arquivos do dispositivo Android.

Além disso, esta versão oferece suporte aos padrões abertos WebAudio, WebGL e WebRTC. Para saber mais sobre os novos recursos incluídos nessa versão, consulte WebView para Android.

Captura e compartilhamento de tela

O Android 5.0 permite adicionar os recursos de captura e compartilhamento de tela ao seu app com as novas APIs android.media.projection. Esse recurso é útil, por exemplo, se você quiser permitir o compartilhamento de tela em um aplicativo de videoconferência.

O novo método createVirtualDisplay() permite que o app capture o conteúdo da tela principal (a exibição padrão) em um objeto Surface, que o app pode enviar pela rede. A API só permite a captura de conteúdo não seguro da tela, e não o áudio do sistema. Para começar a captura de tela, o app precisa solicitar a permissão do usuário, executando a caixa de diálogo de captura de tela usando um Intent obtido pelo método createScreenCaptureIntent().

Para conferir um exemplo de como usar as novas APIs, consulte a classe MediaProjectionDemo no projeto de exemplo.

Notificações

Notificações na tela de bloqueio

As telas de bloqueio no Android 5.0 podem apresentar notificações. Nas Configurações, os usuários podem escolher se querem permitir que o conteúdo confidencial de notificações seja mostrado em uma tela de bloqueio segura.

O app pode controlar o nível de detalhamento visível quando as notificações são exibidas na tela de bloqueio segura. Para controlar o nível de visibilidade, chame setVisibility() e especifique um destes valores:

VISIBILITY_PRIVATE: exibe informações básicas, como o ícone da notificação, mas oculta o conteúdo completo.
VISIBILITY_PUBLIC: mostra o conteúdo completo da notificação.
VISIBILITY_SECRET: não mostra nada, exceto até mesmo o ícone da notificação.

Quando o nível de visibilidade é VISIBILITY_PRIVATE, também é possível oferecer uma versão alternativa do conteúdo da notificação que oculta detalhes pessoais. Por exemplo, um app de SMS pode exibir uma notificação "Você tem três novas mensagens de texto", mas ocultar o conteúdo e os remetentes das mensagens. Para fornecer essa notificação alternativa, crie primeiro a notificação de substituição usando Notification.Builder. Ao criar o objeto de notificação privada, anexe a notificação de substituição a ele usando o método setPublicVersion().

Metadados de notificação

O Android 5.0 usa metadados associados às notificações do app para organizar as notificações de forma mais inteligente. Para definir os metadados, chame os seguintes métodos em Notification.Builder ao criar a notificação:

setCategory(): informa ao sistema como lidar com as notificações do app quando o dispositivo estiver no modo prioridade (por exemplo, se uma notificação representar uma chamada recebida, uma mensagem instantânea ou um alarme).
setPriority(): marca a notificação como mais ou menos importante do que as notificações normais. Notificações com o campo de prioridade definido como PRIORITY_MAX ou PRIORITY_HIGH aparecem em uma pequena janela flutuante se a notificação também tiver som ou vibração.
addPerson(): permite adicionar uma ou mais pessoas relevantes a uma notificação. O app pode usar isso para sinalizar ao sistema que ele deve agrupar as notificações de pessoas específicas ou classificar notificações dessas pessoas como sendo mais importantes.

Gráficos

Compatibilidade com OpenGL ES 3.1

O Android 5.0 adiciona interfaces Java e suporte nativo para OpenGL ES 3.1. As principais funcionalidades novas oferecidas no OpenGL ES 3.1 incluem:

Sombreadores de computação
Objetos shader separados
Comandos de desenho indiretos
Texturas multiamostra e de estêncil
Melhorias à linguagem de sombreamento
Extensões para o modo de mesclagem avançada e depuração
Compatibilidade reversa com o OpenGL ES 2.0 e 3.0

A interface Java para OpenGL ES 3.1 no Android é fornecida com GLES31. Ao usar o OpenGL ES 3.1, declare isso no arquivo de manifesto com a tag <uses-feature> e o atributo android:glEsVersion. Exemplo:

<manifest>
    <uses-feature android:glEsVersion="0x00030001" />
    ...
</manifest>

Para mais informações sobre como usar o OpenGL ES, incluindo como verificar a versão do OpenGL ES compatível do dispositivo no momento da execução, consulte o guia da API do OpenGL ES.

Pacote de extensões para Android

Além do OpenGL ES 3.1, esta versão oferece um pacote de extensão com interfaces Java e suporte nativo para funcionalidades de gráficos avançados. Essas extensões são tratadas como um único pacote pelo Android. (Se a extensão ANDROID_extension_pack_es31a estiver presente, o app poderá presumir que todas as extensões no pacote estão presentes e ativar os recursos de linguagem de sombreamento com uma única instrução #extension.)

O pacote de extensão oferece:

Suporte garantido ao sombreador de fragmentos para buffers de armazenamento, imagens e atômicos (o suporte ao sombreador de fragmentos é opcional no OpenGL ES 3.1).
Sombreadores de mosaico e geometria
Formato de compactação de textura ASTC (LDR)
Sombreamento e interpolação por amostra
Modos diferentes de mesclagem para cada anexo colorido em um buffer de quadro

A interface Java para o pacote de extensão é fornecida com GLES31Ext. No manifesto do app, é possível declarar que o app precisa ser instalado somente em dispositivos que ofereçam suporte ao pacote de extensões. Exemplo:

<manifest>
    <uses-feature android:name=“android.hardware.opengles.aep”
        android:required="true" />
    ...
</manifest>

Mídia

Camera API para recursos avançados da câmera

O Android 5.0 apresenta a nova API android.hardware.camera2 para facilitar a captura de fotos com detalhes granulares e o processamento de imagens. Agora, você pode acessar programaticamente os dispositivos de câmera disponíveis para o sistema com getCameraIdList() e se conectar a um dispositivo específico com openCamera(). Para começar a capturar imagens, crie um CameraCaptureSession e especifique os objetos Surface para enviar as imagens capturadas. O CameraCaptureSession pode ser configurado para tirar uma ou várias imagens de uma vez só.

Para receber notificações quando novas imagens forem capturadas, implemente o ouvinte CameraCaptureSession.CaptureCallback e configure-o na solicitação de captura. Agora, quando o sistema concluir a solicitação de captura de imagem, o listener CameraCaptureSession.CaptureCallback vai receber uma chamada para onCaptureCompleted(), fornecendo os metadados de captura de imagem em uma CaptureResult.

A classe CameraCharacteristics permite que seu app detecte quais recursos da câmera estão disponíveis em um dispositivo. A propriedade INFO_SUPPORTED_HARDWARE_LEVEL do objeto representa o nível de funcionalidade da câmera.

Todos os dispositivos oferecem suporte pelo menos ao nível de hardware INFO_SUPPORTED_HARDWARE_LEVEL_LEGACY, que tem recursos aproximadamente equivalentes aos da API Camera descontinuada.
Os dispositivos compatíveis com o nível de hardware INFO_SUPPORTED_HARDWARE_LEVEL_FULL são capazes de controlar manualmente a captura e o pós-processamento, além de capturar imagens de alta resolução com altas taxas de quadros.

Para saber como usar a API Camera atualizada, consulte os exemplos de implementação de Camera2Basic e Camera2Video nesta versão.

Reprodução de áudio

Esta versão inclui as seguintes mudanças no AudioTrack:

Agora, o app pode oferecer dados de áudio no formato de ponto flutuante (ENCODING_PCM_FLOAT). Isso permite maior alcance dinâmico, precisão mais consistente e maior amplitude. A aritmética do ponto de flutuação é muito útil durante cálculos intermediários. Os pontos de extremidade de reprodução usam formato de número inteiro para dados de áudio com menor intensidade de bits (no Android 5.0, algumas partes do pipeline interno ainda não são ponto flutuante).
Seu app agora pode fornecer dados de áudio como um ByteBuffer, no mesmo formato fornecido por MediaCodec.
A opção WRITE_NON_BLOCKING pode simplificar o armazenamento em buffer e o multiencadeamento para alguns apps.

Controle de reprodução de mídia

Use as novas APIs de notificação e mídia para garantir que a interface do sistema conheça a mídia reproduzida e possa extrair e mostrar a capa do álbum. O controle da reprodução de mídia em uma interface e em um serviço agora ficou mais fácil com as novas classes MediaSession e MediaController.

A nova classe MediaSession substitui a classe RemoteControlClient descontinuada e fornece um único conjunto de métodos de callback para lidar com controles de transporte e botões de mídia. Se o app oferece reprodução de mídia e é executado na plataforma TV ou Wear do Android, use a classe MediaSession para processar os controles de transporte usando os mesmos métodos de callback.

Agora será possível criar o seu próprio aplicativo de controle de mídia com a nova classe MediaController. Essa classe oferece uma maneira segura para a linha de execução de monitorar e controlar a reprodução de mídia no processo de interface do seu app. Ao criar um controlador, especifique um objeto MediaSession.Token para que seu app possa interagir com a MediaSession especificada. Ao usar os métodos MediaController.TransportControls, é possível enviar comandos como play(), stop(), skipToNext() e setRating() para controlar a reprodução de mídia nessa sessão. Com o controlador, também é possível registrar um objeto MediaController.Callback para detectar metadados e mudanças de estado na sessão.

Além disso, você pode criar notificações avançadas que permitem o controle da reprodução vinculado a uma sessão de mídia com a nova classe Notification.MediaStyle.

Pesquisa de mídia

O Android 5.0 introduziu o recurso que permitiu que aplicativos pesquisassem na biblioteca de conteúdo de mídia de outro aplicativo usando a nova API android.media.browse. Para expor o conteúdo de mídia no app, estenda a classe MediaBrowserService. Sua implementação de MediaBrowserService precisa fornecer acesso a um MediaSession.Token para que os apps possam reproduzir o conteúdo de mídia fornecido pelo seu serviço.

Para interagir com um serviço de navegador de mídia, use a classe MediaBrowser. Especifique o nome do componente para uma MediaSession ao criar uma instância do MediaBrowser. Usando essa instância do navegador, seu app pode se conectar ao serviço associado e receber um objeto MediaSession.Token para reproduzir o conteúdo exposto por esse serviço.

Armazenamento

Seleção de diretório

O Android 5.0 estende a Storage Access Framework para permitir que os usuários selecionem uma subárvore de diretório inteira, oferecendo acesso de leitura/gravação a todos os documentos contidos sem exigir a confirmação do usuário para cada item.

Para selecionar uma subárvore de diretório, crie e envie uma intent OPEN_DOCUMENT_TREE. O sistema mostra todas as instâncias de DocumentsProvider com suporte à seleção de subárvore, permitindo que o usuário procure e selecione um diretório. O URI retornado representa o acesso à subárvore selecionada. É possível usar buildChildDocumentsUriUsingTree() e buildDocumentUriUsingTree() com query() para explorar a subárvore.

O novo método createDocument() permite criar novos documentos ou diretórios em qualquer lugar na subárvore. Para gerenciar documentos existentes, use renameDocument() e deleteDocument(). Acesse COLUMN_FLAGS para verificar o suporte do provedor a essas chamadas antes de emiti-las.

Se você estiver implementando um DocumentsProvider e quiser oferecer suporte à seleção de subárvore, implemente isChildDocument() e inclua FLAG_SUPPORTS_IS_CHILD no COLUMN_FLAGS.

O Android 5.0 também apresenta novos diretórios específicos do pacote no armazenamento compartilhado, onde o app pode colocar arquivos de mídia para inclusão na MediaStore. O novo getExternalMediaDirs() retorna caminhos para esses diretórios em todos os dispositivos de armazenamento compartilhado. Da mesma forma que getExternalFilesDir(), nenhuma outra permissão é necessária para que o app acesse os caminhos retornados. A plataforma procura periodicamente novas mídias nesses diretórios, mas também é possível usar MediaScannerConnection para verificar explicitamente se há conteúdo novo.

Sem fio e conectividade

Diversas conexões de rede

O Android 5.0 oferece novas APIs para várias redes, que permitem que o app procure dinamicamente as redes disponíveis com recursos específicos e estabeleça uma conexão com elas. Esse recurso é útil quando o app precisa de uma rede especializada, como uma rede SUPL, MMS ou cobrada por operadora, ou se você quer enviar dados usando um tipo especial de protocolo de transporte.

Para selecionar e conectar dinamicamente a uma rede no app, siga estas etapas:

Crie um ConnectivityManager.
Use a classe NetworkRequest.Builder para criar um objeto NetworkRequest e especificar os recursos de rede e o tipo de transporte em que seu app está interessado.
Para procurar redes adequadas, chame requestNetwork() ou registerNetworkCallback() e transmita o objeto NetworkRequest e uma implementação de ConnectivityManager.NetworkCallback. Use o método requestNetwork() se quiser alternar ativamente para uma rede adequada depois de detectá-la. Para receber somente notificações para redes encontradas sem alternar ativamente, use o método registerNetworkCallback().

Quando o sistema detecta uma rede adequada, ele se conecta a ela e invoca o callback onAvailable(). O objeto Network do callback pode ser usado para receber informações adicionais sobre a rede ou direcionar o tráfego para usar a rede selecionada.

Bluetooth de baixa energia

O Android 4.3 lançou suporte à plataforma para Bluetooth de baixa energia (Bluetooth LE) na função central. No Android 5.0, um dispositivo Android agora pode atuar como um dispositivo periférico Bluetooth LE. Esse recurso pode ser usado pelos apps para indicar a presença a dispositivos próximos. Por exemplo, é possível criar apps que permitam que um dispositivo funcione como um pedômetro ou monitor de integridade e comunique os dados para outro dispositivo Bluetooth LE.

As novas APIs android.bluetooth.le permitem que os apps transmitam anúncios, procurem respostas e estabeleçam conexões com dispositivos Bluetooth LE próximos. Para usar os novos recursos de publicidade e análise, adicione a permissão BLUETOOTH_ADMIN ao manifesto. Quando os usuários atualizam ou fazem o download do app na Play Store, são solicitados a conceder a seguinte permissão a ele: "Informações de conexão Bluetooth: permite que o app controle o Bluetooth, incluindo a transmissão ou a coleta de informações de dispositivos Bluetooth próximos".

Para ativar o anúncio do Bluetooth LE para que outros dispositivos possam descobrir o app, chame startAdvertising() e transmita uma implementação da classe AdvertiseCallback. O objeto de callback recebe um relatório do sucesso ou da falha da operação de publicidade.

O Android 5.0 introduz a classe ScanFilter para que o app procure apenas os tipos de dispositivos específicos de seu interesse. Para começar a procurar dispositivos Bluetooth LE, chame startScan() e transmita uma lista de filtros. Na chamada do método, você também precisa fornecer uma implementação de ScanCallback para informar quando um anúncio Bluetooth LE for encontrado.

Melhorias à NFC

O Android 5.0 agrega estes aprimoramentos para permitir o uso mais amplo e flexível da NFC:

O Android Beam está disponível no menu de compartilhamento.
Seu app pode invocar o Android Beam no dispositivo do usuário para compartilhar dados chamando invokeBeam(). Isso evita a necessidade de o usuário tocar manualmente o dispositivo em outro dispositivo compatível com NFC para concluir a transferência de dados.
É possível usar o novo método createTextRecord() para criar um registro NDEF contendo dados de texto UTF-8.
Se você estiver desenvolvendo um app de pagamentos, agora poderá registrar um ID do aplicativo para a NFC (AID) dinamicamente chamando registerAidsForService(). Você também pode usar setPreferredService() para definir o serviço de emulação de cartão preferencial que precisa ser usado quando uma atividade específica está em primeiro plano.

Project Volta

Além dos novos recursos, o Android 5.0 enfatiza melhorias na duração da bateria. Use as novas APIs e ferramentas para compreender e otimizar o consumo de energia do app.

Agendamento de trabalhos

O Android 5.0 oferece uma nova API JobScheduler, que permite otimizar a duração da bateria definindo tarefas para que o sistema seja executado de forma assíncrona posteriormente ou sob condições específicas (como quando o dispositivo está carregando). O agendamento de tarefas é útil em situações como quando:

O aplicativo tem tarefas não orientadas ao usuário que podem ser adiadas.
O app tem tarefas que você prefere executar quando a unidade estiver conectada.
O app tem uma tarefa que exige acesso à rede ou uma conexão Wi-Fi.
O app tem diversas tarefas que você quer executar em lote ou com um agendamento regular.

Uma unidade de trabalho é encapsulada por um objeto JobInfo. Esse objeto especifica os critérios de agendamento.

Use a classe JobInfo.Builder para configurar como a tarefa agendada será executada. A execução da tarefa pode ser agendada sob condições específicas, como:

Iniciar quando o dispositivo estiver carregando
Iniciar quando o dispositivo estiver conectado a uma rede ilimitada
Iniciar quando o dispositivo estiver ocioso
Terminar antes de um determinado prazo ou com um mínimo de atraso

Por exemplo, é possível adicionar um código como este para executar a tarefa em uma rede ilimitada:

Kotlin

val uploadTask: JobInfo = JobInfo.Builder(
        jobId,
        serviceComponent /* JobService component */
).run {
    setRequiredNetworkType(JobInfo.NETWORK_TYPE_UNMETERED)
    build()
}
val jobScheduler = context.getSystemService(Context.JOB_SCHEDULER_SERVICE) as JobScheduler
jobScheduler.schedule(uploadTask)

Java

JobInfo uploadTask = new JobInfo.Builder(jobId,
                                         serviceComponent /* JobService component */)
        .setRequiredNetworkCapabilities(JobInfo.NETWORK_TYPE_UNMETERED)
        .build();
JobScheduler jobScheduler =
        (JobScheduler) context.getSystemService(Context.JOB_SCHEDULER_SERVICE);
jobScheduler.schedule(uploadTask);

Se o dispositivo tiver energia estável (ou seja, se ele estiver conectado por mais de 2 minutos e a bateria estiver em um nível íntegro), o sistema vai executar todas as tarefas agendadas prontas para execução, mesmo se o prazo não tiver expirado.

Para conferir um exemplo de como usar a API JobScheduler, consulte o exemplo de implementação JobSchedulerSample nesta versão.

Ferramentas de desenvolvedor para uso da bateria

O novo comando dumpsys batterystats gera dados estatísticos interessantes sobre o uso da bateria de um dispositivo, organizados pelo ID de usuário exclusivo (UID). As estatísticas incluem:

Histórico de eventos relacionados à bateria
Estatísticas gerais do dispositivo
Uso aproximado da bateria por UID e componentes do sistema
Ms por dispositivo móvel por pacote
Estatísticas agregadas do UID do sistema
Estatísticas agregadas do UID do app

Use a opção --help para saber mais sobre as diversas opções de personalização do resultado. Por exemplo, para imprimir as estatísticas de uso da bateria de um determinado pacote de apps desde a última carga do dispositivo, execute este comando:

$ adb shell dumpsys batterystats --charged <package-name>

É possível usar a ferramenta Battery Historian na saída do comando dumpsys para gerar uma visualização em HTML dos eventos relacionados a energia dos registros. Essas informações facilitam a compreensão e o diagnóstico de qualquer problema relacionado à bateria.

Android no local de trabalho e na educação

Provisionamento gerenciado

O Android 5.0 oferece um novo recurso para a execução de apps em um ambiente empresarial. Um administrador de dispositivo pode iniciar um processo de provisionamento gerenciado para adicionar um perfil gerenciado copresente, mas separado, a um dispositivo, se o usuário tiver uma conta pessoal. Os apps associados a perfis gerenciados aparecem ao lado dos apps não gerenciados na tela de início, na tela "Recentes" e nas notificações do usuário.

Para iniciar o processo de provisionamento gerenciado, envie ACTION_PROVISION_MANAGED_PROFILE em Intent. Se a chamada for bem-sucedida, o sistema acionará o callback onProfileProvisioningComplete(). Em seguida, chame setProfileEnabled() para ativar esse perfil gerenciado.

Por padrão, somente um subgrupo de aplicativos são habilitados no perfil gerenciado. É possível instalar apps adicionais no perfil gerenciado chamando enableSystemApp().

Se você estiver desenvolvendo um app de tela de início, use a nova classe LauncherApps para ver uma lista de atividades inicializáveis para o usuário atual e os perfis gerenciados associados. A tela de início pode destacar visualmente os apps gerenciados adicionando um emblema de trabalho ao desenhável do ícone. Para recuperar o ícone com emblema, chame getUserBadgedIcon().

Para saber como usar o novo recurso, consulte o exemplo de implementação BasicManagedProfile nesta versão.

Proprietário de dispositivo

O Android 5.0 apresenta a capacidade de implementar um app proprietário do dispositivo. Um proprietário do dispositivo é um tipo especializado de administrador do dispositivo que tem a capacidade adicional de criar e remover usuários secundários e definir configurações globais no dispositivo. O app proprietário do dispositivo pode usar os métodos na classe DevicePolicyManager para assumir controle detalhado da configuração, da segurança e dos apps em dispositivos gerenciados. Um dispositivo só pode ter um proprietário de dispositivo ativo por vez.

Para implementar e ativar um proprietário de dispositivo, é preciso executar uma transferência de dados de NFC de um app de programação para o dispositivo enquanto o mesmo estiver no estado sem provisionamento. Essa transferência de dados envia as mesmas informações que na intent de provisionamento descrita em Provisionamento gerenciado.

Fixação de tela

O Android 5.0 apresenta uma nova API de fixação de tela que permite impedir temporariamente que os usuários deixem a tarefa ou sejam interrompidos por notificações. Isso pode ser usado, por exemplo, se você estiver desenvolvendo um app educacional para oferecer suporte a requisitos de avaliação de alto risco no Android ou um aplicativo público ou de quiosque. Depois que o app ativar a fixação de tela, os usuários não poderão ver notificações, acessar outros apps nem voltar à tela inicial até que o app saia do modo.

Há duas formas de ativar a fixação de tela:

Manualmente: os usuários podem ativar a fixação de tela em Configurações > Segurança > Fixação de tela e selecionar as tarefas que querem fixar tocando no ícone de fixação verde na tela Recentes.
Programaticamente: para ativar a fixação de tela programaticamente, chame startLockTask() no seu app. Se o app solicitante não for um proprietário do dispositivo, o usuário será solicitado a confirmar. Um app proprietário de dispositivo pode chamar o método setLockTaskPackages() para permitir que apps sejam fixados sem a etapa de confirmação do usuário.

Quando o bloqueio de tarefas estiver ativo, ocorrerá o seguinte comportamento:

A barra de status fica em branco, e as notificações do usuário e informações de status são ocultas.
Os botões Home e Recent Apps serão ocultados.
Outros aplicativos não poderão iniciar novas atividades.
O app atual poderá iniciar novas atividades, desde que isso não crie novas tarefas.
Quando a fixação de tela é invocada por um proprietário do dispositivo, o usuário permanece bloqueado no app até que ele chame stopLockTask().
Se a fixação de tela for ativada por outro app que não seja o proprietário do dispositivo ou pelo usuário diretamente, o usuário poderá sair mantendo os botões "Voltar" e "Recente" pressionados.

Estrutura de impressão

Renderização de PDF como bitmap

Agora, você pode renderizar páginas de documentos em PDF em imagens bitmap para impressão usando a nova classe PdfRenderer. É preciso especificar um ParcelFileDescriptor pesquisável (ou seja, conteúdo que possa ser acessado de forma aleatória) no qual o sistema grave o conteúdo imprimível. Seu app pode acessar uma página para renderização com openPage() e, em seguida, chamar render() para transformar o PdfRenderer.Page aberto em um bitmap. Além disso, é possível definir parâmetros adicionais caso você queira apenas converter uma parte do documento em uma imagem bitmap (por exemplo, implementar a renderização de bloco para aumentar o zoom do documento).

Para ver um exemplo de como usar as novas APIs, consulte o exemplo PdfRendererBasic.

Sistema

Estatísticas de uso do aplicativo

Agora é possível acessar o histórico de uso do app em um dispositivo Android com a nova API android.app.usage. Essa API fornece informações de uso mais detalhadas do que o método getRecentTasks() descontinuado. Para usar essa API, é preciso primeiro declarar a permissão "android.permission.PACKAGE_USAGE_STATS" no manifesto. O usuário também precisa ativar o acesso a esse app em Configurações > Segurança > Apps com acesso ao uso.

O sistema coleta os dados de uso por aplicativo, agregando os dados em intervalos diários, semanais, mensais e anuais. O tempo máximo que o sistema mantém esses dados é o seguinte:

Dados diários: 7 dias
Dados semanais: 4 semanas
Dados mensais: 6 meses
Dados anuais: 2 anos

Para cada aplicativo, o sistema registra os seguintes dados:

A última vez em que o aplicativo foi usado
O tempo total em que o app ficou em primeiro plano para esse intervalo de tempo (por dia, semana, mês ou ano)
Captura de carimbo de data/hora quando um componente (identificado por um pacote e nome da atividade) é movido para primeiro ou segundo plano durante um dia
Captura de carimbo de data/hora quando a configuração de um dispositivo mudou (como quando a orientação do dispositivo mudou devido à rotação)

Testes e acessibilidade

Melhorias de teste e acessibilidade

O Android 5.0 adiciona o seguinte suporte para testes e acessibilidade:

Os novos métodos getWindowAnimationFrameStats() e getWindowContentFrameStats() capturam estatísticas de frame para animações de janela e conteúdo. Esses métodos permitem gravar testes de instrumentação para avaliar se um app está renderizando quadros com frequência de atualização suficiente para oferecer uma experiência contínua ao usuário.
O novo método executeShellCommand() permite executar comandos de shell no teste de instrumentação. A execução do comando é semelhante à execução de adb shell de um host conectado ao dispositivo, permitindo o uso de ferramentas baseadas em shell, como dumpsys, am, content e pm.
Serviços de acessibilidade e ferramentas de teste que usam as APIs de acessibilidade (como UiAutomator) agora podem extrair informações detalhadas sobre as propriedades das janelas na tela com as quais os usuários com problemas visuais podem interagir. Para recuperar uma lista de objetos AccessibilityWindowInfo, chame o novo método getWindows().
A nova classe AccessibilityNodeInfo.AccessibilityAction permite definir ações padrão ou personalizadas para realizar em uma AccessibilityNodeInfo. A nova classe AccessibilityNodeInfo.AccessibilityAction substitui as APIs relacionadas a ações encontradas anteriormente em AccessibilityNodeInfo.
O Android 5.0 oferece controle mais detalhado sobre a síntese de texto em fala do app. A nova classe Voice permite que o app use perfis de voz associados a localidades, classificação de qualidade e latência específicas, além de parâmetros específicos de mecanismos de conversão de texto em fala.

IME

Troca mais fácil entre idiomas de entrada

A partir do Android 5.0, os usuários podem alternar mais facilmente entre todos os editores de método de entrada (IME) com suporte da plataforma. A execução da ação de alternância designada (geralmente tocando em um ícone de globo no teclado de software) percorre todos esses IMEs. Essa mudança de comportamento é implementada pelo método shouldOfferSwitchingToNextInputMethod().

Além disso, a estrutura de trabalho agora verifica se o IME seguinte inclui um mecanismo de troca (e, portanto, se o IME oferece suporte para a mudança para o IME seguinte). Um IME com um mecanismo de troca não percorrerá um IME que não tenha esse mecanismo. Essa mudança de comportamento é implementada pelo método switchToNextInputMethod().

Para conferir um exemplo de como usar as APIs de troca de IME atualizadas, consulte o exemplo de implementação de teclado virtual atualizado nesta versão. Para saber mais sobre como implementar a alternância entre IMEs, consulte Como criar um método de entrada.

Declarações do manifesto

Recursos necessários declaráveis

Os valores abaixo agora têm suporte no elemento <uses-feature>. Assim, você pode garantir que o app seja instalado somente em dispositivos que ofereçam os recursos necessários.

Permissões do usuário

A permissão abaixo agora tem suporte no elemento <uses-permission> para declarar as permissões necessárias para o app acessar determinadas APIs.

BIND_DREAM_SERVICE: ao destinar o app ao nível 21 da API e versões mais recentes, essa permissão é exigida por um serviço do Daydream para garantir que somente o sistema possa se vincular a ele.