Starting and stopping android emulators

December 12, 2011 7 comments

Android SDK provides ability to run code in emulated environment called emulator. Its quite easy to start using it. But when it’s time to setup your favorite Continuous Integration system, a lot of issues with emulators start popping up.

The most critical ones is how to start the emulator and detect when its ready to be used to run some code. And how to kill/stop emulators reliably.

In this post I’d like to share some ideas I’ve come across and that seems to work stable enough.

Read more…

Categories: Android Tags: , , ,

Using internal (com.android.internal) and hidden (@hide) APIs [Part 5, summary and example]

January 19, 2011 72 comments

(Parts 1, 2, 3, 4, 5)

In order to enable usage of Internal and Hidden APIs without reflection you need:

  1. Create custom original-android.jar that includes all required .class files (details here)
  2. Create custom android platform that uses original-android.jar (details here).
  3. Modify ADT to allow usage of com.android.internal package (only for Internal API, details here).
  4. Create project that references custom android platform (example in this post)

In this post I’ll show how to actually use those Internal and Hidden APIs.

And as a bonus there is a list of already prepared custom android platforms with Internal and Hidden APIs enabled at the end of the post. I added them just in case you don’t have too much free time but want to try something out quickly.

Read more…

Categories: Android, hacks

Using internal (com.android.internal) and hidden (@hide) APIs [Part 4, customizing ADT]

January 18, 2011 72 comments

(Parts 1, 2, 3, 4, 5)

In previous posts I described how to create custom original-android.jar and how to create new custom Android platform that uses this original-android.jar. This was just enough to use Hidden API. But one more barrier left for Internal API: ADT for Eclipse. It has a rule that forbids usage of classes from com.android.internal.

There are several ways to overcome this access rule.

1) Full ADT source code is available for download. And its possible to remove/modify correct line of original code, build it and install new custom version of ADT. Bad thing about it is that you need to setup 64-bit Linux machine, download source code, build it. It takes some time. And when new version of ADT arrives, you’ll need to start all over again.

2) The other way is to just modify ADT’s bytecode. Just replace “com/android/internal/**“ string with another string like “com/android/internax”.

Second step may be automated using scripts. And does not require access to source code and works on Windows too. That’s why I’ll describe second approach in this post.

Read more…

Categories: Android, hacks

Using internal (com.android.internal) and hidden (@hide) APIs [Part 3, custom android platform]

January 18, 2011 38 comments

(Parts 1, 2, 3, 4, 5)

[note: if you don’t have time to follow this post, you can go here and download the final results]

In previous posts I’ve shown how to create custom original-android.jar that contained all classes from internal and hidden APIs.

The next obvious step is to modify already existing Android platform (SDK_DIR/platforms/platform-x/android.jar, where X is API Level of your selection). You can just replace android.jar with original-android.jar that you created in Part 2. But then all your projects will be able to use Internal and Hidden APIs without any limitations. This is not convenient. Because in most projects you don’t want to allow this. Even more, you basically want to forbid usage of these APIs (and this is default behavior of ADT/android.jar). But for a selected few projects you will want to enable usage of Internal and Hidden APIs.

In order to achieve this flexibility you’ll need to create a new customized Android platform. When access to Internal and Hidden APIs is not required, you’ll use original Android platform. But when you need those APIs, you’ll use customized Android platform.

Read more…

Categories: Android, hacks

Using internal (com.android.internal) and hidden (@hide) APIs [Part 2, customizing android.jar]

January 18, 2011 48 comments

(Parts 1, 2, 3, 4, 5)

[note: if you don’t have time to follow this post, you can go here and download the final results]

In previous post I explained why there is no easy way to use com.android.internal package (internal API) or anything marked with @hide attribute (hidden API) without using reflection. That’s because android.jar file does not contain classes from internal and hidden API and because of this nobody can reference those classes in compile time.

This part describes how to restore original android.jar. This will allow usage of internal and hidden APIs as if they were public APIs.

Read more…

Categories: Android, hacks

Using internal (com.android.internal) and hidden (@hide) APIs [Part 1, Introduction]

January 18, 2011 20 comments

(Parts 1, 2, 3, 4, 5)

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

The first one is located in package com.android.internal. I will refer to this API as to internal API. The second API type is collection of classes and functions that are marked with @hide javadoc attribute. Even though this strictly is not a single API but a collection of small hidden APIs, I still going to assume this is one API and will refer to it as to hidden API.

Read more…

Categories: Android, hacks
Follow

Get every new post delivered to your Inbox.

Join 36 other followers