Alterações de comportamento do Android 5.0

Nível da API: 21

Além de novos recursos e recursos, o Android 5.0 inclui várias mudanças no sistema e no 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, ele poderá ser afetado por essas mudanças no Android 5.0.

Para conferir os novos recursos da plataforma de forma geral, consulte os destaques do Android Lollipop.

Vídeos

Dev Byte: novidades do Android 5.0

Byte do desenvolvedor: notificações

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 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 informações 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ódigos não padrão (como alguns ofuscadores).
  • Você usa técnicas incompatíveis com a coleta de lixo compactada.

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 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 exibidas com texto escuro sobre planos de fundo brancos (ou muito claros) para combinar com os novos widgets do Material Design. Confira se todas as notificações estão corretas com o novo esquema de cores. Se as notificações parecerem incorretas, faça o seguinte:

  • 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 apenas alfa. O sistema desenha os ícones de notificação em branco e os í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 os métodos Notification.Builder para adicionar sons e vibração.

A configuração do dispositivo como RINGER_MODE_SILENT faz com que ele entre no novo modo de prioridade. O dispositivo sai do modo prioritário 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 dispositivos tablet. No Android 5.0, o fluxo de volume principal para smartphones e tablets agora é 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 escolher proteger informações sensíveis para que não sejam expostas. Nesse caso, o sistema oculta 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 na notificação, chame o método setVisibility() e defina o nível de visibilidade da notificação como VISIBILITY_PUBLIC.

Controles 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 os controles sejam acessíveis na tela de bloqueio. 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, desbloqueado e com a tela ligada). Essas notificações aparecem de forma semelhante à forma compacta da notificação, exceto que a notificação de alerta também mostra botões de ação. Os usuários podem dispensar ou interagir com uma notificação de aviso 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 oferecer controle de reprodução de mídia na tela de bloqueio por meio de uma notificação. Isso dá ao app mais controle sobre a apresentação dos 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 apresenta um novo modelo Notification.MediaStyle para essa finalidade. Notification.MediaStyle converte 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 para o 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 mostrar controles de reprodução de mídia se o app estiver sendo executado na plataforma TV ou Wear do Android, implemente a classe MediaSession. Também é necessário implementar MediaSession se o app precisar receber eventos de 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 Atividades e documentos 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 próprias tarefas do aplicativo de chamada e possivelmente outras tarefas não sensíveis (como "Início"). Se o app estiver usando esse método para recuperar 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. O aprimoramento de 64 bits aumenta o espaço de endereço e melhora o desempenho, além de oferecer suporte total aos apps de 32 bits. O suporte a 64 bits também melhora o desempenho do OpenSSL para criptografia. Além disso, esta versão apresenta novas APIs NDK de mídia nativas, além de suporte nativo ao OpenGL ES (GLES) 3.1.

Para usar o suporte a 64 bits fornecido 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 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 o 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 destinado 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 de forma inteligente partes do documento HTML para renderizar. Esse novo comportamento padrão ajuda a reduzir o uso 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 permite conteúdo misto e cookies de terceiros e sempre renderiza todo o documento de uma 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 uma forma de gerenciar o acesso a componentes de maneira reservada, sem usar as permissões do sistema predefinidas da plataforma. Os apps definem permissões personalizadas em elementos <permission> declarados nos arquivos de manifesto.

Há alguns cenários em que a definição de 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é apresentar riscos potenciais 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 qualquer permissão personalizada que quiser. Por isso, pode acontecer de vários apps definirem a mesma permissão personalizada. Por exemplo, se dois apps oferecem um recurso semelhante, eles podem 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 incluem as mesmas definições de permissão 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 atribuísse 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 em um dispositivo pode definir uma determinada permissão personalizada (determinada 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 for assinado com a mesma chave que o app residente que define a permissão, o sistema vai 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, assim 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, é necessário avaliar cuidadosamente os possíveis impactos no app.

Veja alguns pontos a considerar:

  • O app declara elementos <permission> no manifesto? Se sim, elas são realmente necessárias para o funcionamento adequado do app ou serviço? Ou você pode usar uma permissão padrão do sistema?
  • Se você tiver elementos <permission> no app, sabe de onde eles vieram?
  • Você realmente pretende que outros apps solicitem suas permissões personalizadas por <uses-permission>?
  • Você está usando um código de exemplo ou boilerplate no app que inclui elementos <permission>? Esses elementos de permissão são realmente necessários?
  • Suas permissões personalizadas usam nomes simples ou com base em termos comuns que outros apps podem compartilhar?

Novas instalações e atualizações

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

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

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

Recomendações

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

  • 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 pelas 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 pacote de apps assinado com chaves diferentes e os apps acessarem um componente compartilhado por meio de uma permissão personalizada, verifique se a permissão personalizada é definida apenas uma vez, no componente compartilhado. Os apps que usam o componente compartilhado não precisam definir a permissão personalizada, mas podem solicitar acesso pelo mecanismo <uses-permission>.
  • Se você tiver um pacote de apps assinados com a mesma chave, cada app poderá definir as mesmas permissões personalizadas conforme necessário — o sistema permite que os apps sejam instalados da maneira usual.

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 pelos apps para HTTPS e outros tráfegos 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 causar falhas na conectividade HTTPS ou TLS/SSL em alguns casos listados abaixo.

O ProviderInstaller de segurança do Google Play Services já oferece essas mudanças em todas as versões da plataforma Android, desde 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 ativar pacotes e protocolos de criptografia mais fortes e modernos. O ideal é que o TLSv1.2 e o AES-GCM sejam ativados, e que os pacotes de criptografia de forward secrecy (ECDHE, DHE) sejam ativados e preferidos.

Uma alternativa é modificar o app para usar uma SSLSocketFactory personalizada para se comunicar com o servidor. A fábrica precisa ser projetada para criar instâncias de SSLSocket que tenham algumas das suítes de criptografia exigidas pelo servidor ativadas, além das suítes 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 TLS/SSL com um servidor é recusado ou interrompido. A correção recomendada é fazer upgrade do servidor para que ele esteja em conformidade com o protocolo TLS/SSL. Isso fará com que o servidor negocie esses protocolos mais recentes ou negocie o TLSv1 ou protocolos mais antigos e ignore as extensões de TLS que não entende. Em alguns casos, a desativação do TLSv1.1 e do TLSv1.2 no servidor pode funcionar como uma medida temporária até que o software do servidor seja atualizado.

Uma alternativa é modificar o app para usar uma SSLSocketFactory personalizada para se comunicar com o servidor. A fábrica precisa ser projetada para criar instâncias de SSLSocket com apenas os protocolos ativados que são corretamente compatíveis com o servidor.

Compatibilidade com perfis gerenciados

Os administradores de dispositivos podem adicionar um perfil gerenciado a um dispositivo. Esse perfil é de propriedade do administrador, que tem controle sobre o perfil gerenciado, mas deixa o perfil pessoal do usuário e o espaço de armazenamento sob o controle do usuário. Essa mudança pode afetar o comportamento do seu app atual das seguintes maneiras.

Lidar com intents

Os administradores de dispositivos podem restringir o acesso a aplicativos do sistema no perfil gerenciado. Nesse caso, se um app disparar uma intent do perfil gerenciado que normalmente seria processada 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 restringir o acesso de apps no perfil gerenciado ao 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 nenhum app no perfil gerenciado que possa processar a intent, isso resultará em uma ActivityNotFoundException.

Para evitar isso, verifique se há pelo menos um gerenciador para qualquer intent antes de acionar. Para verificar um gerenciador válido, chame Intent.resolveActivity(). Confira um exemplo disso em Tirar fotos de forma simples: 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 de arquivos, isso significa que um URI de arquivo que é válido em um perfil não é válido no outro. Isso geralmente não é um problema para um app, que normalmente só acessa os arquivos que ele cria. No entanto, se um app anexar um arquivo a uma intent, não será 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 dispositivos 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 precisa gravar a imagem em um local que os apps do perfil gerenciado possam ler.

Para garantir a segurança, quando você precisar anexar um arquivo a uma intent que possa passar de um perfil para o 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 Compartilhar arquivos. Por exemplo, o administrador do dispositivo pode permitir que o 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 disparou a intent poderá ler esse arquivo, mesmo que esteja no outro perfil.

Compatibilidade com widget na tela de bloqueio removida

O Android 5.0 remove o suporte a widgets da tela de bloqueio, mas continua oferecendo suporte a widgets na tela inicial.