Junto com novos recursos e funcionalidades, o Android 6.0 (nível 23 da API) 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 apps.
Se você já publicou um app para Android, saiba que essas mudanças na plataforma o afetam.
Permissões em 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 durante a 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 direcionados ao Android 6.0 (nível 23 da API) ou mais recente, não deixe de verificar e solicitar
permissões no momento da 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 direcionado ao Android 6.0 (nível 23 da API), teste-o no
novo modelo de permissões.
Para mais detalhes sobre como oferecer suporte ao novo modelo de permissões no app, consulte Como trabalhar com permissões do sistema. Para dicas sobre como avaliar o impacto no app, consulte 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 recursos afetam todos os apps, então não deixe de testar seus apps nesses novos modos.
- Soneca: se um usuário desconecta um dispositivo e o deixa imóvel com a tela desligada por um período, o dispositivo entra no modo Soneca, tentando 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 realizar operações pendentes.
- App em espera: o App em espera permite que o sistema determine se um app está inativo quando o usuário não o está usando ativamente. O sistema determina isso quando o usuário fica sem tocar no app por um determinado período. Se o dispositivo estiver desconectado, o sistema vai desativar o acesso à rede e suspender as sincronizações e os jobs dos apps que considerar inativos.
Para saber mais sobre essas mudanças de economia de energia, consulte Otimizar para o "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
direcionado ao Android 2.3 (nível 9 da API) ou versões mais recentes, use a classe
HttpURLConnection
. Essa API é mais eficiente porque reduz o uso da rede com compactação transparente e armazenamento em cache de resposta, além de minimizar o consumo de energia. Para continuar usando as APIs Apache HTTP, primeiro declare a seguinte dependência de tempo de compilação no arquivo build.gradle
:
android { useLibrary 'org.apache.http.legacy' }
BoringSSL
O Android está mudando da biblioteca OpenSSL para a
BoringSSL (link em inglês). 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
. Essas
bibliotecas não são APIs públicas e podem mudar ou apresentar falhas sem aviso prévio entre as versões e os dispositivos.
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 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
apps que usam as APIs de 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 por perto por meio de buscas por Bluetooth e Wi-Fi,
seu app agora precisa ter as permissões ACCESS_FINE_LOCATION
ou
ACCESS_COARSE_LOCATION
:
Observação: quando um dispositivo com o Android 6.0 (nível 23 da API) inicia uma verificação de Wi-Fi ou Bluetooth em segundo plano, a operação fica visível para dispositivos externos como proveniente de um endereço MAC aleatório.
Notificações
Nesta versão, removemos o método Notification.setLatestEventInfo()
. 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 de Notification
atualizadas.
O comando adb shell dumpsys notification
não mostra 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
Não há mais suporte para definir o volume diretamente ou silenciar streams específicos usando a classe
AudioManager
. O método setStreamSolo()
foi descontinuado. Em vez disso, chame o
método
requestAudioFocus()
. Da mesma forma, o
método setStreamMute()
foi
descontinuado. Em vez disso, chame o método adjustStreamVolume()
e transmita o valor de 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](https://developer.android.google.cn/static/images/android-6.0/text-selection.gif?authuser=5&hl=pt)
Agora, quando os usuários selecionarem texto no seu app, você poderá 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 à da barra de ações contextuais, 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 mudanças nos apps existentes:
- No objeto
View
ouActivity
, mude as chamadasActionMode
destartActionMode(Callback)
parastartActionMode(Callback, ActionMode.TYPE_FLOATING)
. - Use a implementação existente de
ActionMode.Callback
e faça com que ela estendaActionMode.Callback2
. - Substitua o
método
onGetContentRect()
para fornecer as coordenadas do objetoRect
de conteúdo (como um retângulo de seleção de texto) na visualização. - Se o posicionamento do retângulo não for mais válido e esse for o único elemento a ser invalidado,
chame o método
invalidateContentRect()
.
Se você estiver usando a
Biblioteca de Suporte do Android revisão 22.2, saiba que as barras de ferramentas flutuantes não são
compatíveis 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()
, chame
setHandleNativeActionModesEnabled()
no objeto
AppCompatDelegate
retornado e defina o parâmetro
de entrada como false
. Essa chamada retorna o controle de objetos ActionMode
para
o framework. Em dispositivos com o Android 6.0 (nível 23 da API), isso permite que o framework ofereça suporte aos modos
ActionBar
ou de barra de ferramentas flutuante. Já em dispositivos com o
Android 5.1 (nível 22 da API) ou versões anteriores, somente os modos ActionBar
têm
suporte.
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 versões mais recentes, não acesse
os favoritos do provedor global nem use as permissões relacionadas. Em vez disso, o app precisa armazenar
os dados dos favoritos internamente.
Mudanças no Android Keystore
Com essa versão, o provedor Android Keystore não oferece mais suporte a DSAs. Ainda há compatibilidade com ECDSA.
As chaves que não exigem criptografia em repouso não serão excluídas quando a tela de bloqueio segura for desativada ou redefinida (por exemplo, pelo usuário ou por um administrador do 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.
- Agora seus apps só poderão mudar o estado dos objetos
WifiConfiguration
se você os tiver criado. Não é permitido modificar ou excluir objetosWifiConfiguration
criados pelo usuário ou por outros apps. -
Antes, se um app forçasse o dispositivo a se conectar a uma rede Wi-Fi específica usando
enableNetwork()
com a configuraçãodisableAllOthers=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 atargetSdkVersion
do app for“20”
ou anterior, ela será fixada à rede Wi-Fi selecionada. Se atargetSdkVersion
do seu app for“21”
ou mais recente, use as APIs de várias redes (comoopenConnection()
,bindSocket()
e o novo métodobindProcessToNetwork()
) 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 de acesso a 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 em que 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 abertura e configuração de um dispositivo de câmera, é concedido com base na prioridade do processo do aplicativo cliente. Processos de aplicativos com atividades visíveis para o usuário ou em 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 prioridade mais alta tenta usar a câmera. Na API
Camera
descontinuada, isso resulta emonError()
sendo chamado para o cliente removido. Na APICamera2
, isso resulta emonDisconnected()
sendo chamado para o cliente removido. - Em dispositivos com hardware de câmera adequado, processos de aplicativo separados podem abrir e usar dispositivos de câmera separados e simultaneamente. No entanto, casos de uso de vários processos, em que o acesso simultâneo causa uma degradação significativa do desempenho ou dos 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 prioridade mais baixa, mesmo quando nenhum outro app estiver tentando acessar o mesmo dispositivo de câmera diretamente.
- Alterar o usuário atual faz com que os clientes da câmera ativa em apps da conta do usuário anterior sejam removidos. 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 mudar para outra conta.
Ambiente de execução
O ambiente de execução do ART agora implementa corretamente as regras de acesso para o
método newInstance()
. Essa
mudança corrige um problema em que o Dalvik verificava as regras de acesso incorretamente nas versões anteriores.
Se o app usar o
método newInstance()
e você
quiser substituir as verificações de acesso, chame o
método setAccessible()
com o parâmetro de entrada
definido como true
. Se o app usa a
biblioteca appcompat v7 ou a
biblioteca recyclerview v7,
é necessário atualizar o app para usar as versões mais recentes dessas bibliotecas. Caso contrário, verifique se
todas as classes personalizadas referenciadas do XML estão atualizadas para que os construtores de classe estejam acessíveis.
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 dela
(
bug público 6670). Além disso, a pesquisa por soname
já 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 flag dlopen(3) RTLD_LOCAL
agora está implementada corretamente. Observe que
RTLD_LOCAL
é o padrão. Portanto, as chamadas para dlopen(3)
que não usavam
RTLD_LOCAL
explicitamente serão afetadas (a menos que o app tenha usado RTLD_GLOBAL
explicitamente). Com
RTLD_LOCAL
, os símbolos não são disponibilizados para bibliotecas carregadas por chamadas posteriores de
dlopen(3)
(ao contrário de serem referenciados por entradas DT_NEEDED
).
Nas versões anteriores do Android, se o app solicitasse que o sistema carregasse uma biblioteca compartilhada com
realocações de texto, o sistema exibia um aviso, mas ainda permitia que a biblioteca fosse carregada.
A partir desta versão, o sistema vai rejeitar a biblioteca se a versão do SDK de destino do app for a 23
ou mais recente. Para ajudar a detectar se uma biblioteca não foi carregada, seu app precisa registrar a
falha dlopen(3)
e incluir o texto de descrição do problema retornado pela chamada
dlerror(3)
. 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 se um arquivo é declarado no manifesto, mas não está presente no próprio APK. Um APK precisará ser assinado novamente se algum conteúdo for removido.
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, os usuários precisam conceder permissão explicitamente para essas interações. Se o app oferecer suporte a interações do usuário com o dispositivo por uma porta USB, considere que a interação precisa ser ativada explicitamente.
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 Telefone do Google agora exibe os contatos de trabalho quando o usuário visualiza chamadas anteriores.
Definir
setCrossProfileCallerIdDisabled()
comotrue
oculta os contatos do perfil de trabalho no registro de chamadas do Telefone do Google. Os contatos de trabalho só poderão ser mostrados com os contatos pessoais nos dispositivos por Bluetooth se você definirsetBluetoothContactSharingDisabled()
comofalse
. Por padrão, ela é definida comotrue
. - Remoção da configuração de Wi-Fi:as configurações de Wi-Fi adicionadas por um proprietário do perfil
(por exemplo, por chamadas para o
método
addNetwork()
) serão removidas se o perfil de trabalho for excluído. - Bloqueio de configuração de Wi-Fi:qualquer configuração de Wi-Fi criada por
um proprietário do dispositivo ativo não poderá 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 de dispositivos ativos têm o privilégio de editar ou remover qualquer configuração de Wi-Fi, incluindo as que não foram criadas por eles. - Fazer o download do controlador de política do dispositivo por meio da adição de uma Conta do Google:quando uma Conta do Google que exige gerenciamento por um app controlador de política de dispositivo (DPC, na sigla em inglês) é adicionada a um dispositivo fora de um contexto gerenciado, o fluxo de adição de conta agora solicita que o usuário instale o WPC adequado. Esse comportamento também se aplica a contas adicionadas em 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 apenas para o usuário que fez a chamada. Chamá-lo pelo perfil gerenciado não afeta os apps de câmera em execução no usuário principal. - Além disso, o método
setKeyguardDisabledFeatures()
agora está disponível para proprietários de perfis e de dispositivos. - Um proprietário do perfil pode definir estas restrições de proteção de bloqueio:
KEYGUARD_DISABLE_TRUST_AGENTS
eKEYGUARD_DISABLE_FINGERPRINT
, que afetam as configurações de proteção de teclado do usuário pai do perfil.KEYGUARD_DISABLE_UNREDACTED_NOTIFICATIONS
, que afeta apenas as notificações geradas por aplicativos no perfil gerenciado.
- O uso dos métodos
DevicePolicyManager.createAndInitializeUser()
eDevicePolicyManager.createUser()
foi descontinuado. - O método
setScreenCaptureDisabled()
agora também bloqueia a estrutura de assistência quando um app do usuário específico está em primeiro plano. - O padrão de
EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM
agora é SHA-256. SHA-1 ainda é compatível 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.
- O
EXTRA_PROVISIONING_RESET_PROTECTION_PARAMETERS
foi removido para que o provisionamento de promoção NFC não possa desbloquear programaticamente um dispositivo protegido redefinido para a configuração original. - Agora você pode 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 do Android for Work são otimizadas para permissões de execução M, incluindo perfis de trabalho,
camada de assistência e outras. As novas APIs de permissão
DevicePolicyManager
não afetam apps anteriores ao M. - Quando os usuários saem da parte síncrona do fluxo de configuração iniciado com uma intent
ACTION_PROVISION_MANAGED_PROFILE
ouACTION_PROVISION_MANAGED_DEVICE
, o sistema agora retorna um código de resultadoRESULT_CANCELED
.
- Chamar o método
- Mudanças em outras APIs:
- Uso de dados: a classe
android.app.usage.NetworkUsageStats
foi renomeada comoNetworkStats
.
- Uso de dados: a classe
- Mudanças nas configurações globais:
- Estas configurações não podem mais ser definidas via
setGlobalSettings()
:BLUETOOTH_ON
DEVELOPMENT_SETTINGS_ENABLED
MODE_RINGER
NETWORK_PREFERENCE
WIFI_ON
- Estas configurações globais agora podem ser definidas via
setGlobalSettings()
:
- Estas configurações não podem mais ser definidas via