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.

Caso tenha publicado anteriormente 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

Dev Byte: Notificações (link 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 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 no Dalvik não funcionam no ART. Para saber mais sobre os problemas mais importantes, consulte Como 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).
• Você usa 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 criar notificações para o Android 5.0 e versões mais recentes, consulte o guia de design de notificações (em inglês).

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 parecerem incorretas, 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. Você deve presumir 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 suas notificações usando as classes Ringtone, MediaPlayer ou Vibrator, remova esse código para que o sistema possa apresentar 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 sensíveis contra a exposição. Nesse caso, o sistema edita automaticamente o texto mostrado pela notificação. Para personalizar essa notificação editada, use setPublicVersion().

Se a notificação não contiver informações pessoais ou se você quiser permitir o controle de reprodução de mídia na notificação, 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 apresentem status de reprodução de mídia ou controles de transporte, use o novo modelo de 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 os 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

As notificações agora podem aparecer em uma pequena janela flutuante (também conhecida como notificação de alerta) quando o dispositivo está ativo, ou seja, quando o dispositivo está desbloqueado e com a tela ligada. Essas notificações são semelhantes à forma compacta da notificação, exceto pelo fato de que a notificação de alerta também mostra botões de ação. Os usuários podem agir ou dispensar a 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

O uso da classe RemoteControlClient foi descontinuado. 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 oferecer controle de reprodução de mídia na tela de bloqueio com uma notificação. Isso dá ao app mais controle sobre a apresentação de botões de mídia, além de oferecer 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 as ações de notificação adicionadas com Notification.Builder.addAction() em botões compactos incorporados às notificações de reprodução de mídia do app. Transmita seu token de 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 mais informações, consulte Notificações da tela de bloqueio.

Para exibir controles de reprodução de mídia se o app estiver sendo executado na plataforma Android TV ou Wear, implemente a classe MediaSession. Também implemente 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 documentos e atividades 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 dos dados, incluindo as tarefas próprias do aplicativo que fez a chamada e possivelmente algumas outras tarefas não confidenciais (como a página inicial). Se o app estiver usando esse método para extrair as próprias tarefas, use getAppTasks() para recuperar 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 o desempenho, além de ainda oferecer suporte total aos apps de 32 bits. A compatibilidade com 64 bits também melhora o desempenho do OpenSSL para criptografia. Além disso, esta versão introduz novas APIs NDK de mídia nativa, além de compatibilidade nativa com OpenGL ES (GLES) 3.1.

Para usar a compatibilidade com 64 bits oferecida 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 mais informações sobre mudanças importantes e correções de bugs do NDK.

Vinculação a um serviço

O método Context.bindService() agora requer uma Intent explícita e gera uma exceção se recebe uma intent implícita. Para garantir a segurança do app, use uma intent explícita ao iniciar ou vincular a 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.

• Se o app for direcionado ao nível 21 da API ou mais recente:
  • 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 todo o documento 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 permite conteúdo misto e cookies de terceiros e sempre renderiza 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á um pequeno número de cenários em que definir permissões personalizadas é uma abordagem legítima e segura. No entanto, às vezes, a criação de permissões personalizadas é desnecessária e pode até mesmo introduzir um risco potencial para 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 definam 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 oferecerem um recurso semelhante, eles poderão derivar 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 incluam as mesmas definições de permissões personalizadas.

No Android 4.4 e em 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 aplica uma nova restrição de exclusividade em permissões personalizadas para apps assinados com chaves diferentes. Agora, apenas um app de um dispositivo pode definir uma 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? Nesse caso, eles são realmente necessários para o funcionamento adequado do seu app ou serviço? Ou poderia usar uma permissão padrão do sistema em vez disso?
• Se você tem elementos <permission> no seu app, sabe de onde eles vieram?
• Você realmente quer que outros apps solicitem suas permissões personalizadas pelo <uses-permission>?
• Você está usando código boilerplate ou exemplo de código 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 seu app em dispositivos com o Android 4.4 ou versões anteriores não são afetadas e não há mudança de comportamento. Para novas instalações e atualizações em dispositivos com o Android 5.0 ou mais recente, o sistema impede a instalação do app caso ele defina uma permissão personalizada já definida por um app residente existente.

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

Caso seu app use permissões personalizadas e seja amplamente distribuído e instalado, há uma chance de que ele seja afetado quando os usuários receberem a atualização dos dispositivos para o Android 5.0. Após a instalação da atualização do sistema, 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 que já foi validado e ele 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ê analise seu app imediatamente, faça os ajustes necessários e publique a versão atualizada assim que possível.

• Se você 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 adequado 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 do app, 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 por meio de uma permissão personalizada, verifique se a permissão personalizada foi definida apenas uma vez no componente compartilhado. Apps que usam o componente compartilhado não precisam definir a permissão personalizada, mas precisam solicitar acesso pelo mecanismo <uses-permission>.
• Se você tem um conjunto de apps assinados com a mesma chave, cada um deles pode definir as mesmas permissões personalizadas necessárias . O sistema permite que os apps sejam instalados da maneira normal.

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

O Android 5.0 introduz alterações na configuração TLS/SSL padrão usada por apps para HTTPS e outros tipos de 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 mudanças podem levar a falhas na conectividade HTTPS ou TLS/SSL em um pequeno número de casos listados abaixo.

Observe que o ProviderInstaller de segurança do Google Play Services já oferece essas mudanças em todas as versões da plataforma Android até o Android 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 que os pacotes de criptografia Forward Secrecy (ECDHE, DHE) estejam ativados e tenham 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 que tenham alguns dos conjuntos de criptografia exigidos pelo servidor ativado, além dos conjuntos 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 é erroneamente rejeitado ou travado. A correção recomendada é fazer o upgrade do servidor para que ele fique em conformidade com o protocolo TLS/SSL. Isso fará com que o servidor negocie com êxito esses protocolos mais recentes ou negocie TLSv1 ou protocolos mais antigos e ignore as extensões TLS que não entende. Em alguns casos, desativar TLSv1.1 e 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 deve ser projetada para criar instâncias de SSLSocket apenas com os protocolos ativados que sejam corretamente suportados pelo servidor.

Compatibilidade com perfis gerenciados

Os administradores podem adicionar um perfil gerenciado a um dispositivo. Esse perfil pertence ao administrador, que dá a ele controle sobre o perfil gerenciado, deixando o perfil pessoal do usuário e o espaço de armazenamento dele sob controle do usuário. Essa mudança pode afetar o comportamento do app existente 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 disparar uma intent do perfil gerenciado que normalmente seria processado por esse aplicativo e não houver um gerenciador adequado para a intent no perfil gerenciado, a intent vai causar 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 um app no perfil gerenciado que processe 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 Take Photos Simply: Tirar uma foto com o app 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 do arquivo, isso significa que um URI de arquivo válido em um perfil não é válido em outro. Normalmente, isso não é um problema para um app, que geralmente 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 disparada por um app no perfil gerenciado, a câmera precisará gravar a imagem em um local onde os apps do perfil gerenciado possam lê-la.

Por segurança, quando você precisar anexar um arquivo a uma intent que possa passar de um perfil para outro, crie e use um URI de conteúdo para o arquivo. Para mais informações 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 especificando 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 o app esteja no outro perfil.

Compatibilidade com widget na tela de bloqueio removida

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