What do you think about Android 9.0 to disable the call @Hide Api?

Android 9.0?

Hi, everyone, I am the Incense ink shadow!

Released from Android 8.0, it has been five months, although the share is not high, however, Google has begun to prepare the next version of the Android system.

Last week, according to the news of rapid technology explosion, someone in the XDA community found the latest AOSP (Android Open source Project) submission record, suspected to be the next-generation Android system version of the code: PI, which may be the version name of Android 9.0. However, according to the previous version of Android naming habits, Google love to use dessert to name the version, many people guess Pi may be a pie (PIE) abbreviation.

In AOSP's latest commit, some special information is exposed that may begin to restrict calls to non-public APIs that are not referenced by the document, such as APIs that are labeled @hide .

The above is a commit, interested can go here AOSP to see the details.

https://android-review.googlesource.com/c/platform/external/doclava/+/589515

Simply looking at this commit change, you can see that a privatedexapiwriter is added to the stubs, which should be used to record the methods that are marked @hide .

Specifically used to do what, also did not delve into, but simply from this commit to see the content of speculation, should be to start restricting access to some @hide APIs.

So let's go ahead and think about what Google wants to do to limit the @hide invocation of APIs, something that needs to be considered.

@hide method

As is known to all, Android systems are increasingly focusing on security as part of the iterative process. While some of the methods may involve system security, user privacy, or some other reason, there are a number of factors that, when published, are flagged by Google to @hide indicate that they do not want developers to use them.

And these are tagged @hide methods that we cannot call directly, and only use reflection to invoke them, which in itself is an unsafe operation.

However, we do sometimes need to use these tagged methods in order to achieve some functionality @hide .

From the description of the commit mentioned earlier, it can be seen that this restriction is dex-level layer, that is, it should be able to ignore the reflection call. For example, add a permission limit, call the time to judge the right to call the direct error or let you reflect the time of the call, also can not work, in fact, is the limit of the way, and now do not have to delve into the principle.

Support Library

While Google is able to @hide limit its approach, one thing we don't know is that the support Library contains a lot @hide of APIs.

For example, in the recent implementation of the Autosizing feature, it is used specifically to write a method to make a reflection call and get some property values in the TextView.

    Private<T> TInvokeandreturnwithdefault(@NonNullObject Object,@NonNull FinalString MethodName,@NonNull FinalT defaultvalue) {T result =NULL;BooleanExceptionThrown =false;Try{//Cache lookup.Method method =Gettextviewmethod(MethodName); result = (T) method.Invoke(object); }Catch(Exception ex) {ExceptionThrown =true; Log.W(TAG,"Failed to invoke textview#"+ MethodName +"() method", ex); }finally{if(Result = =NULL&& exceptionthrown) {result = DefaultValue; }        }returnResult }

Google provides a library of support libraries that are essentially some of the APIs extensions that Google has prepared for developers, but it is different from the APIs of the system itself.

We are developing the Android phase, we will specify an API level, from the performance of the IDE, it will refer to a android.jar, essentially for our development phase can be successfully compiled, the jar package itself will not be packaged in the APK.

In the support Library is not the same, it is just a toolkit provided by Google, will be really compiled into the APK, will occupy the size of the APK. That's why support V26 has removed some of the methods to make the volume smaller, which is a pleasant thing to do.

And if Google has a one-size-fits- @hide all approach, some of the features in the support Library should also be affected because it's essentially the code in our APK, the same permission level as the code we wrote in our development.

So there's a problem in two directions:

1. Distinguish between calls from the support Library and developer calls.

2, fits, directly modify the support Library source code and system source code, re-examine those now labeled @hide methods, will not affect the security and privacy of the APIs are all open, allowing developers to invoke.

Here we continue to open the brain hole, carefully talk about these differences.

1. Distinguish the calling source

If Google has a way to differentiate where calls come from, then different call rights controls are implemented for different invocation sources.

For developers, there is actually a loophole that allows us to simulate a call from the support Library, and we can still bypass the restrictions that do not allow calling @hide methods, which is obviously a hidden hazard.

2, fits

As you can see from the code in the existing support Library, the @hide approach that it uses is not all about security and privacy.

For the recently analyzed autosizing, it calls a number of TextView such as, and getHorizontallyScrolling() getLineSpacingMultiplier() getLineSpacingExtra() methods that do not actually touch security and privacy.

Just to get the properties of a text control, what could be unsafe or private? After careful consideration, it is good to take away these methods @hide , open calls, there is no need to distinguish so much.

Conclusion

The above are my simple guess and after the idea of open brain hole, said so much, Android still for the direction of security, ease of use, so whether it is limited or unlimited, is to make the user good use.

What is your unique view on Google's possible restrictions on @hide the invocation of APIs? Welcome to share in the message area!

Today, in the background of incense Ink Shadow Public, reply to " growth ". I will send you some of my study materials.

I also maintained a group of technical exchanges, interested in the public can reply back: "Add Group"

Recommended reading:

• From the perspective of Android development, talk about Airbnb's Lottie
• These tools allow you to write a blog when you only need to focus on writing!
• Looking for a day without a Bug? Try Git's dichotomy!!!
• How to search the Open Source Library on Github more precisely? You need these tricks!
• Android Development, encounter Emoji headache?

What do you think about Android 9.0 to disable the call @Hide Api?