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](https://developer.android.google.cn/static/images/android-6.0/text-selection.gif?authuser=9&hl=pt)
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:
- No objeto
View
ouActivity
, mude oActionMode
chamada destartActionMode(Callback)
parastartActionMode(Callback, ActionMode.TYPE_FLOATING)
. - Use sua implementação atual de
ActionMode.Callback
para que ela se estendaActionMode.Callback2
. - Substitua o
onGetContentRect()
para fornecer as coordenadas do conteúdo do objetoRect
(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 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 ObjetosWifiConfiguration
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çãodisableAllOthers=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 atargetSdkVersion
do app for“20”
ou anterior, ele será fixado ao selecionado Rede Wi-Fi. Se atargetSdkVersion
do app for a versão“21”
ou mais recente, use o APIs de várias redes (comoopenConnection()
,bindSocket()
, e a novabindProcessToNetwork()
) 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 emonError()
sendo chamava o cliente despejado. Na APICamera2
, isso resulta emonDisconnected()
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()
comotrue
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ê definesetBluetoothContactSharingDisabled()
comofalse
. Por padrão, ele é definido comotrue
. - 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:
KEYGUARD_DISABLE_TRUST_AGENTS
eKEYGUARD_DISABLE_FINGERPRINT
, que afetam configurações de bloqueio de teclado para o usuário pai do perfil.KEYGUARD_DISABLE_UNREDACTED_NOTIFICATIONS
, que afeta apenas as notificações geradas por aplicativos no perfil gerenciado.
- Os métodos
DevicePolicyManager.createAndInitializeUser()
eDevicePolicyManager.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
ouACTION_PROVISION_MANAGED_DEVICE
, o sistema agora retorna um código de resultadoRESULT_CANCELED
.
- Chamar o
- Mudanças em outras APIs:
- Uso de dados: a classe
android.app.usage.NetworkUsageStats
foi renomeadaNetworkStats
.
- 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