Mudanças do Android 6.0

Junto com novos recursos e funcionalidades, o Android 6.0 (API de nível 23) inclui uma variedade de mudanças do sistema e mudanças de comportamento da API. Neste documento, destacamos algumas das principais mudanças que você precisa entender e considerar nos seus apps.

Se você já publicou um aplicativo para Android, saiba que essas alterações na de uma plataforma afetam seu app.

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 permissões do app no tempo de execução. Esse modelo oferece aos usuários maior visibilidade e controle e simplifica os processos de instalação e atualização automática para os desenvolvedores de apps. Os usuários podem conceder ou revogar as permissões individualmente para os aplicativos instalados.

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

Para mais detalhes sobre como oferecer suporte ao novo modelo de permissões no seu app, consulte Como trabalhar com permissões do sistema. Para dicas sobre como avaliar o impacto no seu app, consulte as Notas de uso das permissões.

Soneca e App em espera

Esta versão introduz novas otimizações de economia de energia para dispositivos e aplicativos ociosos. Esses afetam todos os aplicativos. Portanto, não deixe de testar seus aplicativos nesses novos modos.

  • Soneca: se um usuário desconectar um dispositivo e deixá-lo parado, com a tela desligada, por um período, o dispositivo entra no modo Soneca, onde tenta manter o sistema em um estado de sono. Neste modo, os dispositivos retomam as operações normais periodicamente por breves períodos para que a sincronização de aplicativos possa ocorrer e o sistema possa executar quaisquer operações pendentes.
  • App em espera: permite que o sistema determine se um app está ocioso. quando o usuário não o estiver usando ativamente. O sistema determina isso quando o usuário não tocar no aplicativo por um determinado período. Se o dispositivo estiver desconectado, o sistema desativará a rede acesso e suspende as sincronizações e as tarefas dos apps considerados inativos.

Para saber mais sobre essas mudanças na economia de energia, consulte Como otimizar para os modos "Soneca" e "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 seja direcionado ao Android 2.3 (API de nível 9) ou versões mais recentes, use a classe HttpURLConnection como alternativa. Essa API é mais eficiente porque reduz o uso da rede por meio de compactação transparente armazenamento em cache de respostas e minimiza o consumo de energia. Para continuar usando as APIs Apache HTTP, faça o seguinte: primeiro precisa declarar a seguinte 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 o BoringSSL (em inglês) biblioteca. Se você estiver usando o Android NDK no seu app, não vincule a bibliotecas criptográficas que não fazem parte da API NDK, como libcrypto.so e libssl.so. Esses não são APIs públicas e podem mudar ou apresentar falhas sem aviso prévio em todas as versões e dispositivos. Além disso, você pode se expor a vulnerabilidades de segurança. Em vez disso, modifique seu código nativo para chamar as APIs de criptografia Java via JNI ou para vincular estaticamente a uma biblioteca de criptografia de sua escolha.

Acesso ao identificador de hardware

Para oferecer aos usuários mais proteção de dados, a partir desta versão, o Android remove o acesso programático ao identificador de hardware local do dispositivo para aplicativos que usam as APIs de Wi-Fi e Bluetooth. A WifiInfo.getMacAddress() e o Métodos 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 por Bluetooth e buscas por Wi-Fi, o app agora precisa ter a permissão ACCESS_FINE_LOCATION ou Permissões ACCESS_COARSE_LOCATION:

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

Notificações

Esta versão remove o método Notification.setLatestEventInfo(). Use o Notification.Builder para criar notificações. Para atualizar um repetidamente, reutilize a instância Notification.Builder. Chame o método build() para receber atualizou Notification instância.

O comando adb shell dumpsys notification não imprime mais o texto da notificação. Use o comando adb shell dumpsys notification --noredact para imprimir o texto. em um objeto de notificação.

Mudanças no AudioManager

Definir o volume diretamente ou silenciar streams específicos usando o AudioManager não é mais compatível. O método setStreamSolo() foi descontinuado, e você precisa chamar o requestAudioFocus() . Da mesma forma, O método setStreamMute() é descontinuado 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 seu app, agora você pode mostrar ações de seleção de texto, como: Recortar, Copiar e Colar em uma barra de ferramentas flutuante. A implementação da interação do usuário é semelhante à para a barra de ação 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 no seu aplicativos:

  1. No objeto View ou Activity, mude o ActionMode chamada de startActionMode(Callback) para startActionMode(Callback, ActionMode.TYPE_FLOATING).
  2. Use sua implementação atual de ActionMode.Callback para que ela se estenda ActionMode.Callback2.
  3. Substitua o 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 este for o único elemento a ser invalidado, chame o método invalidateContentRect().

Se você estiver usando Android Support Library revisão 22.2, esteja ciente de que as barras de ferramentas flutuantes não são é compatível com versões anteriores, e appcompatibilidade assume o controle sobre objetos ActionMode ao padrão. Isso evita que barras de ferramentas flutuantes sejam exibidas. Para ativar Suporte a ActionMode em um AppCompatActivity, ligar getDelegate(), depois chame setHandleNativeActionModesEnabled() na devolução AppCompatDelegate e defina a entrada como false. Essa chamada retorna o controle dos objetos ActionMode para no framework. Em dispositivos com o Android 6.0 (nível 23 da API), isso permite que o framework suporte Modos ActionBar ou da barra de ferramentas flutuante, enquanto em dispositivos em execução Android 5.1 (API de nível 22) ou anterior, apenas os modos ActionBar são suporte.

Mudanças nos favoritos de navegadores

Esta versão remove a compatibilidade com favoritos globais. A android.provider.Browser.getAllBookmarks() e android.provider.Browser.saveBookmark() foram removidos. Da mesma forma, READ_HISTORY_BOOKMARKS e WRITE_HISTORY_BOOKMARKS forem removidas. Caso seu app seja destinado ao Android 6.0 (nível 23 da API) ou versões mais recentes, não acesse favoritos do provedor global ou use as permissões de favorito. Em vez disso, seu app deve armazenar adiciona dados aos favoritos internamente.

Mudanças no Android Keystore

Com esse lançamento, O provedor Android Keystore não oferece mais suporte DSA. Ainda há compatibilidade com ECDSA.

As chaves que não exigem criptografia em repouso não serão mais excluídas quando a tela de bloqueio estiver protegida for desativado ou redefinido (por exemplo, pelo usuário ou por um administrador do dispositivo); Chaves que exigem a criptografia em repouso será excluída 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.

  • Agora seus apps só podem mudar o estado de objetos WifiConfiguration se tiver criado esses objetos. 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 o Configuração disableAllOthers=true, o dispositivo foi desconectado 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 ao selecionado Rede Wi-Fi. Se a targetSdkVersion do app for a versão “21” ou mais recente, use o APIs de várias redes (como openConnection(), bindSocket(), e a nova 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 de câmera foi alterado do antigo modelo de acesso "primeiro a chegar, primeiro a ser atendido" para um modelo de acesso em que os 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 configuração de um dispositivo de câmera, é concedido com base na "prioridade" do processo de inscrição do cliente. Processos de aplicativos com atividades visíveis ao usuário ou em primeiro plano geralmente recebem uma prioridade mais alta, tornando o recurso da câmera aquisição e uso mais confiáveis.
  • Os clientes de câmera ativa para apps de menor prioridade podem ser "despejados" quando uma prioridade mais alta o aplicativo tenta usar a câmera. Na API Camera descontinuada, o que resulta em onError() sendo chamava o cliente despejado. Na API Camera2, isso resulta em onDisconnected() chamado para o cliente despejado.
  • Em dispositivos com hardware de câmera adequado, processos de aplicativo separados podem abrir de forma independente e usar dispositivos de câmera separados ao mesmo tempo. No entanto, o uso de vários processos casos em que o acesso simultâneo causa uma degradação significativa do desempenho ou das capacidades qualquer um dos dispositivos de câmera abertos, agora são detectados e proibidos pelo serviço de câmera. Essa mudança poderá resultar em "despejos" para clientes de menor prioridade, mesmo quando nenhum outro app estiver ao tentar acessar o mesmo dispositivo de câmera.
  • Mudar o usuário atual faz com que os clientes da câmera ativam nos apps da conta do usuário anterior ser removido. 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 pode sair em execução. processos que usam o subsistema da câmera quando o usuário muda para uma conta diferente.

Ambiente de execução

O tempo de execução de ART agora implementa adequadamente as regras de acesso para o newInstance(). Isso change corrige um problema em que o Dalvik verificava incorretamente as regras de acesso em versões anteriores. Caso seu app use o método newInstance() e você substituir as verificações de acesso, chame o método Método setAccessible() com a entrada definido como true. Caso seu app use o Biblioteca appcompatibilidade v7 ou a Biblioteca recyclerview v7, você precisa atualizar seu aplicativo para usar as versões mais recentes dessas bibliotecas. Caso contrário, certifique-se de que quaisquer classes personalizadas referenciadas do XML são atualizadas para que seus construtores de classe fiquem acessíveis.

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

A sinalização dlopen(3) RTLD_LOCAL agora está implementada corretamente. Observe que RTLD_LOCAL é o padrão. Portanto, chamadas para dlopen(3) que não usaram explicitamente RTLD_LOCAL será afetado, a menos que seu app tenha usado RTLD_GLOBAL explicitamente. Com RTLD_LOCAL, os símbolos não serão disponibilizados para bibliotecas carregadas por chamadas posteriores de dlopen(3) (em vez de ser referenciada por entradas DT_NEEDED).

Em versões anteriores do Android, se o app solicitava que o sistema carregasse uma biblioteca compartilhada com realocações de texto, o sistema mostrou um aviso, mas ainda permitiu que a biblioteca fosse carregada. A partir desta versão, o sistema rejeitará essa biblioteca se a versão do SDK de destino do app for a 23. ou superior. Para ajudar a detectar se uma biblioteca falhou ao carregar, seu aplicativo deve registrar o dlopen(3) e inclua o texto de descrição do problema que o dlerror(3) retorno de chamada. Para saber mais sobre realocações de texto, consulte este .

Validação de APK

A plataforma agora realiza validações mais estritas de APKs. Um APK será considerado corrompido se um arquivo for declarados no manifesto, mas não presentes no próprio APK. Um APK precisará ser assinado novamente se algum dos são removidos.

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 deverá conceder permissão explicitamente para e interações. Se o aplicativo oferecer suporte a interações do usuário com o dispositivo através de uma porta USB, leve em a interação precisa ser ativada de maneira explícita.

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 Telefone Google O registro de chamadas agora exibe os contatos de trabalho quando o usuário visualiza as chamadas anteriores. Ambiente setCrossProfileCallerIdDisabled() como true oculta os contatos do perfil de trabalho no Registro de chamadas do Telefone do Google. Os contatos de trabalho podem ser exibido com contatos pessoais para dispositivos por Bluetooth somente se você define setBluetoothContactSharingDisabled() como false. Por padrão, ele é definido como true.
  • Remoção da configuração de Wi-Fi:configurações de Wi-Fi adicionadas por um proprietário do perfil (por exemplo, por meio de chamadas para o addNetwork()) serão removidos se esse perfil de trabalho for excluído.
  • Bloqueio total de configuração de Wi-Fi: qualquer configuração de Wi-Fi criada pelo um proprietário ativo do dispositivo não poderá mais ser modificado ou excluído pelo usuário se WIFI_DEVICE_OWNER_CONFIGS_LOCKDOWN é diferente de zero. O usuário ainda pode criar e modificar as próprias configurações de Wi-Fi. Dispositivo ativo Os proprietários têm o privilégio de editar ou remover qualquer configuração de Wi-Fi, incluindo e aqueles não criados por eles.
  • Faça o download do controlador de política de dispositivo por meio da adição da Conta do Google: quando um serviço uma conta que exige gerenciamento por meio de um aplicativo controlador de política de dispositivo (DPC) é adicionada a um dispositivo fora de um contexto gerenciado, o fluxo de adição de conta agora solicita que o usuário instale o o WPC apropriado. Esse comportamento também se aplica a contas adicionadas por meio do Configurações > Contas e no assistente de configuração inicial do dispositivo.
  • Mudanças em comportamentos específicos da API DevicePolicyManager:
    • Chamar o setCameraDisabled() afeta a câmera apenas para o usuário que faz a chamada; chamá-lo do perfil gerenciado não afetar os apps de câmera em execução no usuário principal.
    • Além disso, setKeyguardDisabledFeatures() está disponível para Proprietários de Perfil, bem como para Proprietários 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 setScreenCaptureDisabled() agora também bloqueia a estrutura de assistência quando um app do usuário indicado está em primeiro plano.
    • EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM O padrão agora é SHA-256. SHA-1 ainda tem suporte para compatibilidade com versões anteriores, mas será removido no futuro. EXTRA_PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM agora aceita apenas SHA-256.
    • As APIs inicializadoras de dispositivo que existiam no Android 6.0 (API de nível 23) foram removidas.
    • O dispositivo EXTRA_PROVISIONING_RESET_PROTECTION_PARAMETERS foi removido para promover uma conexão NFC o provisionamento não pode desbloquear de forma programática um dispositivo protegido redefinido para a configuração original.
    • Agora você pode usar o EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE extra para transmitir dados ao app do proprietário do dispositivo durante o provisionamento de NFC do dispositivo gerenciado.
    • As APIs do Android for Work são otimizadas para permissões de 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 Android M.
    • Quando os usuários desistem da parte síncrona do fluxo de configuração iniciado por um 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 NetworkStats.
  • Mudanças nas configurações globais: