Android – hidden and internal API’s revisited


A few years ago I wrote a short article on how you can access, and use, Android internal API’s in Eclipse. This is still a popular article which still generate hits every day.

Android – hidden and internal API’s

Sadly it is perhaps a bit dated – especially since Eclipse is no more and Android Studio is the new toolbox, so I decided to see if I could do the same with Android Studio and Android 5.1 aka Lollipop…

I must admit that I initially tried to fix an important “feature” which after many hours turned out to be void, but such is life I guess… What I was trying to find was the previously hard-coded string “com/android/internal/**” which used to stop the ADT plugin from allowing us to compile with android internals. It turned out that this limitation has not (yet?) been implemented in Android Studio. I now have ~4GB source code for Android Studio sitting on my build server to no current use… 😉

Anyhow, here is how you enable Android Internals in Android Studio, and a small example application as a proof of concept!

First you must create a android.jar which contains the necessary classes:

Connect the phone to the computer and run the following commands.

adb pull /system/framework/framework.jar
unzip framework.jar
d2j-dex2jar.bat classes2.dex


dex2jar can be downloaded from SourceForge.

Select and open android.jar (…/sdk/platforms/android-22/android.jar in this example, and make sure you pick the same version as you’ve pulled from your phone!) in the SDK and add all classes/files that you’ve extracted from classes2.dex

Jar-files are actually zip-files so you can open them in your favourite zip-handling tool, or you can simply unpack them, copy the files and then pack a new android.jar, whatever method you prefer.

Start Android Studio and create a new project without an activity.
Edit build.gradle (Module:app) and change targetSdkVersion to the same as compileSdkVersion in order to make sure the correct android.jar is used when compiling.
I also had to comment out the dependencies in order for gradle to build correctly. I’m using targetSdkVersion 22 in my example below but you must use whatever sdk version you have on your phone.

dependencies {
 compile fileTree(include: ['*.jar'], dir: 'libs')
 //testCompile 'junit:junit:4.12'
 //compile ''
 //compile ''


Create an activity (

package com.politisktinkorrektpappa.hack.hackinternals;

import android.os.Bundle;


 * Created by PolitisktInkorrektPappa on 2016-04-21.
 * HackInternals

public class MainActivity extends Activity {

 protected void onCreate(Bundle savedInstanceState) {

LockPatternView lpv = (LockPatternView) findViewById(;

Create the layout (unlock.xml)

<?xml version="1.0" encoding="utf-8"?>
 android:orientation="horizontal" >




I was unable to get visual rendering working in Android Studio for the layout of the LockPatternView but I’ve only just started using Android Studio so perhaps this is something that can be fixed?

You will now be able to build and deploy your application to your phone and verify that it works.


Total time: 3.075 secs


Sometimes it’s nice to have access to Android Internals when creating an app, but remember – it’s not something you can deploy on Google Play because you’d be in breach of EULA and the fine-print you have to sign when setting up a developer account, but for home tinkering etc it’s perfectly fine!

Happy hacking!

Author: politisktinkorrektpappa

Share This Post On


  1. I followed the steps here, but I’m getting an error “Execution failed for task ‘:app:mockableAndroidJar’. > java.lan.NullPointerException (no error message)”. Any ideas why this might be happening?

    Post a Reply
    • That is impossible to answer I’m afraid based on the information you have provided.
      My example activity was specifically for that Android release. It might have changed in your version?
      Hacking internals require that you know the functions/classes you are using – especially since they’re not part of any javadoc.

      Try debugging and see where (who) NullPointerException is casted and you might find why…

      Post a Reply
      • Thanks for replying. I actually took another approach and just used reflection to access the APIs I needed, since the code is for a very specific set of devices that will always run the same version of Android.

        Your article guided me in the right direction and I appreciate that you took the time to create it.

        Post a Reply
  2. Hi
    Could you please provide your example or at least API-22 jar file
    I really do not want to drive in creating of custom jars)

    Post a Reply
    • It’s really quite simple and you might run into problems if you take my jar because we might run different versions/flavours of Android.
      I’m running Cyanogen which will have various functions that are different to a vanilla Android, let alone an operator custom one…
      It’s pretty much only extract, open (as zip), copy (to new jar) and done.

      Post a Reply
      • Hi
        I’ve decided not to use hidden APIs.
        The one I need, needs permission with level SIGNATURE, so to use that I’ll need users to have rooted phones.
        I’m looking to avoid this, looks like I’ve found solution, but it is so poorly documented…
        Thanks for willing to help! 🙂

        Post a Reply
  3. You mention at the end of this post, and in the referenced previous post from 2012 that publishing an application that utilizes hidden parts of the API that have been exposed this way is in breach of some EULA. Do you have any references for that?

    I can’t find any text in the EULA either for the SDK or the Google Play developer area that specifically prohibits usage of hidden parts of the android API. Since all these parts would also be available through reflection, would it matter which way you access the classes?

    Post a Reply
    • Back in 2012 things were different and although Android was open source-ish, there were a lot of areas that weren’t, and deploying apps on Android Market (now Google Play) that contained hidden API’s was a no-no from an EULA point of view.
      Now it’s 2017 and things are different. Gone are the hardcoded obstacles that were put in place to prevent us from even compiling code that included hidden/internal API’s and gone are also the red tape, i.e. EULA’s, to prevent us from doing this.
      This means, as far as I know (from being a former large Android vendor) that you can include, and link, to hidden API’s as much as you want. You’re still going to have to bake your own android.jar to include hidden/internal API’s but the compiler/IDE no longer tries to stop you from doing this.

      You can obviously still break things by doing this in case there’s a change in a hidden/internal API and you’ve linked to an older one, but these API’s are very seldom changed, so you should be safe – but it’s important to mention. Google Play will (probably) not reject your app if it includes hidden/internal API calls today, unless you’re doing something dodgy 😉
      This is based on the fact that you could build, and include, those parts yourself when deploying your app. It’ll be a very big app, but still…

      Post a Reply


  1. Android – hidden and internal API’s | Politiskt Inkorrekt Pappa - […] Android – hidden and internal API’s revisited […]

Submit a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: