Alterações de comportamento do Android 5.0

API de nível: 21

Junto com novos recursos e funcionalidades, o Android 5.0 inclui uma variedade de mudanças do sistema e de comportamento da API. Este documento destaca algumas das principais mudanças que você precisa entender e considerar nos seus apps.

Se você já tiver publicado um app para Android, saiba que ele pode ser afetado por essas mudanças no Android 5.0.

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

Vídeos

Dev Byte: Novidades do Android 5.0 (link em inglês)

Dev Byte: notificações (em inglês)

Android Runtime (ART)

No Android 5.0, o tempo de execução ART substitui o Dalvik como a plataforma padrão. O ambiente de execução do ART foi introduzido no Android 4.4 de forma experimental.

Para ter uma visão geral dos novos recursos do ART, consulte Introdução ao ART. Alguns dos principais novos recursos são:

• Compilação antecipada (AOT)
• Melhor coleta de lixo (GC)
• Melhor suporte à depuração

A maioria dos aplicativos Android devem funcionar normalmente sem precisar mudar nada no ART. No entanto, algumas técnicas que funcionam na Dalvik não funcionam no ART. Para saber mais sobre os problemas mais importantes, consulte Verificar o comportamento do app no Android Runtime (ART). Dê atenção especial se:

• Se aplicativo usar Java Native Interface (JNI) para executar código C/C++.
• Você usa ferramentas de desenvolvimento que geram código não padrão (como alguns ofuscadores).
• Se você usar técnicas incompatíveis com a compactação da coleta de lixo.

Notificações

Certifique-se de que suas notificações levam essas mudanças ao Android 5.0 em consideração. Para saber mais sobre como projetar suas notificações para o Android 5.0 e versões mais recentes, consulte o guia de design de notificações.

Estilo do material design

As notificações são desenhadas com texto escuro sobre fundos brancos (ou muito claros) para combinar com os novos widgets do Material Design. Confira se todas as suas notificações estão corretas com o novo esquema de cores. Se as notificações estiverem erradas, corrija-as:

• Use setColor() para definir uma cor de destaque em um círculo atrás da imagem do ícone.
• Atualize ou remova ativos que envolvam cor. O sistema ignora todos os canais não alfa em ícones de ação e no ícone de notificação principal. Suponha que esses ícones serão somente Alfa. O sistema desenha ícones de notificação em branco e ícones de ação em cinza-escuro.

Som e vibração

Se você estiver adicionando sons e vibrações às notificações usando as classes Ringtone, MediaPlayer ou Vibrator, remova esse código para que o sistema possa apresentar as notificações corretamente no modo prioridade. Em vez disso, use métodos de Notification.Builder para adicionar sons e vibração.

Definir o dispositivo como RINGER_MODE_SILENT faz com que ele entre no novo modo de prioridade. O dispositivo sairá do modo de prioridade se você o definir como RINGER_MODE_NORMAL ou RINGER_MODE_VIBRATE.

Anteriormente, o Android usava STREAM_MUSIC como o stream principal para controlar o volume em tablets. No Android 5.0, o fluxo de volume principal para smartphones e tablets agora está unificado e é controlado por STREAM_RING ou STREAM_NOTIFICATION.

Visibilidade na tela de bloqueio

Por padrão, as notificações agora aparecem na tela de bloqueio do usuário no Android 5.0. Os usuários podem optar por proteger informações confidenciais contra a exposição. Nesse caso, o sistema edita automaticamente o texto exibido pela notificação. Para personalizar essa notificação editada, use setPublicVersion().

Se a notificação não tiver informações pessoais ou se você quiser permitir o controle de reprodução de mídia, chame o método setVisibility() e defina o nível de visibilidade da notificação como VISIBILITY_PUBLIC.

Reprodução de mídia

Se você estiver implementando notificações que apresentam o status de reprodução de mídia ou controles de transporte, use o novo modelo Notification.MediaStyle em vez de um objeto RemoteViews.RemoteView personalizado. Seja qual for a abordagem escolhida, defina a visibilidade da notificação como VISIBILITY_PUBLIC para que seus controles possam ser acessados na tela de bloqueio. Observe que, a partir do Android 5.0, o sistema não mostra mais objetos RemoteControlClient na tela de bloqueio. Para mais informações, consulte Se o app usa o RemoteControlClient.

Notificação de informações básicas

Agora, as notificações podem aparecer em uma pequena janela flutuante (também chamada de notificação de alerta) quando o dispositivo está ativo, ou seja, quando ele está desbloqueado e com a tela ligada. Essas notificações são semelhantes à forma compacta da notificação, exceto pelo fato de a notificação de alerta também mostrar botões de ação. Os usuários podem agir ou dispensar uma notificação de alerta sem sair do app atual.

Exemplos de condições que podem ativar uma notificação de informações básicas incluem:

• A atividade do usuário está no modo de tela cheia (o app usa fullScreenIntent).
• A notificação tem alta prioridade e usa toques ou vibrações

Se o app implementar notificações em qualquer um desses cenários, verifique se as notificações de alerta são apresentadas corretamente.

Controles de mídia e RemoteControlClient

A classe RemoteControlClient foi descontinuada. Mude para a nova API MediaSession assim que possível.

As telas de bloqueio no Android 5.0 não mostram controles de transporte para MediaSession ou RemoteControlClient. Em vez disso, o app pode fornecer controle de reprodução de mídia na tela de bloqueio usando uma notificação. Isso dá ao app mais controle sobre a apresentação dos botões de mídia e oferece uma experiência consistente para os usuários em dispositivos bloqueados e desbloqueados.

O Android 5.0 introduz um novo modelo de Notification.MediaStyle para essa finalidade. O Notification.MediaStyle converte ações de notificação adicionadas com Notification.Builder.addAction() em botões compactos incorporados nas notificações de reprodução de mídia do app. Transmita o token da sessão ao método setSession() para informar ao sistema que essa notificação controla uma sessão de mídia em andamento.

Defina a visibilidade da notificação como VISIBILITY_PUBLIC para marcar a notificação como segura para exibição em qualquer tela de bloqueio (segura ou não). Para ver mais informações, consulte Notificações na tela de bloqueio.

Para mostrar controles de mídia se o app estiver sendo executado na plataforma Android TV ou Wear, implemente a classe MediaSession. Implemente também MediaSession se o app precisar receber eventos do botão de mídia em dispositivos Android.

getRecentTasks()

Com a introdução do novo recurso de tarefas de atividades e documentos simultâneos no Android 5.0 (consulte Documentos e atividades simultâneos na tela recentes abaixo), o método ActivityManager.getRecentTasks() foi descontinuado para melhorar a privacidade do usuário. Para compatibilidade com versões anteriores, esse método ainda retorna um pequeno subconjunto de dados, incluindo as tarefas do próprio aplicativo que faz a chamada e possivelmente algumas outras tarefas não confidenciais (como a Página inicial). Caso seu app esteja usando esse método para extrair as próprias tarefas, use getAppTasks() para extrair essas informações.

Compatibilidade com 64 bits do Android NDK

O Android 5.0 introduz a compatibilidade com sistemas de 64 bits. A melhoria com 64 bits aumenta o espaço de endereço e melhora o desempenho, sem deixar de oferecer suporte total aos apps de 32 bits. A compatibilidade com 64 bits também melhora o desempenho do OpenSSL em relação à criptografia. Além disso, esta versão introduz novas APIs NDK de mídia nativa, assim como compatibilidade nativa com OpenGL ES (GLES) 3.1.

Para usar a compatibilidade com 64 bits fornecida no Android 5.0, faça o download e instale a revisão 10c do NDK na página do Android NDK. Consulte as notas da versão da Revisão 10c para saber mais sobre mudanças importantes e correções de bugs no NDK.

Vinculação a um serviço

O método Context.bindService() agora exige uma Intent explícita e gera uma exceção se receber uma intent implícita. Para garantir a segurança do app, use uma intent explícita ao iniciar ou vincular Service e não declare filtros de intent para o serviço.

WebView

O Android 5.0 muda o comportamento padrão do seu aplicativo.

• Caso o app seja destinado ao nível 21 da API ou mais recente, faça o seguinte:
  • O sistema bloqueia conteúdo misto e cookies de terceiros por padrão. Para permitir conteúdo misto e cookies de terceiros, use os métodos setMixedContentMode() e setAcceptThirdPartyCookies(), respectivamente.
  • Agora, o sistema escolhe partes do documento HTML para desenhar de maneira inteligente. Esse novo comportamento padrão ajuda a reduzir o consumo de memória e aumentar o desempenho. Se você quiser renderizar o documento inteiro de uma só vez, desative essa otimização chamando enableSlowWholeDocumentDraw().
• Se o app for direcionado a níveis de API anteriores ao 21:o sistema vai permitir conteúdo misto e cookies de terceiros e sempre renderizará todo o documento de uma só vez.

Exigência de exclusividade para permissões personalizadas

Conforme documentado na visão geral de Permissões, os apps Android podem definir permissões personalizadas como um meio de gerenciar o acesso a componentes de maneira reservada, sem usar as permissões de sistema predefinidas da plataforma. Os apps definem permissões personalizadas nos elementos <permission> declarados nos arquivos de manifesto.

Há poucos cenários em que definir permissões personalizadas é uma abordagem legítima e segura. No entanto, a criação de permissões personalizadas às vezes é desnecessária e pode até mesmo introduzir um possível risco a um app, dependendo do nível de proteção atribuído às permissões.

O Android 5.0 inclui uma mudança de comportamento para garantir que apenas um app possa definir uma determinada permissão personalizada, a menos que seja assinado com a mesma chave de outros apps que definem a permissão.

Aplicativos que usam permissões personalizadas duplicadas

Qualquer app pode definir a permissão personalizada que quiser. Portanto, pode acontecer que vários apps definam a mesma permissão personalizada. Por exemplo, se dois apps oferecem recursos semelhantes, eles podem ter o mesmo nome lógico para as permissões personalizadas. Os apps também podem incorporar bibliotecas públicas comuns ou exemplos de código que incluem as mesmas definições de permissões personalizadas.

No Android 4.4 e versões anteriores, os usuários podiam instalar vários desses apps em um determinado dispositivo, embora o sistema tivesse atribuído o nível de proteção especificado pelo primeiro app instalado.

A partir do Android 5.0, o sistema impõe uma nova restrição de exclusividade em permissões personalizadas para apps assinados com chaves diferentes. Agora, apenas um app no dispositivo pode definir determinada permissão personalizada (conforme determinado pelo nome), a menos que o outro app que define a permissão seja assinado com a mesma chave. Se o usuário tentar instalar um app com uma permissão personalizada duplicada e não estiver assinado com a mesma chave do app residente que define a permissão, o sistema bloqueará a instalação.

Considerações para o aplicativo

No Android 5.0 e versões mais recentes, os apps podem continuar definindo as próprias permissões personalizadas como antes e solicitar permissões personalizadas de outros apps pelo mecanismo <uses-permission>. No entanto, com o novo requisito introduzido no Android 5.0, você precisa avaliar cuidadosamente os possíveis impactos no seu app.

Veja alguns pontos a considerar:

• O app declara algum elemento <permission> no manifesto? Em caso afirmativo, eles são realmente necessários para o funcionamento adequado do seu app ou serviço? Ou você poderia usar uma permissão padrão do sistema?
• Se você tem elementos <permission> no seu app, sabe de onde eles vieram?
• Você realmente quer que outros apps solicitem suas permissões personalizadas usando <uses-permission>?
• Você está usando código boilerplate ou exemplo de código no app que inclui elementos <permission>? Esses elementos de permissão são realmente necessários?
• Suas permissões personalizadas usam nomes simples ou baseados em termos comuns que outros apps podem compartilhar?

Novas instalações e atualizações

Como mencionado acima, novas instalações e atualizações do app em dispositivos com o Android 4.4 ou versão anterior não são afetadas e não há mudanças no comportamento. Para novas instalações e atualizações em dispositivos com o Android 5.0 ou mais recente, o sistema impedirá a instalação do app se ele definir uma permissão personalizada já definida por um app residente existente.

Instalações existentes com atualização de sistema do Android 5.0

Se seu app usa permissões personalizadas e é amplamente distribuído e instalado, é possível que ele seja afetado quando os usuários receberem atualizações de dispositivos para o Android 5.0. Depois que a atualização do sistema é instalada, o sistema revalida os apps instalados, incluindo a verificação das permissões personalizadas. Se o app definir uma permissão personalizada já definida por outro app já validado e seu app não estiver assinado com a mesma chave do outro app, o sistema não vai reinstalar o app.

Recomendações

Em dispositivos com Android 5.0 ou versões mais recentes, recomendamos que você examine o app imediatamente, faça os ajustes necessários e publique a versão atualizada assim que possível.

• Se estiver usando permissões personalizadas no app, considere a origem delas e se você realmente precisa delas. Remova todos os elementos <permission> do app, a menos que você tenha certeza de que eles são necessários para o funcionamento correto do app.
• Considere substituir suas permissões personalizadas por permissões padrão do sistema sempre que possível.
• Se o app exigir permissões personalizadas, renomeie-as para que sejam exclusivas, por exemplo, anexando-as ao nome completo do pacote do app.
• Se você tiver um conjunto de apps assinados com chaves diferentes e os apps acessarem um componente compartilhado usando uma permissão personalizada, verifique se a permissão personalizada é definida apenas uma vez, no componente compartilhado. Apps que usam o componente compartilhado não devem definir a permissão personalizada em si, mas precisam solicitar acesso por meio do mecanismo <uses-permission>.
• Se você tem um conjunto de apps assinados com a mesma chave, cada app pode definir as mesmas permissões personalizadas necessários. O sistema permite que os apps sejam instalados da maneira habitual.

Mudanças na configuração padrão de TLS/SSL

O Android 5.0 introduz mudanças na configuração TLS/SSL padrão usada por apps para HTTPS e outro tráfego TLS/SSL:

• Os protocolos TLSv1.2 e TLSv1.1 agora estão ativos,
• Os conjuntos de criptografia AES-GCM (AEAD) agora estão ativos,
• Os conjuntos de criptografia MD5, 3DES, export e ECDH de chave estática agora estão inativos,
• Os conjuntos de criptografia Forward Secrecy (ECDHE e DHE) são preferíveis.

Essas alterações podem levar a interrupções na conectividade HTTPS ou TLS/SSL em um pequeno número de casos listados abaixo.

Observe que o provedor de segurança do Google Play Services já oferece essas mudanças nas versões da plataforma Android anteriores à 2.3.

O servidor não é compatível com nenhum conjunto de criptografia ativo

Por exemplo, um servidor pode ser compatível somente com conjuntos de criptografia 3DES ou MD5. A correção recomendada é melhorar a configuração do servidor para permitir pacotes e protocolos de criptografia mais fortes e modernos. O ideal é que TLSv1.2 e AES-GCM estejam ativados, e os pacotes de criptografia Forward Secrecy (ECDHE, DHE) precisam estar ativados e ter preferência.

Uma alternativa é modificar o app para usar um SSLSocketFactory personalizado para se comunicar com o servidor. A fábrica precisa ser projetada para criar instâncias de SSLSocket com alguns dos pacotes de criptografia exigidos pelo servidor ativados, além dos pacotes de criptografia padrão.

O aplicativo está fazendo suposições erradas sobre conjuntos de criptografia usados para se conectar ao servidor

Por exemplo, alguns apps contêm um X509TrustManager personalizado que falha porque espera que o parâmetro authType seja RSA, mas encontra ECDHE_RSA ou DHE_RSA.

O servidor é intolerante a extensões TLSv1.1, TLSv1.2 ou TLS novas

Por exemplo, o handshake de TLS/SSL com um servidor é rejeitado ou é interrompido por engano. A correção recomendada é fazer upgrade do servidor para que ele fique em conformidade com o protocolo TLS/SSL. Isso faz com que o servidor negocie esses protocolos mais recentes ou o TLSv1 ou protocolos mais antigos e ignore as extensões TLS que ele não entende. Em alguns casos, desativar o TLSv1.1 e o TLSv1.2 no servidor pode funcionar como uma medida provisória até que o software do servidor seja atualizado.

Uma alternativa é modificar o app para usar um SSLSocketFactory personalizado para se comunicar com o servidor. A fábrica precisa ser projetada para criar instâncias de SSLSocket com apenas os protocolos ativados que tenham suporte correto do servidor.

Compatibilidade com perfis gerenciados

Os administradores podem adicionar um perfil gerenciado a um dispositivo. Esse perfil é de propriedade do administrador, que concede a ele o controle sobre o perfil gerenciado, deixando o perfil pessoal do usuário e o espaço de armazenamento dele sob controle. Essa mudança pode afetar o comportamento do app das seguintes maneiras.

Lidar com intents

Os administradores do dispositivo podem restringir o acesso a aplicativos do sistema pelo perfil gerenciado. Nesse caso, se um app dispara uma intent do perfil gerenciado que normalmente seria processado por esse aplicativo e não há um gerenciador adequado para a intent no perfil gerenciado, a intent causa uma exceção. Por exemplo, o administrador do dispositivo pode impedir que apps no perfil gerenciado acessem o aplicativo de câmera do sistema. Se o app estiver em execução no perfil gerenciado e chamar startActivityForResult() para MediaStore.ACTION_IMAGE_CAPTURE, e não houver app no perfil gerenciado que possa processar a intent, o resultado será uma ActivityNotFoundException.

Para evitar isso, verifique se há pelo menos um gerenciador para qualquer intent antes de acioná-la. Para conferir se há um gerenciador válido, chame Intent.resolveActivity(). Confira um exemplo disso em Tirar fotos simplesmente: tirar uma foto com o app de câmera.

Compartilhar arquivos dentre perfis

Cada perfil tem seu próprio armazenamento de arquivos. Como um URI de arquivo se refere a um local específico no armazenamento de arquivos, isso significa que um URI de arquivo válido em um perfil não é válido no outro. Normalmente, isso não é um problema para um app, que normalmente acessa apenas os arquivos criados. No entanto, se um app anexa um arquivo a uma intent, não é seguro anexar um URI de arquivo, já que, em algumas circunstâncias, a intent pode ser processada no outro perfil. Por exemplo, um administrador de dispositivo pode especificar que os eventos de captura de imagem precisam ser processados pelo app de câmera no perfil pessoal. Se a intent for acionada por um app no perfil gerenciado, a câmera precisa gravar a imagem em um local onde os apps do perfil gerenciado possam fazer a leitura dela.

Por segurança, quando você precisa anexar um arquivo a uma intent que pode passar de um perfil para outro, crie e use um URI de conteúdo para o arquivo. Para saber mais sobre o compartilhamento de arquivos com URIs de conteúdo, consulte Como compartilhar arquivos. Por exemplo, o administrador do dispositivo pode permitir que ACTION_IMAGE_CAPTURE seja processado pela câmera no perfil pessoal. O EXTRA_OUTPUT da intent de disparo precisa conter um URI de conteúdo que especifique onde a foto será armazenada. O app da câmera pode gravar a imagem no local especificado por esse URI, e o app que acionou a intent poderia ler esse arquivo, mesmo que esteja no outro perfil.

Compatibilidade com widget na tela de bloqueio removida

O Android 5.0 não oferece mais suporte a widgets na tela de bloqueio, mas ainda é compatível com widgets na tela inicial.