When I run my application in an emulator with the API 28, the console gives me the following warning:
W/oaristachimene: Accessing hidden method Landroid/view/View;->computeFitSystemWindows(Landroid/graphics/Rect;Landroid/graphics/Rect;)Z (light greylist, reflection) W/oaristachimene: Accessing hidden method Landroid/view/ViewGroup;->makeOptionalFitsSystemWindows()V (light greylist, reflection)
I have been debugging it and I found out that it comes from the call: setContentView(R.layout.activity_main)
, so is there another way to set the layout of an activity or is this method going to be updated so that it doesn't throws that warning when running on a device with android API 28?.
For the warnings in the question, computeFitSystemWindows
and makeOptionalFitsSystemWindows
are actually used by the support library or androidx library through reflection. You can verify it by simply searching those two methods in the AppCompatDelegateImpl
.
Hopefully this can be fixed later.
Update 1
Recently when I test app in Firebase Test Lab, these 2 APIs and some other APIs are marked
One possible root cause for this warning is Google-owned library UI Toolkit. No action need be taken at this time.
Or
One possible root cause for this warning is Google-owned library Android WebView. No action need be taken at this time.
Chances are good that the layout id you’re passing to setContentView()
contains some view from a 3rd-party library that uses non-SDK interfaces. This warning is telling you that this is happening, but all you can do is
For now, this is only a warning; nothing bad will actually happen. But in future versions of Android, it might become a real problem. The system is just giving you time to figure it out.
It's just a warning
.
You should read the Restrictions on non-SDK interfaces documentation.
Android 9 (API level 28) introduces new restrictions on the use of non-SDK interfaces, whether directly, via reflection, or via JNI. These restrictions are applied whenever an app references a non-SDK interface or attempts to obtain its handle using reflection or JNI. For more information about this decision, see Improving Stability by Reducing Usage of non-SDK Interfaces.
In general, apps should only use the officially documented parts of the classes in the SDK. In particular, this means that you should not plan to access methods or fields that are not listed in the SDK when you interact with a class via semantics such as reflection.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With