Using AOSP we can build own Android with some features.
I have setup environment using google documentation and another web sites, and in tutorials says -
make adb fastboot. Update yours android OS with yours customization.
But i just need use #SystemApi classes for build one app, what i should to do?
I searched in web for one month, but still didn't find.
Methods marked as #hide or #SystemAPI are not part of the official SDK, and are not intended to be used generally.
Yet, until lately you could access all of them either by Reflection, or by using a custom android.jar that has those methods too. See this project for the list of android.jar: https://github.com/anggrayudi/android-hidden-api
If your Android version is below P, that's all you need to do. Otherwise keep reading:
In Android P, Google removed access to non-SDK interfaces, so you cannot use those methods as above. In this case you'd have to remove the #SystemApi and #hide annotations from the classes and methods you need, compile and flash the update to the device. Then you can use the above methods
Related
In pure Java, using intrumentation and java agents, there is a way to replace the body of a method at runtime.
Unfrotunately java.lang.instrument.Instrumentation is not available under Android.
I have checked all other alternatives, like the one described here in stackoverflow, which directs to the obsolete javassist-android implementation. Which surprisingly works, but only for new classes.
There's also an article named Hot swapping code in Android which describes how again to load classes at runtime, not how to replace existing methods of classes.
The only article dealing with this issue is an article named Android hacking: replacing system classes methods with your own, which misses the source code and refers to Dalvik, not ART (so it won't work on modern hardware).
So, is there any way to do so?
...
Bottom line: the reason I want this is to trace specific method calls in my application, like just when this method is called (and do some action before it) and just when this method exits (and also do some action on it). These methods are defined at runtime, so there's no way to know them in advance, at compile time.
One of the new features in Android Studio 3.5 is Apply Changes, which basically performs similar logic to what you're looking to achieve:
".. we rely on runtime instrumentation that is supported in Android
8.0 (Oreo) and newer devices and emulators to redefine classes on the fly."
Also, in episode 108 of ADB Podcast Esteban de la Canal mentioned:
".. In Android Oreo (8.0), the platform implemented bytecode
instrumentation on the fly, so we can actually change the dexed class
of a running app.. by attaching, basically, an equivalent of
JVMTI in Java, so we can attach an agent and say: can you swap
this class with this one. "
Start with reading the art/openjdkjvmti sources, i.e. the readme documents the following:
openjdkjvmti plugin
This is a partial implementation of the JVMTI v1.2
interface for the android runtime as a plugin. This allows the use of
agents that can modify the running state of the program by modifying
dex files in memory and performing other operations on the global
runtime state.
Once Android Studio 3.5's sources will be released, see how they used those new APIs in Apply Changes implementation.
Although the j.l.instrument APIs were never added to android the underlying JVMTI apis that were used to implement them were added in Android O. For example here is a test JVMTI agent that will redefine listed classes and add a single nop to the beginning of every method: https://android.googlesource.com/platform/art/+/refs/heads/master/tools/jvmti-agents/simple-force-redefine/
I am creating an app showing local events for android. I was hoping to use the Eventful API, since that came with its own java-based client library. However, I'm not sure if it's fit for Android, since I know a lot of these java based client libraries use stuff Android doesn't support.
So, does anybody know if it works?
My entire project is available # github if you want to check it out for yourself.
The API is found here.
Android does not have have issues with Java client libraries. It is build on top of standard Java, and can use all of the framework features.
Furthermore, it looks like this API offers a RESTful interface, which is for sure supported by Android.
Bottom line, I do think you can use this API in Android without issue.
I'd say the easiest way is to compile and run an application that embeds the library and tests a few methods.
Typically, you may have issues with the way the networking is handled. There are 2 main ways in android to do HTTP, the Java and the Apache way, I think the Java URL API is fully supported and very close to the actual Java version, but the Apache has some hidden differences.
The main risks you'll have are A/ that it uses classes or packages that are not present on Android. B/ that a class does not behave as expected, which does happen from time to time, as the Android implementation is entirely specific.
Apparently you have already tried to run an android app with the library included? Did you encounter a specific error? If you, can you post the stacktrace?
I am writing my own SDK on android and as such creating my own jar.
Now I create documentation of my SDK using droiddoc tool.
In my framework files(.java), there are many APIs that I have marked with #hide
Now this is the current state:
a) all APIs marked with #hide are hidden in documentation.
b) These APIs marked hidden is INCLUDED in class files in generated jar file.(I use Java decompiler to check this).
Now when I include this jar in eclipse and use Ctrl+space on my class object to find its options, i can see that hidden APIs are actually visible and accessible here.
Am I missing anything here, and do I need to add any special flags in make file? Or is this a normal behaviour?
I found out that:
android.jar has all classes from com.android.internal removed, and all
classes, enums, fields and methods marked with #hide removed as well
So the classes with #hide are not included on jar -> that's why they are not accessible in eclipse.
Furthermore:
When you launch your application on device it loads framework.jar
(roughly this is equivalent of android.jar on the device) which is
uncut and has all the internal API classes and all hidden API
components.
Have a look over this post and this answer
Hope you find an alternative solution for hiding things
Now I am doing an android project(Api level 8),I install JD-Eclipse(decompiler) to know the flow of program execution.The decompiled 'android.jar' contains full of abstract classes and interfaces, then where is the actual class containing the body to be executed? What is the name of that jar file?
You probably won't find what you are looking for. The android.jar is an API and as that not directly executable, there isn't even any guarantee that it contains such code.
If you want to start creating an application, just go to the developer page and start reading through the documentation on how to set up the development environment, how to program against the API, how to test your application and, finally, how to deploy it on an actual device.
The lifecycle of an activity for example can be found in the documentation.
Android.jar contains the Android API (Classes, interfaces, ..). If you want to see the rest, download the source from Android Git repository or via SDK Manager.
It's weird I found PackageManager has public APIs like installPackage(...)/deletePackage(...) although in the comment it's marked as Hide, here http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/2.2_r1.1/android/content/pm/PackageManager.java#PackageManager.deletePackage%28java.lang.String%2Candroid.content.pm.IPackageDeleteObserver%2Cint%29, but the reference page google provides hide this API.
So my question is how can I access such APIs?
Thank you all very much for help.
Kindest regards,
Nessus.
It was declared as public just to simplify the SDK developers life. But it never was expected to be called by outside developers. See also this post.
But if you really need to call this method, you can use reflection. Thought I suggest to look around for an alternative solution using official API.
In general you should not use "hidden" APIs in your applications. These methods are for internal usage and can be changed or even removed without notice. They are often not available for non-system applications due to permission restriction. If you want to use these APIs in your application then you may build your app within the platform build.
There is also a workaround to build application that uses hidden API in Eclipse: you can collect compiled framework libraries from the platform build and add them to build path as "User library", framework_intermediates/classes-full-debug.jar should be enough for the package manager.