The @hide Penny Drops

As XDA Developers originally reported, and as I covered ~6 weeks ago, Google is going to start blocking your ability to access classes and members marked with the @hide pseudo-annotation, as part of Android P (Pretzel? Pumpernickel? Pumpernickel Pretzel?).

They indicate that this will be a phased rollout, stating that “Initially, this restriction will impact interfaces with low or no usage”. So, right now, we do not know exactly what will and will not be blocked. My guess is that they will roll out these restrictions over 2-3 releases.

The upcoming developer preview is supposed to offer warnings when you are using “a non-SDK interface that will be subject to blacklist or greylist in the final release”. That will tell you the stuff that you really need to fix quickly, lest your code start to fail outright on Android P devices.

However, I do not recommend that you wait around for the developer preview.

Developers should start examining their code bases for any signs of using reflection to access hidden members: Class.forName(), getConstructor(), getField(), and so on. This is particularly important for library authors, as issues with a library get amplified by the number of library users.

The big reason is that Google has set up a dedicated issue tracker component for requests to make formerly-private APIs public. The results of filing issues on the issue tracker can be generously described as “mixed”. However, what has become clear is that Google does not make changes to a release once the first developer preview has shipped, outside of egregious problems. So, if you want some APIs to be made public for 2019’s Android Q, you had best get those requests filed quickly, so that they can get in the pipeline. Plus, if it happens that your desired API collides with a plan for Android P’s “blacklist or greylist”, the faster that you get your request into the system, the more likely it is that it will have a positive effect.

Note that not all uses of reflection will need to result in changes in Android P. Of note:

• Using reflection for accessing your own code is fine, if perhaps heavyweight

• Using reflection for accessing things on older devices, where newer devices have some official solution, will not change based on Android P’s release – while this is still risky, the risk is not any greater now than before

• Using reflection for accessing manufacturer-supplied libraries – the kind that you need to use <uses-library> for in the manifest – should be unaffected by this change

Once a developer preview of Android P is released, hopefully we can work out a list of the affected hidden items that are on the “blacklist or greylist”.

So, a partial ban on @hide is real, and its results may be spectacular… in terms of the amount of wailing and gnashing of teeth that we will see on Stack Overflow. The sooner you come to grips with how it will affect your app, the better off you will be.