page.title=Mudanças de comportamento page.keywords=preview,sdk,compatibility sdk.platform.apiLevel=MNC @jd:body
Junto com novas capacidades e recursos, o M Developer Preview inclui uma variedade de mudanças do sistema e alterações no comportamento da API. Este documento destaca algumas das alterações principais que você deve entender e levar em consideração nos aplicativos.
Caso tenha publicado anteriormente um aplicativo para Android, saiba que ele pode ser afetado pelas alterações na plataforma.
Esta prévia introduz um novo modelo de permissões em que os usuários podem gerenciar diretamente as permissões do aplicativo no tempo de execução. Este modelo fornece aos usuários uma visibilidade aprimorada e controle sobre permissões, ao mesmo tempo em que agiliza os processos de atualização automática e instalação para os desenvolvedores de aplicativos. Os usuários podem conceder ou revogar as permissões individualmente para os aplicativos instalados.
Nos aplicativos direcionados para o M Preview, certifique-se de verificar e solicitar as permissões no tempo de execução. Para determinar se o aplicativo recebeu uma permissão, chame o novo método {@code Context.checkSelfPermission()}. Para solicitar uma permissão, chame o novo método {@code Activity.requestPermission()}. Mesmo se o aplicativo não é direcionado para o M, deve-se testá-lo sob o novo modelo de permissões.
Para obter mais detalhes sobre o suporte do novo modelo de permissões no aplicativo, consulte a página de prévia de desenvolvedor Permissões. Para obter dicas sobre como avaliar o impacto no aplicativo, consulte o guia de teste.
Esta prévia introduz novas otimizações de economia de energia para dispositivos e aplicativos ociosos.
Se o dispositivo estiver desconectado e parado com a tela desligada por um período, o modo Soneca será ativado, onde ele tentará manter o sistema em um estado ocioso. Neste modo, os dispositivos retomam as operações normais periodicamente por breves períodos para que a sincronização de aplicativos possa ocorrer e para que o sistema possa realizar quaisquer operações pendentes.
As seguintes restrições se aplicam aos aplicativos durante a Soneca:
Quando o dispositivo sair do modo soneca, quaisquer sincronizações e trabalhos pendentes são executados.
É possível testar este recurso conectando o dispositivo executando o M Preview à máquina de desenvolvimento e chamando os seguintes comandos:
$ adb shell dumpsys battery unplug $ adb shell dumpsys deviceidle step $ adb shell dumpsys deviceidle -h
Observação: o próximo lançamento do Google Cloud Messaging permite que você designe mensagens de alta prioridade. Se o aplicativo recebe mensagens de alta prioridade do GCM, um acesso breve à rede é concedido mesmo quando o dispositivo está no modo soneca.
Consulte o guia de teste para obter dicas sobre como testar a soneca nos aplicativos.
Com esta prévia, o sistema pode determinar quais aplicativos estão em espera quando não estão em uso ativo. O aplicativo é considerado em espera após um período, a não ser que o sistema detecte algum destes sinais:
Se o dispositivo estiver desconectado, o aplicativo considerado ocioso terá o acesso à rede desativado e as sincronizações e os trabalhos suspensos. Quando o dispositivo está conectado em uma fonte de alimentação, esses aplicativos têm acesso à rede permitido e podem executar quaisquer sincronizações e trabalhos pendentes. Se o dispositivo permanece ocioso por longos períodos, os aplicativos ociosos têm acesso à rede permitido aproximadamente uma vez por dia.
É possível testar este recurso conectando o dispositivo executando o M Preview à máquina de desenvolvimento e chamando os seguintes comandos:
$ adb shell dumpsys battery unplug $ adb shell am set-idle <packageName> true $ adb shell am set-idle <packageName> false $ adb shell am get-idle <packageName>
Observação: o próximo lançamento do Google Cloud Messaging (GCM) permite que você designe mensagens de alta prioridade. Se o aplicativo recebe mensagens de alta prioridade do GCM, um acesso breve à rede é concedido mesmo quando o aplicativo está ocioso.
Consulte o guia de teste para obter dicas sobre como testar a espera dos aplicativos.
Com esta prévia, os usuários podem adotar dispositivos de armazenamento externo como cartões SD. Adotar um dispositivo de armazenamento externo criptografa e formata o dispositivo para agir como um armazenamento interno. Este recurso permite que os usuários movam aplicativos e dados privados desses aplicativos entre dispositivos de armazenamento. Ao mover aplicativos, o sistema respeita a preferência {@code android:installLocation} no manifesto.
Se o aplicativo acessar as seguintes APIs ou campos, saiba que os caminhos de arquivos retornados serão alterados dinamicamente quando o aplicativo for movido entre os dispositivos de armazenamento externo e interno. Ao compilar caminhos de arquivos, é recomendado que essas APIs sempre sejam chamadas dinamicamente. Não use caminhos de arquivo criptografados nem persista em caminhos de arquivo completamente qualificados que foram compilados anteriormente.
Para depurar este recurso na prévia de desenvolvedor, é possível ativar a adoção de uma unidade USB que está conectada a um dispositivo Android por meio de um cabo USB On-The-Go (OTG) executando este comando:
$ adb shell sm set-force-adoptable true
Esta prévia remove o suporte para o cliente Apache HTTP. Se o aplicativo estiver usando este cliente e for direcionado para Android 2.3 (nível da API 9) ou mais recente, use a classe {@link java.net.HttpURLConnection}. Esta API é mais eficiente, pois reduz o uso de rede por meio de compressão transparente e armazenamento em cachê de respostas, além de minimizar o consumo de energia. Para continuar usando as APIs do Apache HTTP, deve-se primeiro declarar a dependência de tempo de compilação no arquivo {@code build.gradle}:
android { useLibrary 'org.apache.http.legacy' }
O Android está mudando da biblioteca OpenSSL para BoringSSL . Caso esteja usando o Android NDK no aplicativo, não vincule contra bibliotecas criptográficas que não fazem parte da API de NDK, como {@code libcrypto.so} e {@code libssl.so}. Estas bibliotecas não são APIs públicas e podem mudar ou apresentar erros sem notificar entre liberações e 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 com relação a uma biblioteca criptográfica de sua escolha.
Ajustar o volume diretamente ou desativar o áudio de transmissões específicas por meio da classe {@link android.media.AudioManager} não são mais recursos suportados. O método {@link android.media.AudioManager#setStreamSolo(int,boolean) setStreamSolo()} é obsoleto e deve-se chamar o método {@code AudioManager.requestAudioFocus()}. De forma semelhante, o método {@link android.media.AudioManager#setStreamMute(int,boolean) setStreamMute()} é obsoleto; em vez disso, chame o método {@code AudioManager.adjustStreamVolume()} e passe o valor da direção de {@code ADJUST_MUTE} ou {@code ADJUST_UNMUTE}.
Quando os usuários selecionam o texto no aplicativo, agora é possível exibir ações de seleção de texto como Recortar, Copiar e Colar na barra de ferramentas flutuante. A implementação da interação do usuário é semelhante ao processo da barra de ação contextual, como descrito em Ativação do modo de ação contextual para vistas individuais.
Para implementar uma barra de ferramentas flutuante para seleção de texto, faça as seguintes alterações nos aplicativos existentes:
Caso esteja usando a biblioteca de suporte Android revisão 22.2, saiba que as barras de ferramentas flutuantes não têm compatibilidade com versões anteriores e que o appcompat tem controle sobre os objetos {@link android.view.ActionMode} por padrão. Isto evita que barras de ferramentas flutuantes sejam exibidas. Para ativar o suporte de {@link android.view.ActionMode} em um {@link android.support.v7.app.AppCompatActivity}, chame {@code android.support.v7.app.AppCompatActivity.getDelegate()} e, em seguida, chame {@code android.support.v7.app.AppCompatDelegate.setHandleNativeActionModesEnabled()} no objeto {@link android.support.v7.app.AppCompatDelegate} retornado e defina o parâmetro de entrada para {@code false}. Esta chamada retorna o controle dos objetos {@link android.view.ActionMode} à estrutura. Em dispositivos que são executados no M Preview, isto permite que a estrutura suporte os modos de {@link android.support.v7.app.ActionBar} ou de barra de ferramenta flutuante, enquanto que, para dispositivos anteriores ao M Preview, somente os modos {@link android.support.v7.app.ActionBar} são suportados.
Com esta prévia, o provedor Android Keystore não suporta mais DSA. ECDSA ainda é suportado.
As chaves que não exigem criptografia em rest não precisam ser excluídas quando a tela de bloqueio segura é desativada ou redefinida (por exemplo, pelo usuário ou por um administrador do dispositivo). As chaves que exigem criptografia serão excluídas durante esses eventos.
Esta prévia introduz as seguintes alterações de comportamento nas APIs de rede e Wi-Fi.
Nesta prévia, 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 onde os processos de alta prioridade são favorecidos. As mudanças no comportamento do serviço incluem:
O tempo de execução de ART agora implementa adequadamente as regras de acesso para o método {@link java.lang.reflect.Constructor#newInstance(java.lang.Object...) newInstance()}. Esta alteração corrige um problema onde o Dalvik estava verificando as regras de acesso incorretamente em versões anteriores. Se o aplicativo usa o método {@link java.lang.reflect.Constructor#newInstance(java.lang.Object...) newInstance()} e você quer substituir as verificações de acesso, chame o método {@link java.lang.reflect.Constructor#setAccessible(boolean) setAccessible()} com o parâmetro de entrada definido como {@code true}. Se o aplicativo usar a biblioteca v7 appcompat ou a biblioteca v7 recyclerview, deve-se atualizá-lo para usar as versões mais recentes dessas bibliotecas. Caso contrário, certifique-se de que as classes personalizadas mencionadas a partir do XML sejam atualizadas para que os construtores de classe estejam acessíveis.
Esta prévia atualiza o comportamento do vinculador dinâmico. O vinculador dinâmico agora entende a diferença entre um {@code soname} da biblioteca e o seu caminho ( erro público 6670), e a pesquisa por {@code soname} agora está implementada. Os aplicativos que anteriormente trabalhavam e têm entradas {@code DT_NEEDED} inválidas (geralmente, caminhos absolutos no sistema de arquivo na máquina de programação) podem falhar ao serem carregados.
O sinalizador {@code dlopen(3) RTLD_LOCAL} agora está corretamente implementado. Observe que {@code RTLD_LOCAL} é o padrão. Portanto, chamadas para {@code dlopen(3)} que não usam explicitamente {@code RTLD_LOCAL} serão afetadas (a não ser que o aplicativo tenha usado explicitamente {@code RTLD_GLOBAL}). Com {@code RTLD_LOCAL}, os símbolos não estarão disponíveis para as bibliotecas carregadas por chamadas posteriores a {@code dlopen(3)} (o oposto ocorre quando mencionado por entradas {@code DT_NEEDED}).
A plataforma agora realiza validações mais estritas de APKs. Um APK é considerado corrompido se um arquivo for declarado no manifesto, mas não estiver presente no próprio APK. Um APK deve ser atribuído novamente se qualquer conteúdo for removido.
Esta prévia inclui as seguintes mudanças de comportamento para Android for Work: