Hope you guys can give me some much sought advice.
I've been attempting to build a JAR file that packages it's own JARs as internal class dependencies, but without exposing those inner JAR dependencies to the outside world. I'm guessing this needs to happen, otherwise the link process for building an Eclipse Android project would fail if not.
So my problem is such:
If I have an internal dependency on say dom4j-1.6.1.jar, I don't want to prevent someone from being able to add my JAR to an Eclipse Android project and including their own dom4j package dependency (possibly a different version). If the internal JAR dependency is exposed they will experience a duplicate resource conflict when attempting to build their project.
e.g. java.lang.IllegalArgumentException: already added: Lcom/google/gson/DefaultTypeAdapters$ByteTypeAdapter;
Here is what I tried to date:
So I have a regular Android project in Eclipse which adds in my packaged JAR as an dependency.
I refered to the Oracle docs, however there is a footnote about the inclusion of JAR files within JARs.
Note: The Class-Path header points to classes or JAR files on the local network, not JAR files within the JAR file or classes accessible over internet protocols. To load classes in JAR files within a JAR file into the class path, you must write custom code to load those classes. For example, if MyJar.jar contains another JAR file called MyUtils.jar, you cannot use the Class-Path header in MyJar.jar's manifest to load classes in MyUtils.jar into the class path.
So I decided to try the Fat Jar Eclipse Plug-In from SourceForge.
It's an Eclipse Plug-In for deploying a project into one "fat" executable jar file containing all referenced libraries. References are taken from the project settings, so no manual configuration is necessary.
I did manage to execute my build using this method, however did have to manually hack the packaged JAR file to remove the reference to the annotations package which was causing a conflict with my Android test project by being referenced twice.
So now I am left with a project that builds and executes, but exposes those inner JAR dependency packages to my Android project.
I would appreciate any advice you guys can provide. I hope my explanation is clear enough.
Related
I can add a jar file into the apk package, however if multiple apps are using the same jar, ideally it should placed under /system.
The jar file is not really activities (so using intents/providers is not applicable here) but may contain some commonly utils by my apps.
This is somewhat similar to OSGI, but more modest.
Any pointers ..
-Dan
I can take dex files and decompiling them to smali assembler and make changes there but it is much harder to read than java. I have been able to decompiling to sTraight java but then once I have made a change, I can't figure out how to compile just the single java back to a class without recreating the entire project in eclipse. Is there a way to just compile that single file I changed and insert it back in?
Sent from my Inspire '4g'.
How did you decompiled dex file?
You can't compile it back just like that, but you could use some workaround:
If you reference in Java some other classes from dex, then you will have to create Java stubs for these classes.
Compile your java class, linking to above stubs and android.jar file (javac).
dex resulting *.class files (dx tool).
baksmali resulting classes.dex.
baksmali original dex file.
replace smali files with new ones.
smali everything back to classes.dex form.
You could also read this: http://code.google.com/p/android-apktool/issues/detail?id=88
I want to share my Tool I made yesterday in a couple of hours. I was just sad about all the steps which have to be done until you have a proper codebase of an android app (apk) so I automated some processes.
You might think "this guy have only 1 post I can't trust him !!!" I would probably think the same but I'm here on xda actually pretty long but just read as anonymous user without an account and now I just wanted to give something back so I created an account.
My Tool includes following thirdparty software:
jad (decompile .class files)
dex2Jar (converts apk files into .class files)
apktool Decompile (is used for extracting resources and Smali code)
apktool build (is used to build the smali code into an apk again)
testsign.jar (is used to sign the build apk file)
Features:
Decompile assets
Decompile resources
Decompile smali files
Decompile java files
Build apk from smali source
Sign build apk
Nice gui with drag and drop
The application is written in java so it should probably work on all operating system (not sure because jad isnt written in java so I have to use os specific files)
Screenshot:
i.imgur.com/U85AU.png
Virustotal
virustotal.com/file/69601c98a25edf2fcb22b94fb58863848a4cd4a7ee0a39b4ad40de54c086f102/analysis/1358111315/
Download: ul.to/5hy2wf9x
Awesome tool! Tested it and works perfectly! Thank you!
OK, so I'm just gonna throw this one out there as a feeler..
When porting packages from other devices, I've found myself modifying Smali reference IDs for ages. The goal being to get the references in a foreign package to reference the correct resource in e.g. the BASE framework-res.apk.
Finally, I got really fed up, and automated the process. The result is this very alpha SmaliRefSwapper JAR. Instead of spending endless hours of cutting and pasting references until your eyes bleed, this code does most of the process for you in a matter of seconds.
Now I'm trying to figure out if this is something which would be of interest to developers. If not I probably won't put much more work into this. So let me know what you think - yey or nay!
Definitions
BASE framework = framework-res.apk in the ROM you are trying to port the foreign package to.
BASE package = the APK in the ROM you are trying to port the foreign package code to.
PORT framework = framework-res.apk in the ROM you are trying to port the foreign package from.
PORT package = the APK in the ROM you are trying to port the foreign package from.
Preparations
You can place the files wherever you want, but for simplicity, I have provided a folder structure and instructions relative to this.
1. Place the Smali files (package.apk/smali/*) from the PORT package into SmaliRefSwapper/smali
2. Place the XML files (package.apk/res/values/*) from the BASE package into SmaliRefSwapper/xml/base/package_values
3. Place the XML files (framework-res.apk/res/values/*) from the BASE framework into SmaliRefSwapper/xml/base/framework-res_values
4. Place the XML files (package.apk/res/values/*) from the PORT package into SmaliRefSwapper/xml/port/package_values
5. Place the XML files (framework-res.apk/res/values/*) from the PORT framework into SmaliRefSwapper/xml/port/framework-res_values
If there is no XML in the BASE or PORT package, place a dummy public.xml file in these folders.
Usage Instructions
Run the JAR (through terminal to obtain some logs) and select the appropriate folders.
The output will be two folders:
SmaliRefSwapper/smali_new
SmaliRefSwapper/xml_new
smali_new content goes into the PORT package before recompilation. In it, all Smali references have been replaced with the correct reference from the BASE framework/package.
xml_new contains two folders:
SmaliRefSwapper/xml_new/framework-res
SmaliRefSwapper/xml_new/package
framework-res files contain references which should be added to the respective XMLs in the BASE framework before recompilation (e.g. public.xml content should be added to framework-res.apk/res/values/public.xml). In certain cases, for example when drawable references have been added, it is necessary to manually fix the dependencies they may infer (e.g. adding a PNG file from the PORT framework-res/package).
xml_new may also contain a UNHANDLED.xml, which lists references that could not be found in either PORT framework-res or package. In most cases these are hardcoded hexadecimal values, such as colors or numbers.
After recompiling the BASE framework with the new XML, and the PORT package with the new Smali and XML, it should be safe to include the PORT package in the BASE ROM.
Download
SmaliRefSwapper Alpha
Please do not mirror my work!
Reserved in case.
I am doing some modifications to okhttp library in AOSP. The library exists in this location in in AOSP: /external/okhttp
I know that the library will become a jar file okhttp.jar after I compile the AOSP. but compiling the whole AOSP take a long time. So I am wondering if there is an easy way to compile the okhttp library alone and get the jar file.