Cuando ejecuto mi aplicación en un emulador con la API 28, la consola me da la siguiente advertencia:

W / oaristachimene: acceso al método oculto Landroid / view / View; -> computeFitSystemWindows (Landroid / graphics / Rect; Landroid / graphics / Rect;) Z (lista gris, reflexión) W / oaristachimene: acceso al método oculto Landroid / view / ViewGroup; -> makeOptionalFitsSystemWindows () V (lista de luz, reflexión)

Lo he estado depurando y descubrí que proviene de la llamada: setContentView(R.layout.activity_main), entonces, ¿hay otra manera de configurar el diseño de una actividad o este método se actualizará para que no arroje eso? advertencia cuando se ejecuta en un dispositivo con Android API 28 ?.

18
Iván Gómez 17 sep. 2018 a las 00:24

4 respuestas

La mejor respuesta

Para las advertencias en la pregunta, computeFitSystemWindows y makeOptionalFitsSystemWindows son realmente utilizados por la biblioteca de soporte o la biblioteca androidx a través de la reflexión. Puede verificarlo simplemente buscando esos dos métodos en AppCompatDelegateImpl.

Sí, rompen algunas reglas establecidas por ellos. Esperemos que esto pueda arreglarse más tarde.

Actualización 1

Recientemente, cuando pruebo la aplicación en Firebase Test Lab, estas 2 API y algunas otras API están marcadas

Una posible causa raíz de esta advertencia es la biblioteca de propiedad de Google UI Toolkit. No es necesario tomar medidas en este momento.

O

Una posible causa raíz de esta advertencia es la biblioteca Android WebView propiedad de Google. No es necesario tomar medidas en este momento.

30
Dewey Reed 24 oct. 2019 a las 04:05

Es probable que la identificación de diseño que está pasando a setContentView() contenga alguna vista de una biblioteca de terceros que utiliza interfaces que no son SDK. Esta advertencia te dice que esto está sucediendo, pero todo lo que puedes hacer es

  • Espera a que la tercera persona arregle su biblioteca
  • Eliminar esas vistas de terceros de su diseño

Por ahora, esto es solo una advertencia; nada malo sucederá realmente. Pero en las versiones futuras de Android, podría convertirse en un problema real. El sistema solo te está dando tiempo para resolverlo.

4
Ben P. 16 sep. 2018 a las 22:57

Para aquellos que obtienen Accessing hidden method XYZ en Android 9 (Pie, API 28):

Algunos métodos incluidos en la lista gris de Android 9 se incluyeron en la lista blanca de Android 10. Antes de buscar cualquier alternativa a los métodos incluidos en la lista gris, marque https://developer.android.com/about/versions/10/non-sdk-q#greylist-now-public

Esto no se aplica a los métodos en la pregunta de OP (computeFitSystemWindows, makeOptionalFitsSystemWindows) en este momento, pero puede cambiar en futuras versiones de Android.

Consulte también https://developer.android. com / about / version / 10 / non-sdk-q # greylist-now-restricte que presenta:

interfaces no SDK de la lista gris en Android 9 (nivel de API 28) que ahora están restringidas en Android 10 (nivel de API 29). Siempre que sea posible, se sugieren API alternativas en un comentario que sigue al nombre de la interfaz.

P.ej. Todos los métodos comunes informados por Android 9 light greylist filter:

Accessing hidden method Landroid/graphics/drawable/Drawable;->getOpticalInsets()Landroid/graphics/Insets; (light greylist, linking)
Accessing hidden field Landroid/graphics/Insets;->left:I (light greylist, linking)
Accessing hidden field Landroid/graphics/Insets;->right:I (light greylist, linking)
Accessing hidden field Landroid/graphics/Insets;->top:I (light greylist, linking)
Accessing hidden field Landroid/graphics/Insets;->bottom:I (light greylist, linking)

Ahora están incluidos en la lista blanca en Android 10, por lo que la advertencia logcat se puede ignorar de forma segura (al menos hasta Android 11, que puede volver a incluirlos en la lista gris :)).

0
dominik 12 nov. 2019 a las 00:13

Es solo un warning.

Debe leer las Restricciones en la documentación de las interfaces que no son SDK .

Android 9 (API nivel 28) introduce nuevas restricciones en el uso de interfaces que no son SDK, ya sea directamente, a través de la reflexión o mediante JNI. Estas restricciones se aplican cada vez que una aplicación hace referencia a una interfaz que no es SDK o intenta obtener su identificador mediante reflexión o JNI. Para obtener más información sobre esta decisión, consulte Mejora de la estabilidad reduciendo el uso de interfaces que no son SDK.

En general, las aplicaciones solo deben usar las partes documentadas oficialmente de las clases en el SDK. En particular, esto significa que no debe planear el acceso a métodos o campos que no figuran en el SDK cuando interactúa con una clase a través de la semántica, como la reflexión.

1
Skizo-ozᴉʞS 16 sep. 2018 a las 21:42