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.