Overview of the Android internal API (com.android.internal) and the Hidden API (@hide)

Examples of internal APIs and hidden code

When flipping through the Android source code, there are some strange codes, such as the following:

Note: This code is in the source Android/provider/telephony.java. Import Android.util.patterns;import com.android.internal.telephony.smsapplication;import java.util.HashSet;//...

And this (this paragraph is excerpted from the same file):

/** *//comments ... * @hide * * public static Boolean isoutgoingfolder (int messageType) { Method Body ...}

What does this code mean?

Internal api:android.internal.*

In fact, in the source directory of the SDK, the so-called android.internal package is not found. The source code for all classes under this package is not visible and is intended for internal use by the system only. In general, under this package are the core features of Android system, not open interface and source code.

Hidden code: @hide

Unlike the internal API, the @hide tag is generally not an entire file or an external class, but is typically an inner class, function, or field, which is generally referred to as hidden code (I personally think that the code that is not open should not be called application programming Interface). These hidden codes are visible in the source code, but cannot be referenced directly.

The difference between the internal API and the hidden API

From Google's point of view, the use of two different ways, is to have their own consideration, the internal API is the core part of the system, do not plan to open to the outside. The core functionality of the system provides a certain amount of access through the framework, but it does not need to advertise its code.

The hidden API is more about security between different versions of Android. It is very likely that a developing, unstable feature is hidden until it is stable, mature, and open. Android does not appear in the API Level5 after the Bluetooth API, but in fact, the earlier source code already has this part, but is hidden by @hide. As you can imagine, if an application relies on the Bluetooth API of API 4, there is a good chance that an unpredictable problem will occur on the Android2.0 (API Level5) machine.

Of course, the internal code may also have such a change, but because it is a black box for developers, so its internal changes we can rest assured to Google.

The difference in the developer's eyes

Currently Android developers use the Eclispe ADT plugin to develop, for the general developer, the internal API and hidden code is no different, can not be used. However, there are always people who want to use these APIs for a variety of purposes.

At the time of development we use most of the library is the Android.jar package, the package has our use of almost all the features "do not exclude the use of Android-support-v4.jar." In the jar package, we can see that all the classes within the android.internal are gone, and similarly, the class does not contain fields, functions, and classes marked as @hide in the source code.

But when the application actually runs on the device, the system loads the Framework.jar package, which is not cropped and contains all the internal APIs and hidden code. So developers can call through the reflection mechanism.

In addition, when using Eclipse ADT, the ADT plugin specifically restricts access rules to the Android.internal package. Therefore, it is difficult to use the internal API even if the Android.jar under the project is replaced with an Android.jar package that is not cropped.

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M01/44/B8/wKioL1PiVCzwPqP3AAHzgbZLaZA239.jpg "title=" QQ picture 20140807000127.jpg "alt=" Wkiol1pivczwpqp3aahzgbzlaza239.jpg "/>

Using internal APIs and hiding code is not recommended

As mentioned earlier, in theory, developers can make calls to these functions using the reflection mechanism. However, the following issues must be faced:

• android version upgrade, its internal functionality or hidden code may change significantly, so the program used the code cannot ensure backward compatibility.

Reference: Using internal (com.android.internal) and Hiding (@hide) api[part 1th, Introduction]

This article is from the "Flying Cat" blog, be sure to keep this source http://flyingcat2013.blog.51cto.com/7061638/1536679