How Android calls the @hide and internal APIs

 How Android calls the @hide and internal APIs2012-12-11 16:21 8772 People read Comments (3) favorite reports Classification:Android Development (277)

Android has two types of APIs that are not accessible through the SDK.

The first is the API that is located in the Com.android.internal package. I'll call it the internal API. The second type of API is a series of classes and methods that are marked as @hide properties. Strictly speaking, this is not a single API, but a small set of hidden API, but I still assume it as an API, and called the Hidden API.

Hidden API Example

You can check the source code of Android, and can find some variables, functions and classes, etc., are marked by the @hide attribute.

The following example is a variable that is hidden in Wifimanager (API 10 source code).

Another example is the hidden setwifiapenabled function in Wifimanager (API 10 source code).

So, as long as you see the @hide attribute, you see the hidden API.

Differences between the internal and hidden APIs

The Hidden API is hidden to prevent developers from using parts (interfaces or schemas) that are incomplete or unstable in the SDK. For example, the Bluetooth API is open on API 5 (Android 2.0) and is hidden with the @hide attribute on both APIs 3 and 4. When these APIs are verified and cleaned, Google's developers will remove the @hide attribute and make it official in API 5. Many places have changed between APIs 4 and 5. If your program relies on some hidden APIs, it can get into trouble when it deploys to a new platform.

For the internal API, there has never been a plan to open it. It is the "inside kitchen" of Android and should be seen as a black box for developers. Everything is going to change. If you rely on some internal APIs, it's also possible that these internal APIs will change on the new Android release, which can disappoint you.

Summarize the difference:

Hidden API = working in progress;

Internal API = black box;

Compile-time vs. Runtime for internal and hidden APIs

When you use the Android SDK for development, you reference a very important jar file,--android.jar. It is located in the folder of the Android SDK platform (Sdk_dir/platforms/platform-x/android.jar, where X represents the API level). This android.jar removes all classes in the Com.android.internal package, and also removes all classes, enumerations, fields, and methods that are tagged with @hide.

But when you start the application on the device, it loads Framework.jar (simply, it is equivalent to Android.jar), and it does not remove the internal API and hidden API. (but it's not accessible to developers, so I'll show you how to use these APIs without reflection).

There is one more thing to note about the internal API. Eclipse's ADT plugin adds an additional rule that prohibits the use of anything in the Com.android.internal package. So, even if we can get the most primitive Android.jar (not abridged version), there is no easy way to use these internal APIs through eclipse.

You can check it yourself. Create a new Android project (or use existing ones). Look at the class library it references (right-click Project properties–> Java Build path–> Libraries).

Important summary: The internal and hidden APIs are handled the same way in the SDK (all removed from Android.jar), but the internal API is also explicitly banned by Eclipse's ADT plugin.

Using the internal and hidden APIs without reflection

The ultimate goal of these articles is to enable developers to use the internal and hidden APIs without reflection. If you have completed the steps described in the next section, you will be able to use these internal and hidden APIs, as in the public API. You no longer need to use reflection.

Note: If you are using these non-public APIs, you must know that your program is at great risk. Basically, there is no guarantee that these APIs will not be compromised at the next Android OS update, and there is no guarantee that different carriers have consistent behavior. You decide it yourself.

Next there are three scenarios:

1. Internal and Hidden APIs are available (scenario a)

2. Only hidden API is available (scenario B)

3. Only internal API is available (scenario C)

Scene A is the sum of B and C. Scenario B is the simplest one (no need to modify the ADT for Eclipse).

Scene A: Read Part1, 2, 3, 4, 5

Scenario B: Reading Part1, 2, 3, 5

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

I explained why we would have difficulty using the internal and hidden APIs without reflection. This is because the APIs are not included in Android.jar, so no one can reference these classes at compile time.

This article will describe how to restore the original Android.jar. This will allow us to use the internal and hidden APIs in the same way that we use public APIs.

How to get the original Android.jar?

We need to modify android.jar so that it can contain all the *.class files (including the internal and hidden API classes). There are two ways to do this:

1) Android is an open source project. We can download the source code and build the compilation environment so that it cannot remove the classes of internal and hidden. This method is more difficult;

2) each simulator or real machine will have an equivalent android.jar when running. We can get the jar file from here, extract the original. class file, and copy it to the Android SDK Android.jar.

I will adopt scenario 2. It's easy to start, doesn't need to build Linux environments and build environments.

Get Framework.jar from your device

You can use the command line (adb pull) to download files from an emulator or device, or use DDMS (with an app in Eclipse or the SDK).

Note: The emulator usually contains code in the. dex file, and the real machine typically contains the code--odex file in the optimized version of the Dex file. Manipulating the Odex file is difficult, which is why I chose the emulator.

Files that are equivalent to Android.jar in the Android SDK are framework.jar. This file is located on the device:/system/framework/framework.jar

ADB Pull/system/framework/framework.jar

When Framework.jar is down from the device, rename it to Framework.zip and unzip it into a separate folder, which looks like this:

Classes.dex is exactly what we need.

Create Framework-classes.zip

First, we need to convert. dex files to. jar format. You can use the generic tool Dex2jar. Only need to run:

Dev2jar Classes.dex

When the conversion is over, you should get the Classes.dex.dex2jar.jar file. Rename to Framework-classes.zip. Using the Zip Viewer, go to framework-classes.zip/com/android/internal/:

Congratulations, you already have all the. class files, including the internal and hidden APIs (although only the internal section is confirmed).

Create Original-android.jar

The Android SDK Android.jar is located in Android_sdk/platforms/android-x/android.jar (X for API level).

Copy Android.jar into Custom-android.jar. Unzip to the Custom-android folder. Copy all the. class files in the Framework-classes.zip to the Custom-android folder (you need to overwrite all existing. class files).

Then, compress the custom-android file into Original-android.zip. Rename to Original-android.jar.

Summary of steps

1. Select your target platform x

2. Create simulator for Target platform X

3. Launch Simulator, download/system/framework/framework.jar

4. Renaming Framework.jar-Framework.zip

5. Extracting Classes.dex from the Framework.zip

6. Use the Dex2jar tool to convert it to Classes.jar

7. Renaming Classes.jar-Framework-classes.zip

8. Copy android.jar–> Custom-android.zip

9. Unzip Custom-android.zip to custom-android folder

10. Copy all the files in the Framework-classes.zip to the Custom-android folder (overwriting existing files)

11. Compress custom-android folder into Original-android.zip

12. Renaming Original-android.zip- Original-android.jar

After the harvest.

Summarize

We restored the Android.jar to include all of the. class files for the internal and hidden APIs. This is only the first step. The next step is to create a custom Android platform that uses the Android.jar version and add it to the Android SDK platforms folder.

I have shown how to create a Original-android.jar that contains all the internal and hidden APIs.

The next thing to do is to modify an existing Android platform (SDK_DIR/PLATFORMS/PLATFORM-X/ANDROID.JAR,X indicates the API level). You can replace Android.jar directly with the Original-android.jar created in Part2. However, all of your projects will use the internal and hidden APIs directly without any restrictions. It's not convenient because you don't want that in most projects. Even, you might prefer to disallow these APIs (the default behavior of Adt/android.jar). But for some specific projects, you want to be able to use these internal and hidden APIs.

To achieve this flexibility, you need to create a new custom Android platform. When you don't need access to the internal and hidden APIs, you only need to use the original Android platform. When you use these APIs, you use a custom Android platform.

Android SDK folder structure

Let's look at how the Android SDK tree is organized:

We need the "Platforms" folder. Look inside:

The supported Android platforms are listed here.

Now, let's look at how it relates to eclipse settings. Select your project and right click on –> properties–> Android. You will see a set of supported Android platforms (similar to the/platforms/folder). Here are the following:

Create a new platform

In order to create a new platform, we need to copy the Android-9 folder---Android-9-internals. Let's make some corrections:

1. Delete the Android.jar

2. Copy the Original-android.jar and rename it to Android.jar

3. Modify the Build.prop file:

...

Ro.build.version.sdk=9-Ro.build.version.sdk=-9

...

ro.build.version.release=2.3-ro.build.version.release=2.3.extended

...

Restart Eclipse. and confirm that you can see the new platform. Here's what I see:

Why am I choosing an API level of-9? This is because it must be a number, and it cannot be 9 (or any other API level that already exists). Otherwise, your custom platform will not be used (it is visible in the list, but it does not work properly when it is selected, and the original platform of the corresponding API level is still used at compile time).

The following is a reference to a class library (the current project has a custom platform selected):

Summarize

In the previous article, I have already told you how to create an abridged version of Android.jar. In this article, I showed you how to create a custom Android platform and use Original-android.jar in it. This is sufficient for the hidden API. But for the internal API, another step is needed. This is because ADT still does not allow the use of classes in the Com.android.internal package (see "Forbidden" access rules in). In the next section I will show you how to customize ADT to allow the use of classes in the internal package.

============ Gorgeous split-line =============

During the actual operation, the custom Android.jar (API 10) I created cannot be successfully loaded by eclipse, and the following error box appears, like the results of other people's actions on the site, expecting the solution.

However, the author provides the available custom Android.jar, if you do not want to try, you can download directly from the site, the address will be given in the Part5, a little bit.

In order to be able to use the internal and hidden APIs, you need:

1. Create a custom Original-android.jar that contains all the. class files

2. Create a custom Android platform to use Original-android.jar

3. Modify the ADT plugin to allow the use of the Com.android.internal package (internal API only)

4. Create a new project that references a custom Android platform (examples in this article)

In this article, I'll show you how to use those internal and hidden APIs.

Also, at the end of this article, I have listed some custom Android platforms that contain the internal and hidden APIs. I came with them for the possibility that you don't want to spend too much time on this, but want to try something fast.

Example

Create a new project and select the 2.3.extender platform:

Here's the code:

This code uses the internal API (Powerprofile) and the Hidden API (iswifiapenabled). I can compile and run this code without using reflection.

Custom Platforms

Here are some of the platforms that I created for myself. Just copy them to the Sdk_dir\platforms folder. This just makes the hidden API available. For the internal API, you need to modify your ADT plugin.

API 3:http://www.megaupload.com/?d=s1f2mkyz

API 4:http://www.megaupload.com/?d=vuctri3y

API 7:HTTP://WWW.MEGAUPLOAD.COM/?D=7ITNILBK

API 8:http://www.megaupload.com/?d=ext5fkkt

API 9:http://www.megaupload.com/?d=ext5fkkt

API 10:http://www.megaupload.com/?d=fcv78a9m

============== Gorgeous split-line =============

I tried several of these custom platforms and found that the internal and hidden APIs are really available, but there are some unexpected issues, such as alertdialog.builder (context context) actually saying the context parameter is superfluous.

Did not take the time to study why this, if any child shoes know why, tell me AH ~ ~

Source: http://devmaze.wordpress.com/2011/01/18/using-com-android-internal-part-1-introduction/

How Android calls the @hide and internal APIs