Starting with Android P, Google began slowly closing the door on the use of non-public APIs. The process began with method calls that had little or no known usage among app developers, but things changed when Android Q expanded the list of restricted interfaces to cover a larger selection. Now with Android 11, the crackdown continues as the Android team adds even more non-public APIs to the restricted list.

The use of private APIs is occasionally necessary to accomplish certain tasks with the OS that weren't made available through the SDK. It's not ideal, but it's sometimes the only way to get the desired behavior, especially in apps that come up with new and interesting features. Of course, the catch is that non-public method calls may be removed or change function without notice, which could lead to crashing apps or unintended behaviors.

Most developers stick to the official SDK while building apps, and that generally means they're not going to run into many issues with the new restrictions. However, most developers also use libraries from other sources, and it may not be immediately obvious if those include calls to restricted methods.

In either case, developers have a few ways to double check that their apps are not using any restricted APIs. The easiest method is to simply watch for lint warnings in Android Studio, but for a more exhaustive scan, it's worth running the veridex tool on an APK to see all explicit method calls. Unfortunately, neither option will identify private APIs called through JNI or reflection. To catch most of those, developers would have to either enable Strict Mode and capture events sent from the system when a restricted call is made, or just build a debug release of an app and watch for messages in the system log.

Google has split the non-public APIs into a blacklist for everything that is now entirely forbidden, a greylist for methods that are permitted up to certain API levels but will likely be treated as blacklist items in later versions of the OS, and a whitelist for everything that is an officially documented part of the framework, even though it's not part of the SDK. You can peruse the Android 11 greylist here to see the list of methods that are now restricted, and here's the Android 11 whitelist additions for everything that's safe to use.

If developers do come across any APIs that don't have public counterparts, there's a process for requesting additions to the SDK.

While this process unfortunately makes more work for app developers and sometimes takes away features that some of our favorite apps rely on, it is intended to improve security and prevent unintended crashes and bugs.