Según un conjunto de confirmaciones en AOSP, Google puede comenzar a restringir el acceso a API no documentadas u ocultas en Android P. Muchas aplicaciones de marca utilizan API ocultas para aumentar la funcionalidad, por lo que el efecto puede ser generalizado.
Actualización 28/02/18: Google ha publicado hoy una entrada de blog confirmando los cambios. Más detalles al final del artículo.
Si bien algunos entusiastas de Android están especulando De qué postre llevará el nombre la próxima versión de Android, hay algunos desarrollos interesantes detrás de escena. Hemos visto un pocos dignos de mención próximas funciones en Android P, pero un descubrimiento más reciente en el Proyecto de código abierto de Android (AOSP) ha demostrado ser mucho más interesante. Según estas confirmaciones recientes, es posible que las aplicaciones tengan restringido el acceso a las API que no están documentadas en el SDK de Android (como las API marcadas por el atributo @hide de javadoc).
Por qué esto importa
El kit de desarrollo de software (SDK) de Android proporciona a los desarrolladores las bibliotecas API y las herramientas que necesitan para probar y crear nuevas aplicaciones de Android. Con cada nueva versión de Android viene una gran cantidad de nuevas API que están disponibles para los desarrolladores a través del SDK de Android. Las API que están disponibles para una aplicación dependen de la versión de compilación SDK que establezca el desarrollador. Por eso Google
anfitriones de google páginas de documentación para cada clase y todos sus métodos que están disponibles en cada nivel de API. Este es el conjunto de API documentadas que están disponibles en el SDK oficial de Android. Puede explorar la lista de clases fácilmente utilizando una aplicación de Android, como la aplicación de búsqueda SDK de Android lanzada recientemente por Android Engineer. Jake Wharton.
Precio: Gratis.
4.1.
Sin embargo, no todas las API que están disponibles en cada versión de Android están documentadas por Google ni están disponibles en el SDK oficial de Android. A menudo hay API útiles que son indocumentado, pero no por ello dejan de ser muy útiles. No se recomienda que los desarrolladores creen sus aplicaciones utilizando API no documentadas u ocultas, pero muchos lo hacen porque simplemente no hay alternativa si quieren ofrecer una característica determinada. Los desarrolladores que utilizan API ocultas o no documentadas también pueden obtener una ventaja competitiva. ya que pueden ofrecer funciones que sus competidores, que se ciñen a las API ofrecidas por Android SDK: no se puede.
Si bien no puedo proporcionar una lista de aplicaciones que utilizan API no documentadas (los desarrolladores probablemente no compartan cuáles usan porque les daría una ventaja a sus competidores), la lista probablemente sea bastante grande. Por lo tanto, concluiría que prohibir el acceso a API ocultas sería importante. Mark Murphy, fundador de conocimiento común, está de acuerdo:
Estoy de acuerdo con la evaluación de que la prohibición masiva del acceso a elementos con anotaciones @ocultar será un gran problema, si eso sucede. Con suerte, pocas aplicaciones acceden a estos elementos como parte de una funcionalidad clave. Sin embargo, sospecho que muchas aplicaciones de marca las usan en ocasiones, directamente o a través de una biblioteca.
¿Qué está pasando en Android P?
Estos próximos cambios fueron notados por primera vez por el desarrollador reconocido senior de XDA. rovo89, el desarrollador de la Marco expuesto. Me señaló dos compromisos, uno de cual ha sido fusionado, que presenta una nueva herramienta de compilación llamada 'hiddenapi'. Esta herramienta modifica los indicadores de acceso de todos los miembros de la clase dentro de un archivo DEX si sus firmas aparecen en una lista gris o negra de entrada y, de ser así, los métodos marcados se tratarán como API internas con restricciones acceso. La otra confirmación describe cómo funciona la lista negra de API; impide el acceso a clase de arranque métodos y campos marcados por el 'hiddenapi' antes mencionado a los que los desarrolladores pueden acceder mediante enlaces estáticos, reflexión y JNI.
Según rovo89, el resultado final de estos dos cambios en Android P es el siguiente:
Si estas confirmaciones se fusionan, significaría que las aplicaciones ya no podrán usar/acceder a API ocultas, es decir. clases, métodos y campos que están anotados con @hide en AOSP y por lo tanto no forman parte del SDK oficial. Esto no sería un problema para los módulos Xposed ya que podría revertir fácilmente esas confirmaciones o permitir que los módulos también lo hagan. acceder a estas API. Pero hay muchas aplicaciones que aprovechan las API ocultas y fallarían en el futuro. futuro.
De hecho, más compromisos muestran que esto puede ser lo que Google está planeando. Este comprometerse afirma lo siguiente:
Si bien esta confirmación en particular no se fusionó, ya que se abandonó en favor de 3 confirmaciones más pequeñas, el mensaje de confirmación describe el propósito de estos cambios. Otro conjunto de se compromete muestra que Google sugerirá alternativas a los desarrolladores que busquen utilizar API no públicas:
Sin embargo, a menudo no existen alternativas a determinadas API ocultas. Nosotros en XDA podemos hablar por experiencia aquí como Desafortunadamente, este cambio puede significar el fin de algunas aplicaciones innovadoras, o puede requerir que algunas aplicaciones de renombre reduzcan su funcionalidad. Este próximo cambio parece similar en espíritu al reciente Medidas enérgicas contra los servicios de accesibilidad. (eso fue afortunadamente pausado mientras Google evaluaba usos innovadores). Si bien la mayoría de las aplicaciones que utilizan API no documentadas lo hacen por razones benignas, es posible que algunas aplicaciones las hayan hecho mal uso con fines nefastos.
Debido a esto, es posible que Google esté bloqueando el acceso a todas las API ocultas en Android P para proteger a los usuarios de los pocos que abusan de ellas. Es difícil decir qué impacto puede tener esto en los usuarios, pero si eres desarrollador considerando buscar en AOSP para encontrar un uso innovador de una API oculta, entonces es posible que desee reconsiderar.
Actualización: Google confirma
en un entrada en el blog Publicado hoy, 28 de febrero, Google ha confirmado estos cambios. Citando riesgos de fallas para los usuarios y posteriormente obligando a los desarrolladores a implementar soluciones de emergencia, Google afirma que la empresa ha ido cambiando gradualmente para disuadir a los desarrolladores de acceder a productos que no sean SDK interfaces. A partir de Android P, las restricciones se ampliarán para cubrir las interfaces del lenguaje Java del SDK.
La compañía afirma que "algunos métodos y campos que no pertenecen al SDK estarán restringidos", aunque no dieron más detalles sobre cuáles estarían restringidos. Inicialmente, la restricción se centrará en interfaces que rara vez se utilizan y, durante un tiempo, la empresa permitirá los desarrolladores continúen usando métodos y campos que no sean del SDK en los que la transición a un método del SDK sea técnicamente desafiante. Sin embargo, eventualmente las restricciones se ampliarán, por lo que los desarrolladores de aplicaciones que utilizan métodos que no son SDK deben realizar la transición lo antes posible en preparación para Android P. En cuanto a los métodos sin una alternativa de SDK, Google solicita a los desarrolladores que publiquen en sus localizador de bichos con más información.
La próxima vista previa para desarrolladores, que aparentemente llegará pronto, permitirá a los desarrolladores probar aplicaciones existentes en la lista negra o gris antes del lanzamiento final.