De acordo com um conjunto de commits no AOSP, o Google pode começar a restringir o acesso a APIs não documentadas ou ocultas no Android P. Muitos aplicativos de marca usam APIs ocultas para aumentar a funcionalidade, portanto o efeito pode ser generalizado.
Atualização 28/02/18: O Google publicou uma postagem no blog hoje confirmando as mudanças. Mais detalhes no final do artigo.
Embora alguns entusiastas do Android estejam especulando qual será o nome da sobremesa que dará nome à próxima versão do Android, há alguns desenvolvimentos interessantes acontecendo nos bastidores. Nós avistamos um poucos dignos de nota próximos recursos do Android P, mas uma descoberta mais recente no Android Open Source Project (AOSP) provou ser muito mais interessante. De acordo com esses commits recentes, os aplicativos podem ser impedidos de acessar APIs que não estão documentadas no Android SDK (como APIs marcadas pelo atributo @hide do javadoc).
Por que isso é importante
O Android Software Development Kit (SDK) fornece aos desenvolvedores bibliotecas de API e ferramentas necessárias para testar e criar novos aplicativos Android. Com cada nova versão do Android vem uma série de novas APIs que estão disponíveis para desenvolvedores por meio do Android SDK. Quais APIs estão disponíveis para um aplicativo dependem de qual compileSDKVersion o desenvolvedor define. É por isso que o Google
novos requisitos da Play Store são tão importantes que forçarão os aplicativos a atualizar e migrar para APIs mais recentes.Anfitriões do Google páginas de documentação para cada classe e todos os seus métodos disponíveis em cada nível de API. Este é o conjunto de APIs documentadas que estão disponíveis no SDK oficial do Android. Você pode navegar facilmente pela lista de classes usando um aplicativo Android, como o aplicativo Android SDK Search lançado recentemente pelo Android Engineer Jake Wharton.
Preço: Grátis.
4.1.
No entanto, nem todas as APIs disponíveis em cada versão do Android são documentadas pelo Google ou disponíveis no Android SDK oficial. Muitas vezes existem APIs úteis que são indocumentado, mas ainda assim são muito úteis. Não é recomendado que os desenvolvedores criem seus aplicativos usando APIs não documentadas ou ocultas, mas muitos o fazem porque simplesmente não há alternativa se quiserem oferecer um determinado recurso. Os desenvolvedores que usam APIs ocultas ou não documentadas também podem ter uma vantagem competitiva, já que podem oferecer recursos que seus concorrentes – que seguem as APIs oferecidas pelo Android SDK – não pode.
Embora eu não possa fornecer uma lista de aplicativos que utilizam APIs não documentadas (os desenvolvedores provavelmente não compartilham quais eles usam porque dariam uma vantagem aos seus concorrentes), a lista é provavelmente bastante grande. Assim, eu concluiria que proibir o acesso a APIs ocultas seria significativo. Mark Murphy, fundador da Software comum, concorda:
Concordo com a avaliação de que proibir em massa o acesso a itens anotados com @hide será um grande problema, se isso acontecer. Felizmente, poucos aplicativos acessam esses itens como parte de funcionalidades importantes. No entanto, suspeito que muitos aplicativos de marca os utilizam ocasionalmente, diretamente ou por meio de uma biblioteca.
O que está acontecendo no Android P?
Essas próximas mudanças foram observadas pela primeira vez pelo XDA Senior Recognized Developer rovo89, o desenvolvedor do Estrutura Xposed. Ele apontou dois commits para mim, um dos qual foi mesclado, que apresenta uma nova ferramenta de compilação chamada ‘hiddenapi.’ Esta ferramenta modifica os sinalizadores de acesso de todos os membros da classe dentro de um arquivo DEX se suas assinaturas aparecem em uma lista cinza ou lista negra de entrada e, nesse caso, os métodos marcados serão tratados como APIs internas com restrição acesso. O outro commit descreve como funciona a lista negra da API; impede o acesso a classe de inicialização métodos e campos marcados pelo mencionado 'hiddenapi' que os desenvolvedores podem acessar por meio de links estáticos, reflexão e JNI.
Segundo rovo89, o resultado final dessas duas mudanças no Android P é o seguinte:
Se esses commits forem mesclados, isso significaria que os aplicativos não poderão mais usar/acessar APIs ocultas, ou seja classes, métodos e campos que são anotados com @hide no AOSP e, portanto, não fazem parte do SDK oficial. Isso não seria um problema para os módulos Xposed, pois eu poderia facilmente reverter esses commits ou permitir que os módulos também acessar essas APIs. Mas há muitos aplicativos que tiram proveito de APIs ocultas, e esses falhariam no futuro.
Na verdade, outros compromissos mostram que isto pode ser o que o Google está planejando. Esse comprometer-se afirma o seguinte:
Embora este commit específico não tenha sido mesclado, pois foi abandonado em favor de 3 commits menores, a mensagem do commit descreve o propósito dessas alterações. Outro conjunto de compromete mostram que o Google irá sugerir alternativas para desenvolvedores que buscam usar APIs não públicas:
No entanto, muitas vezes não há alternativas para certas APIs ocultas. Nós do XDA podemos falar por experiência própria aqui como infelizmente, essa mudança pode significar o fim de alguns aplicativos inovadores ou pode exigir que alguns aplicativos de grande nome reduzam seu desempenho. funcionalidade. Esta próxima mudança parece semelhante em espírito à recente repressão aos serviços de acessibilidade (isso foi felizmente pausado conforme o Google avaliou usos inovadores). Embora a maioria dos aplicativos que utilizam APIs não documentadas o façam por motivos benignos, pode haver alguns aplicativos que as tenham utilizado indevidamente para fins nefastos.
Por causa disso, o Google pode estar bloqueando o acesso a todas as APIs ocultas no Android P, a fim de proteger os usuários dos poucos que abusam delas. É difícil dizer o impacto que isso pode ter sobre os usuários, mas se você for um desenvolvedor considerando pesquisar no AOSP para encontrar um uso inovador de uma API oculta, então você pode querer reconsiderar.
Atualização: Google confirma
Em um postagem no blog publicado hoje, 28 de fevereiro, o Google confirmou essas mudanças. Citando riscos de travamento para os usuários e subsequentemente forçando os desenvolvedores a implementar correções emergenciais, o Google afirma que a empresa tem mudado gradualmente no sentido de desencorajar os desenvolvedores de acessar não-SDK interfaces. A partir do Android P, as restrições serão expandidas para abranger as interfaces da linguagem Java do SDK.
A empresa afirma que “alguns métodos e campos não-SDK serão restritos”, embora não tenha especificado quais seriam restritos. Inicialmente a restrição se concentrará em interfaces raramente utilizadas e, por um tempo, a empresa permitirá desenvolvedores continuem a usar métodos e campos não-SDK onde a transição para um método SDK é tecnicamente desafiante. No entanto, eventualmente as restrições serão ampliadas, portanto, os desenvolvedores de aplicativos que usam métodos não SDK devem fazer a transição o mais rápido possível, em preparação para o Android P. Quanto aos métodos sem alternativa de SDK, o Google está solicitando que os desenvolvedores publiquem em seus rastreador de bugs com mais informações.
A próxima prévia do desenvolvedor, aparentemente chegando em breve, permitirá que os desenvolvedores testem os aplicativos existentes na lista negra ou na lista cinza antes do lançamento final.