Trying to develop android LPA system app for eSIM with the new Pie API.
The doc says to extend the abstract EuiccService class. But this class is not in the official SDK, and the link in the docs just leads to corresponding file in the android source repo.
I tried using this file/class as a dependency, but it references other internal android classes/annotations and causes build/IDE errors.
Does anyone have an idea how to use this?
Do I really have to pull android src code and somehow reference required class from it?
EDIT: I think I've solved it, found couple of potential solutions, but they were a bit cumbersome. Used the android.jar from here: https://github.com/anggrayudi/android-hidden-api (contains modified android.jar with hidden APIs and internal resources). It didn't work when i replaced the whole file and resulted strange build errors, but i manually transferred the android\service\euicc\ folder to original android.jar of android-28 sdk and it works perfectly (class is available and apk builds without issues). And no need to waste time pulling and building AOSP.
EDIT #2: apparently not fully fixable atm. There's issue with android gradle plugins (at least 3.2.x-3.3.x) where during full sync some build task generates mock classes from android.jar and process fails if it's modified (discussion is here: https://github.com/anggrayudi/android-hidden-api/issues/46). Error looks like this:
Failed to transform file 'android.jar' to match attributes {artifactType=android-mockable-jar, returnDefaultValues=false} using transform MockableJarTransform
There's a workaround for that, though inconvenient:
when you need a full sync for the project, replace the android.jar with original, run sync, restore modified android.jar, the IDE now will run indexing and classes will be available again with build working until next full sync.
Will update this post if/when it's fixed or new solution is found.
EDIT#3: here's probably a final solution for EuiccService case (turned out pretty obvious):
Instead of adding 'android/service/euicc' folder to android.jar, just put it in a separate library and add it as a compileOnly dependency. Since the classes were not in the SDK, the lib should not cause conflict (would be the case if you need to use modified framework or access hidden APIs in already existing classes).
If you are going to create a System APP, you will do it in several ways:
You could call a part of the SystemAPI (a method for example) by reference.
You could make the aplication as a part of the AOSP Project (Downloading the AOSP code, and introducing your app as part of packages/apps/)
You will be able to access system APIs on a rooted device or if you have system permissions (this happens when you flash your app into the device as part of the system image).
However, if you want to be able to call the EuiccService class from Android Studio (for coding purposes), you'll need to add the Android framework jar to your project.
The steps are provided below:
First, you will have to download and build AOSP and generate a framework jar for your target Android version. Check the documentation here to get an idea of how to download and build AOSP.
After a successful build all framework classes are compiled into a jar called classes.jar which can be found at the location out/target/common/obj/JAVA_LIBRARIES/framework_intermediates.
Get this classes.jar and add it to your Android project as a jar file.
Gradle sync the project and start coding.
Please beware that you WILL NOT BE ABLE TO run this app on an Adnroid device where you do not have system permission for this app.
Many times after building an app and uploading it to play store I realize that I haven't guarded the apk using proguard feature provided by android and anyone can decompile the app using various tools to get my app's source code. So is it possible that whenever i create a new project the proguard feature is automatically enabled and my app's source code can be secure?
For obfuscation just add to project.properties file in android project the following line:
proguard.config=proguard.cfg
see details in android's development page here
Probably you will have to right a custom ant build script which throws an error when proguard property is not set in properties.To write custom ant build script visit this link:
http://www.androidengineer.com/2010/06/using-ant-to-automate-building-android.html
I am working on an android project working in Android Studio (0.5.3).
I have created two endpoint api classes (called UserEndpoint and OfferEndpoint) in the backend part of the project. Then I wanted to create the client libraries to use in the app part of the project. I use the gradlew appengineEndpointsInstallClientLibs command for this. In the /build/client-libs part it did create the .zip files of the client libraries. But it did not install them in the app part of the project.
So now my question:
Is the command I am using (gradlew appengineEndpointsInstallClientLibs) supposed to also install them in the app part, and if yes what could be the reason it is not working for me (there seem to be no errors).
This tutorial mentions that I have to manually add the libraries. I added the .zip files to the /libs folder, but there is no 'add as library' option as the tutorial mentions. Is this the correct way of doing this? And if yes could someone give me a little more in detail explanation because I tried some things by adding the dependency in the build.gradle file but nothing seems to work.
Thanks in advance!
By default, if you don't use #ApiNamespace, the namespace that is used
is the reverse of your-project-id.appspot.com. That is, the package
path will be com.appspot.your-project-id.yourApi.
Source
The annotation was missing in the #Api annotations of the endpoints.
I have been working on one project which is too complex and contain very much space with so many images and Java files as well.
Somewhere I have read about the proguard which optimizes the code.
I have used it, but it's still does not have an effect on my final APK file.
It might be I have made a mistake somewhere. I have the following this like http://developer.android.com/guide/developing/tools/proguard.html.
How can I optimize my code?
You can add it to the default.properties. I've been adding manually without having a problem so far.
If you add the line:
proguard.config=proguard.cfg
As said it will only use ProGuard when exporting signed application (Android Tools => Export Signed Application)
If you start the project with the SDK before Android 2.3 the proguard.cfg file will not be created (next to default.properties as in 2.3>).
To enable automatic creation of it, just simply update to the SDK of Android 2.3 and create a new project with existing sources (which are the sources of the project you currently have).
Automagically the proguard.cfg fill will be created.
Without optimizations the compiler produces very dumb code - each command is compiled in a very straightforward manner, so that it does the intended thing.
The Debug builds have optimizations disabled by default, because without the optimizations the produced executable matches the source code in a straightforward manner.
Please refer this one
From documentation:
ProGuard is integrated into the Android build system, so you do not have to invoke it manually. ProGuard runs only when you build your application in release mode, so you do not have to deal with obfuscated code when you build your application in debug mode.
I want to rebuild the Android SDK (or rather only the android.jar) to include hidden and internal APIs.
I could not find any documentation or discussion doing on how to go about this. I have an Ubuntu CyanogenMod build environment already setup that is able to build cm7.
Now, I read that make SDK will build the SDK but I want to build an SDK that includes methods and fields that are marked as hidden using #hide. Is this possible?
What I want to do is make changes to an application that uses hidden API and in order to rebuild it I would like to use the modified SDK.
This is what I always do to use hidden api.
Build the repo or download jars from https://sites.google.com/site/hippunosource/home/android/androidnohide-apiwo-shi-yongsuru-rifurekushonha-wei-shi-yong
copy out out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/classes.jar (better to rename it as something like framework_all.jar)
config your project build path-->libraries --> add this external jars. In Order and Export, move it up and before android.jar
I have done some investigating into this, and my conclusion is simply: This cannot be done without quite a bit of work. Read the rest of this answer for details on what I have found.
android.jar is actually comprised of the "public api" of framework.jar and core.jar which is found in system/frameworks/ on the device. android.jar is a kind of what I would call Java library header, all implementation in the actual byte code are just a throw new RuntimeException("stub");, this allows you to build against android.jar (e.g. in Eclipse), but execution has to be performed on a device or emulator.
The public API of the Android SDK is defined by classes/methods/fields that are not prefixed with the #{hide} javadoc annotation. I.e. everything that is not annotated is included in the SDK.
android.jar is built from the sources located in out/target/common/obj/JAVA_LIBRARIES/android_stubs_current_intermediates which itself is generated by the tool DroidDoc located in build/tools/droiddoc.
DroidDoc is the tool (probably adapted from javadoc, or using javadoc) that generate the actual Android SDK documentation. As a side-effect, and probably because it is already parsing all the javadoc, it also spews out the android stubs which are then compiled into the android.jar which is distributed in the SDK.
So to include the stuff that is hidden you could, if you only want to include specific parts, just remove the #hide annotation and rebuild the SDK.
However if you want to include all the hidden parts things get a lot more complicated. You can modify DroidDoc (the relevant source is in build/tools/droiddoc/src/Stubs.java) such that nothing is detected as hidden. This is quite trivial and I have tried this, however the stubs that is then generated does not compile at all.
My conclusion by now is that this is simply not feasible. The stubs generated if you remove the part of DroidDoc that detect hidden annotations, is simply not compilable, and would require quite a bit of work to compile correctly.
So my answer to your questions is: No, this cannot be done, without doing a lot of work. Sorry.
A side note about the mkstubs tool. mkstubs are used when you build a SDK addon, i.e. the addons you can find in the Android SDK manager from vendors, e.g. Samsung providing you with an additional API for stuff specific to Samsung phones. mkstubs does much the same as the DroidDoc stubs generation process, however it does not use #hide annotations, it uses a .defs file describing which packages/classes/fields to include or exclude from your SDK addon.
However this is all irrelevant to the question, as the Android SDK build does not use the mkstubs tool. (Unfortunately.)
We could reconstruct the *.jar files from the Android platform.
First, connect ADB to your device. Then run:
adb pull /system/framework/core.jar .
adb pull /system/framework/framework.jar .
The core.jar contain the standard Java libraries (java.*) and the framework.jar contain the Android libraries (android.*). This is not usable yet, as the actual files are in DEX format, not JAR format.
We could convert these DEX-formatted *.jars into real JARs using tools such as dex2jar:
dex2jar core.jar
dex2jar framework.jar
Then pull in these jars using "Add External JARs..." (assuming you're using Eclipse ADT)
right click on Project → Properties → Java Build Path → Libraries → Add External JARs... → (Choose the core-dex2jar.jar and framework-dex2jar.jar from above).
This will enable you to use the internal and some Java 7 APIs. (The generated APK, as far as I can see, does not contain any actual code from the JARs.)
You can download the modified android.jar to be used as hidden APIs from this repository. Follow the instructions there.
For Lollipop the flow is little different:
Get /system/framework/arm/boot.oat from lollipop device
Use 'java -jar oat2dex.jar boot boot.oat'
You will get two folders: dex and odex. Go to dex and make 'java -jar dex2jar.jar framework.dex'
Rename resulting framework.jar to .zip, extract and find classes you need
Go to [sdk_path]/platforms/[target_platform] and extract android.jar (first rename it to zip).
Copy files from extracted framework to extracted android.jar. Then compress to zip and rename to .jar :)
ps: probably you need repeat steps 4-6 for 'framework_classes2.dex'
DroidCon 2011
Here Erik Hellman from Sony Ericson explains how to access the hidden Android API's:
http://vimeo.com/30180393
(Hmm link doesn't appear to work).
Goto the DroidCon webpage Day 2 scroll down to Using Hidden APIs 10:15 and you can watch it there.
Links are dieing!
I've found this one: http://skillsmatter.com/podcast/os-mobile-server/hidden-api I don't know, how long it'll be up.
The official APIs in the Android SDK is usually sufficient for most normal applications. However, there are sometimes situations where a developer needs access to the internal system services, APIs and resources that are not published in the official APIs. Fortunately, these APIs are still available through some clever tricks and can often be useful when developing new and innovative solution on top of Android. In this session you will learn how to access and use these hidden and protected APIs, the limitations of their usage and some tips'n'trick on how to use them in a safe and control manner across multiple vendors devices and Android versions. The audience will see several advanced demos that you normally cannot do with Android. Expect a fairly advanced session with lots of insights in the internals of the Android platform.
Try to look at this:
The ultimate target of these articles is to give developers the power of Internal and Hidden APIs without using reflection. If you complete all the steps described in next several parts you will be able to use Internal and Hidden APIs as if they were public open APIs. There will be no need for reflection.
But if you’re using these non-public APIs then you should be aware that your application is at great risk. Basically there are no guarantees that APIs will not be broken with next update to Android OS. There are even no guarantees about consistent behavior across devices from different vendors. You are completely on your own.
There are three scenarios you may want to follow:
Enable both internal and hidden APIs (scenario A)
Enable only hidden API (scenario B)
Enable only internal API (scenario C)
Scenario A is a sum of B and C. Scenario B is the easiest one (requires no eclipse ADT plugin modifications).
Scenario A: read parts 1, 2, 3, 4, 5
Scenario B: read parts 1, 2, 3, 5
Scenario C: read parts 1, 2, 3, 4, 5
I once wrote some Groovy scripts for extracting the java files from a repo checkout from http://source.android.com/ and then compiling them without the need for a full toolchain for compiling all the android sources, including the needed other steps (packaging, generating resources etc).
They can be found here:
https://github.com/thoutbeckers/CollectAndroid
But for sure this will need updating for anything after Gingerbread, mostly by setting the correct directories in "rootdirs" in the config file (CollectConfig.groovy).
At the time I regularly used this for development with all of the hidden API and sources (also problematic at the time) available.
As mentioned elsewhere com/android/internal/** will still be hidden in recent versions of ADT due to the access rule aded.
Long's answer worked for me, but I was still missing some classes I needed, in particular android.provider.Telephony. I was able to add it like this:
Extract the framework.jar file
mkdir /tmp/framework
cp framework.jar /tmp
cd /tmp/framework
jar xvf ../framework.jar
mv android classes
Build the Android repo, which will create the out/target/common/obj/JAVA_LIBRARIES directory
Find where the missing classes are
$ cd /path/to/out/target/common/obj/JAVA_LIBRARIES
$ find . | grep "/Telephony.class"
./telephony-common_intermediates/classes/android/provider/Telephony.class
./android_stubs_current_intermediates/classes/android/provider/Telephony.class
Add the new classes and rebuild the framework JAR file
cd /tmp/framework
cp -r /path/to/out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/classes .
cp -r /path/to/out/target/common/obj/JAVA_LIBRARIES/telephony-common_intermediates/classes .
cd classes
jar cvf ../framework.jar .
Or you can just be lazy and include all of the classes into one giant jar file:
cd /tmp/framework
cp -r /path/to/out/target/common/obj/JAVA_LIBRARIES/*/classes .
cd classes
jar cvf ../framework.jar .
I can't comment but this is basically a comment to #KennyTM's (https://stackoverflow.com/a/13550030/2923406) excellent answer:
If you find yourself with the following error in Eclipse:
The type com.android.internal.util.Predicate cannot be resolved. It is indirectly referenced from required .class files
(that is, android.internal.* is not available)
Then one possible solution is to apply the same method for /system/framework/framework2.jar. Using the Android Emulator for SDK19 I have this extra jar. On my HTC One there is even a framework3.jar.