Use internal (com.android.internal) and Hide (@hide) api[1th, Introduction]

This article translated from http://devmaze.wordpress.com/2011/01/18/using-com-android-internal-part-1-introduction/#more-79

Android has two types of APIs that are not available in the SDK.

The first class is the API that is located in package com.android.internal , which I call the internal API. The second type of API is the class and function marked with @hide , although strictly speaking it is not an API but a collection of hidden APIs, I still assume this is an API, called the hidden API.

Examples of hidden APIs

You read the source code of Android, you will find some constants, functions and classes marked as @hide.

Here is an example of a hidden constant from Wifimanager (source code of API level 10).

Another example is the hidden function setwifiappenabled, from Wifimanager (source code of API level 10).

So you just see the @hide property, which is a hidden API.

The difference between the internal API and the hidden API

Hide API shadowing is to prevent developers from using parts of the SDK that are incomplete or not stable (interface and schema). For example, the Bluetooth API existed before API Level 5 (Android 2.0), but was hidden in API Level 3 and 4 (Android 1.5 and 1.6) using @hide. When the API stabilizes, Google's developers remove the @hide attribute, and there is a Bluetooth API in API level 5. There are a lot of things that have changed between level 4 and 5. If the program relies on some hidden APIs, there may be a problem running on the new version of Android OS.

The internal API is not intended to be open to the outside. This is an in-house restaurant for Android, and developers can treat it as a black box. Things like this are also subject to change. Similarly, if your program relies on internal APIs, you may experience trouble after the new Android release.

The differences between them are summarized below:

Hide API = under development;

Internal API = Black box

Compile-time and run-time comparisons of internal and hidden APIs

When you use the Android SDK for development, a very important jar file Android.jar is referenced. It is located in the Android SDK platform directory Sdk_dir/platforms/platform-x/android.jar (where X is the API level, which can be 5 or 10 or other numbers). In Android.jar, all classes in com.android.internal are removed, and similarly, all classes, enumerations, fields, and methods that are marked as @hide are removed.

But when you run the application on the device, the load is Framework.jar (approximately equivalent to Android.jar), it is not trimmed, it contains all the inner classes and the hidden API. So you can use the reflection mechanism to access the hidden API and the internal API (which, of course, is inconvenient to use, and I'll show you how to access these APIs without using the reflection mechanism).

There are some special information about the internal API. Eclipse's ADT plugin adds an additional rule that prohibits the use of anything from the com.android.internal package. So, even if you use raw (non-trimmed) Android.jar, it's not easy to use an internal API in eclipse.

You can check it yourself. Create a new Android project in Eclipse (or use an existing one) and view its reference library (right-click Project,properties–> Java Build path–> Libraries).

Important Summary: The internal API and the stealth API are handled essentially the same way in the SDK (all removed from Android.jar), but the internal API is disabled in the Eclipse ADT plugin.

Not using the internal API and stealth API through the reflection mechanism

The ultimate goal of this series of articles is to give programmers the means to use internal APIs and hide APIs without reflection. If you have completed all the steps in the following article, you will be able to use the internal API and the Hide API as you would with the official API, and there is no need to use reflection.

But if you use these nonpublic APIs, you must be aware that there is a huge risk. There is no guarantee that these APIs will not change after the Android OS upgrade, and that there is no guarantee of consistent behavior across different devices in different manufacturers. It all depends on you.

The following three scenarios are available:

1. Open the internal API and hide API (scenario a)
2. Open hidden API only (scenario B)
3. Open Internal API only (scenario C)

Scenario A is a synthesis of scenes B and C. Scenario B is the simplest (no need to modify the Eclipse ADT plugin).

Scenario A: Reading 1,2,3,4,5

Scenario B: Reading 1,2,3,5

Scenario C: Reading 1,2,3,4,5

Original: http://mogoweb.net/archives/87