Mudanças do Android 6.0

Além de novos recursos e funcionalidades, o Android 6.0 (nível 23 da API) inclui uma série de mudanças de comportamento do sistema e da API. Este documento destaca algumas das principais mudanças que você deve entender e considerar nos seus apps.

Caso você já tenha um aplicativo para Android publicado, saiba que ele pode ser afetado pelas mudanças na plataforma.

Permissões de tempo de execução

Esta versão introduz um novo modelo de permissões em que os usuários podem gerenciar diretamente as permissões do app no momento da execução. Esse modelo oferece aos usuários maior visibilidade e controle sobre permissões, além de simplificar os processos de instalação e atualização automática para desenvolvedores de apps. Os usuários podem conceder ou revogar as permissões individualmente para os aplicativos instalados.

Nos apps destinados ao Android 6.0 (nível 23 da API) ou mais recente, verifique e solicite permissões em tempo de execução. Para determinar se o app recebeu uma permissão, chame o novo método checkSelfPermission(). Para solicitar uma permissão, chame o novo método requestPermissions(). Mesmo que seu app não seja destinado ao Android 6.0 (nível 23 da API), teste-o no novo modelo de permissões.

Para mais detalhes sobre o suporte do novo modelo de permissões no app, consulte Como trabalhar com permissões do sistema. Para conferir dicas sobre como avaliar o impacto no app, consulte Observações sobre o uso de permissões.

Soneca e App em espera

Esta versão introduz novas otimizações de economia de energia para dispositivos e aplicativos ociosos. Esses recursos afetam todos os apps, portanto, teste seus apps nesses novos modos.

  • Soneca: se um usuário desconecta um dispositivo e o deixa parado, com a tela desligada por um período, o dispositivo entra no modo Soneca, em que tenta manter o sistema em um estado de suspensão. Nesse modo, os dispositivos retomam as operações normais periodicamente por breves períodos para que a sincronização de apps possa ocorrer e o sistema possa executar qualquer operação pendente.
  • App Standby: permite que o sistema determine se um app está ocioso quando o usuário não o está usando ativamente. O sistema determina isso quando o usuário não toca no app por um determinado período. Se o dispositivo está desconectado, o sistema desativa o acesso à rede e suspende as sincronizações e as tarefas do aplicativo considerado ocioso.

Para saber mais sobre essas mudanças de economia de energia, consulte Otimização para o Soneca e o App em espera.

Remoção do cliente Apache HTTP

A versão Android 6.0 remove a compatibilidade com cliente Apache HTTP. Se o app estiver usando esse cliente e for direcionado para o Android 2.3 (nível 9 da API) ou mais recente, use a classe HttpURLConnection em vez disso. Essa API é mais eficiente, porque reduz o uso da rede por meio de compactação transparente e armazenamento em cache de resposta, além de minimizar o consumo de energia. Para continuar usando as APIs do Apache HTTP, declare a dependência de tempo de compilação no arquivo build.gradle: 

android {
    useLibrary 'org.apache.http.legacy'
}

BoringSSL

O Android está migrando do OpenSSL para a biblioteca BoringSSL. Se você estiver usando o Android NDK no app, não vincule-o a bibliotecas criptográficas que não façam parte da API NDK, como libcrypto.so e libssl.so. Estas bibliotecas não são APIs públicas e podem ser modificadas ou apresentar erros nas diversas versões e dispositivos sem aviso prévio. Além disso, você pode se expor a vulnerabilidades de segurança. Em vez disso, modifique o código nativo para chamar as APIs de criptografia Java pelo JNI ou para vincular estaticamente a uma biblioteca criptográfica de sua escolha.

Acesso ao identificador de hardware

Para oferecer aos usuários uma maior proteção de dados, a partir desta versão, o Android remove o acesso programático ao identificador de hardware local do dispositivo para apps que usam as APIs Wi-Fi e Bluetooth. Os métodos WifiInfo.getMacAddress() e BluetoothAdapter.getAddress() agora retornam um valor constante de 02:00:00:00:00:00.

Para acessar os identificadores de hardware de dispositivos externos próximos via detecções de Bluetooth e Wi-Fi, o app agora precisa ter as permissões ACCESS_FINE_LOCATION ou ACCESS_COARSE_LOCATION:

Observação: quando um dispositivo com o Android 6.0 (API de nível 23) inicia uma verificação de Wi-Fi ou Bluetooth em segundo plano, a operação fica visível para dispositivos externos como originada de um endereço MAC aleatório.

Notificações

Esta versão remove o método Notification.setLatestEventInfo(). Em vez disso, use a classe Notification.Builder para criar notificações. Para atualizar uma notificação repetidamente, reutilize a instância Notification.Builder. Chame o método build() para receber instâncias Notification atualizadas.

O comando adb shell dumpsys notification não mostra mais o texto da notificação. Em vez disso, use o comando adb shell dumpsys notification --noredact para imprimir o texto em um objeto de notificação.

Mudanças no AudioManager

Não há mais suporte para o ajuste direto do volume nem para a desativação do áudio de transmissões específicas por meio da classe AudioManager. O método setStreamSolo() foi descontinuado, e você precisa chamar o método requestAudioFocus(). Da mesma forma, o método setStreamMute() está obsoleto. Em vez disso, chame o método adjustStreamVolume() e transmita o valor da direção ADJUST_MUTE ou ADJUST_UNMUTE.

Seleção de texto

Tela mostrando novos recursos de seleção de texto em uma barra de ferramentas flutuante

Quando os usuários selecionam texto no app, agora é possível mostrar ações de seleção de texto, como Cortar, Copiar e Colar em uma barra de ferramentas flutuante. A implementação da interação do usuário é semelhante à barra de ações contextual, conforme descrito em Ativar o modo de ação contextual para visualizações individuais.

Para implementar uma barra de ferramentas flutuante para seleção de texto, faça as seguintes alterações nos apps existentes:

  1. No objeto View ou Activity, mude as chamadas de ActionMode de startActionMode(Callback) para startActionMode(Callback, ActionMode.TYPE_FLOATING).
  2. Pegue a implementação atual de ActionMode.Callback e faça com que ela estenda ActionMode.Callback2.
  3. Substitua o método onGetContentRect() para fornecer as coordenadas do conteúdo do objeto Rect (como um retângulo de seleção de texto) na visualização.
  4. Se o posicionamento do retângulo não for mais válido e for o único elemento a ser invalidado, chame o método invalidateContentRect().

Caso esteja usando a Android Support Library revisão 22.2, saiba que as barras de ferramentas flutuantes não têm compatibilidade com versões anteriores e que o appcompat assume o controle sobre os objetos ActionMode por padrão. Isso evita que barras de ferramentas flutuantes sejam exibidas. Para ativar o suporte a ActionMode em um AppCompatActivity, chame getDelegate() e, em seguida, chame setHandleNativeActionModesEnabled() no objeto AppCompatDelegate retornado e defina o parâmetro de entrada como false. Essa chamada retorna o controle dos objetos ActionMode para a estrutura. Em dispositivos com Android 6.0 (nível 23 da API), a estrutura de trabalho pode oferecer suporte a ActionBar ou modos de barra de ferramentas flutuante, enquanto que, para dispositivos com Android 5.1 (nível 22 da API) ou anterior, somente os modos de ActionBar são compatíveis.

Mudanças nos favoritos de navegadores

Esta versão remove a compatibilidade com favoritos globais. Os métodos android.provider.Browser.getAllBookmarks() e android.provider.Browser.saveBookmark() foram removidos. Da mesma forma, as permissões READ_HISTORY_BOOKMARKS e WRITE_HISTORY_BOOKMARKS foram removidas. Se o app for direcionado ao Android 6.0 (nível 23 da API) ou mais recente, não acesse as marcações do provedor global nem use as permissões de adição aos favoritos. Em vez disso, o app precisa armazenar dados de favoritos internamente.

Mudanças no Android Keystore

Com esta versão, o provedor Android Keystore não oferece mais suporte a DSA. Ainda há compatibilidade com ECDSA.

As chaves que não exigem criptografia em repouso não precisam ser excluídas quando a tela de bloqueio segura é desativada ou redefinida (por exemplo, pelo usuário ou por um administrador de dispositivo). As chaves que exigem criptografia em repouso serão excluídas durante esses eventos.

Mudanças de rede e Wi-Fi

Esta versão introduz as alterações de comportamento a seguir nas APIs de rede e Wi-Fi.

  • Os apps agora podem mudar o estado dos objetos WifiConfiguration somente se você os tiver criado. Você não tem permissão para modificar ou excluir objetos WifiConfiguration criados pelo usuário ou por outros apps.
  • Anteriormente, se um app forçasse o dispositivo a se conectar a uma rede Wi-Fi específica usando enableNetwork() com a configuração disableAllOthers=true, o dispositivo se desconectava de outras redes, como dados móveis. Nesta versão, o dispositivo não interrompe mais a conexão com outras redes. Se a targetSdkVersion do app for “20” ou anterior, ele será fixado na rede Wi-Fi selecionada. Se a targetSdkVersion do app for “21” ou mais recente, use as APIs de multirrede (como openConnection(), bindSocket() e o novo método bindProcessToNetwork()) para garantir que o tráfego de rede seja enviado na rede selecionada.

Mudanças no serviço de câmera

Nesta versão, o modelo para acessar recursos compartilhados no serviço da câmera foi alterado do antigo modelo de acesso "primeiro a chegar, primeiro a ser atendido" para um modelo de acesso onde os processos de alta prioridade são favorecidos. As mudanças no comportamento do serviço incluem:

  • O acesso aos recursos do subsistema da câmera, incluindo a abertura e a configuração de um dispositivo de câmera, é concedido com base na prioridade do processo do aplicativo do cliente. Processos de aplicativos com atividades visíveis ao usuário ou de primeiro plano geralmente têm prioridade mais alta, tornando a aquisição e o uso de recursos da câmera mais confiáveis.
  • Os clientes de câmera ativa para apps de menor prioridade podem ser "despejados" quando um app de alta prioridade tenta usar a câmera. Na API Camera descontinuada, isso resulta em onError() sendo chamado para o cliente removido. Na API Camera2, isso resulta na chamada de onDisconnected() para o cliente removido.
  • Em dispositivos com hardware de câmera adequado, processos de aplicativo separados podem abrir e usar os dispositivos de câmera de forma simultânea e independente. No entanto, casos de uso de vários processos, em que o acesso simultâneo causa uma degradação significativa de desempenho ou recursos de qualquer um dos dispositivos de câmera abertos, agora são detectados e proibidos pelo serviço da câmera. Essa mudança pode resultar em "despejos" para clientes de menor prioridade, mesmo quando nenhum outro app está tentando acessar diretamente o mesmo dispositivo de câmera.
  • Mudar o usuário atual faz com que os clientes de câmera ativa em apps pertencentes à conta de usuário anterior sejam despejados. O acesso à câmera é limitado a perfis de usuário de posse do usuário atual do dispositivo. Na prática, isso significa que uma conta de "convidado", por exemplo, não poderá deixar processos em execução que usam o subsistema da câmera quando o usuário alternar para uma conta diferente.

Ambiente de execução

O tempo de execução de ART agora implementa adequadamente as regras de acesso para o método newInstance(). Essa mudança corrige um problema em que o Dalvik verificava as regras de acesso de forma incorreta em versões anteriores. Se o app usa o método newInstance() e você quer substituir as verificações de acesso, chame o método setAccessible() com o parâmetro de entrada definido como true. Se o app usar a biblioteca appcompat v7 ou a biblioteca recyclerview v7, atualize-o para usar as versões mais recentes dessas bibliotecas. Caso contrário, confira se as classes personalizadas referenciadas do XML estão atualizadas para que os construtores de classe possam ser acessados.

Esta versão atualiza o comportamento do vinculador dinâmico. O vinculador dinâmico agora entende a diferença entre o soname de uma biblioteca e o caminho ( erro público 6670) dela, e a pesquisa por soname agora está implementada. Os apps que funcionavam anteriormente e têm entradas DT_NEEDED inválidas (geralmente caminhos absolutos no sistema de arquivos da máquina de build) podem falhar ao serem carregados.

A sinalização dlopen(3) RTLD_LOCAL agora está implementada corretamente. RTLD_LOCAL é o padrão. Portanto, chamadas de dlopen(3) que não usam explicitamente RTLD_LOCAL serão afetadas (a menos que o app use RTLD_GLOBAL explicitamente). Com RTLD_LOCAL, os símbolos não são disponibilizados para bibliotecas carregadas por chamadas posteriores a dlopen(3) (ao contrário de serem referenciados por entradas DT_NEEDED).

Em versões anteriores do Android, se o app pedia que o sistema carregasse uma biblioteca compartilhada com relocalizações de texto, o sistema exibia um aviso, mas a biblioteca podia ser carregada. A partir desta versão, o sistema rejeita a biblioteca se o app é direcionado à versão 23 ou mais recente do SDK. Para ajudar a detectar uma biblioteca cujo carregamento falhou, o app deve registrar a falha dlopen(3) e incluir o texto de descrição que a chamada dlerror(3) retorna. Para saber mais sobre como lidar com realocações de texto, consulte este guia.

Validação de APK

A plataforma agora realiza validações mais estritas de APKs. Um APK é considerado corrompido quando um arquivo é declarado no manifesto, mas não está presente no próprio APK. Deve-se reatribuir o APK se alguma parte do conteúdo for removida.

Conexão USB

Conexões de dispositivo na porta USB são agora definidas, por padrão, para o modo "somente carga". Para acessar o dispositivo e o conteúdo dele por uma conexão USB, o usuário precisa conceder permissão explicitamente para essas interações. Se o app oferecer suporte a interações do usuário com o dispositivo por meio de uma porta USB, considere que a interação precisa ser explicitamente ativada.

Mudanças no Android for Work

Esta versão inclui as seguintes mudanças de comportamento no Android for Work:

  • Contatos de trabalho em contextos pessoais. O registro de chamadas do Google Dialer agora mostra contatos de trabalho quando o usuário visualiza chamadas anteriores. Definir setCrossProfileCallerIdDisabled() como true oculta os contatos do perfil de trabalho no registro de chamadas do Google Dialer. Os contatos de trabalho só poderão ser exibidos junto com os contatos pessoais em dispositivos por meio de Bluetooth se setBluetoothContactSharingDisabled() for definido como false. Por padrão, ela é definida como true.
  • Remoção de configuração de Wi-Fi:as configurações de Wi-Fi adicionadas por um proprietário de perfil (por exemplo, por meio de chamadas para o método addNetwork()) agora são removidas se esse perfil de trabalho for excluído.
  • Bloqueio de configuração do Wi-Fi: qualquer configuração do Wi-Fi criada por um proprietário de dispositivo ativo não pode mais ser modificada ou excluída pelo usuário se WIFI_DEVICE_OWNER_CONFIGS_LOCKDOWN for diferente de zero. O usuário ainda pode criar e modificar as próprias configurações de Wi-Fi. Proprietários ativos de dispositivos têm o privilégio de editar ou remover qualquer configuração de Wi-Fi, incluindo as que não foram criadas por eles.
  • Baixe o controlador de política de dispositivo adicionando uma conta Google: quando uma conta Google que exige gerenciamento por meio do aplicativo Work Policy Controller (WPC) é adicionada a um dispositivo fora de um contexto gerenciado, o fluxo de adição de conta agora solicita ao usuário a instalação do WPC adequado. Esse comportamento também se aplica a contas adicionadas via Configurações > Contas e no assistente de configuração inicial do dispositivo.
  • Mudanças em comportamentos específicos da API DevicePolicyManager:
    • Chamar o método setCameraDisabled() afeta a câmera somente para o usuário que realizou a chamada. Chamá-lo do perfil gerenciado não afeta os aplicativos de câmera em execução no usuário principal.
    • Além disso, o método setKeyguardDisabledFeatures() agora está disponível para donos de perfil e de dispositivo.
    • Um proprietário de perfil pode definir estas restrições de bloqueio de teclado:
    • Os métodos DevicePolicyManager.createAndInitializeUser() e DevicePolicyManager.createUser() foram descontinuados.
    • O método setScreenCaptureDisabled() agora também bloqueia a estrutura de auxílio quando um app do usuário está em primeiro plano.
    • O EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM agora tem como padrão SHA-256. O SHA-1 ainda é compatível para compatibilidade com versões anteriores, mas será removido no futuro. EXTRA_PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM agora só aceita SHA-256.
    • As APIs inicializadoras de dispositivo que existiam no Android 6.0 (API de nível 23) foram removidas.
    • EXTRA_PROVISIONING_RESET_PROTECTION_PARAMETERS foi removido para que o provisionamento de impulso do NFC não possa desbloquear programaticamente um dispositivo protegido redefinido de fábrica.
    • Agora é possível usar o extra EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE para transmitir dados ao app do proprietário do dispositivo durante o provisionamento de NFC do dispositivo gerenciado.
    • As APIs Android for Work estão otimizadas para permissões em tempo de execução M, incluindo perfis de trabalho, camada de assistência e outros. As novas APIs de permissão DevicePolicyManager não afetam apps anteriores ao M.
    • Quando os usuários desistem da parte síncrona do fluxo de configuração iniciada com uma intenção ACTION_PROVISION_MANAGED_PROFILE ou ACTION_PROVISION_MANAGED_DEVICE, o sistema agora retorna um código de resultado RESULT_CANCELED.
  • Mudanças em outras APIs:
    • Uso de dados: a classe android.app.usage.NetworkUsageStats foi renomeada como NetworkStats.
  • Mudanças nas configurações globais: