I have a JAR library which includes some non source code files in a couple different /src packages (JSON files in this case)
When I add that JAR as a dependency on one of my Android projects and build the apk file, those JSON files are not in the apk or the classes.dex (I ran dex2jar and saw that the files are missing)
How can I tell dex to also include those json files in the output?
AFAIK, a dex file is only designed to hold .class files (and strings). Here is an (old) description of the dex file format. (I was unable to find one on google's site) http://retrodev.com/android/dexformat.html
When google parses your dependency jars at compile time it only pays attention to .class files, since that is what dependencies are for - classes you want to use in your code which aren't defined in your code. I'm not sure it even pays attention to anything else you might have in those jars.
The question you want to ask is not how to tell dex to include the json files (it can't) but how to get those json files into your apk. Unfortunately, if they are stored in a jar I don't know of a way to do this short of setting up something in ant to manually unpack the jar and move the files yourself. Compile-time jar dependencies are not designed to simply copy files into your project package.
Related
I'm trying to use ini4j in an Android app, compiled in the AIDE IDE. When I put ini4j-0.5.4.jar in the libs folder in my app, it works. However, when I include ini4j with the line compile 'org.ini4j:ini4j:0.5.4' in my build.gradle, I get the error bad utf-8 byte a0 at offset 00000004. I've checked the jar file in the Maven directory, and it is identical to the one in my libs folder. Both have the SHA1 4a3ee4146a90c619b20977d65951825f5675b560. I have absolutely no clue what could be causing this.
EDIT: For some reason, it seems to have xerces as a dependency, which is the library known to have these issues.
According to Apache (http://xerces.apache.org/xerces2-j/install.html) xerces.jar is now deprecated and renamed to xercesImpl.jar, so you have to stick to the old JAR.
xerces.jar is no longer available in the main distribution. You can still download this jar from deprecated distribution. xerces.jar is a Jar file that contains all the parser class files (i.e., it contains the intersection of the contents of xercesImpl.jar and xml-apis.jar).
To be clearer, the technical details are:
The old xerces.jar you have in your libs folder is working, because of the internal folder structure.
The new xerces from the repository has a different folder structure and some weird UTF encoded bytes AIDE is not understanding.
if I have a project with many library projects linked, could I improve build performances by packaging each of them in an AAR and including it in the main project ? Or this will not make any difference since that when the compiler need to assemble the apk it need to package everything together anyway?
Thanks to any one who will give me some clarifcation about performance differences between the 2 approach
I don't think you will save any build time by wrapping an existing .jar file into a .aar file and using that instead of the original .jar file.
As this SO post notes, .aar files are basically just zip files which may contain a jar file and some android resources.
Also, because .aar files are not precompiled into Dalvik byte code, the build process for your apk file must still carry out that step at least once. So, you won't save dexing time just by wrapping the .jar file into a .aar file either.
If you build a typical Android Studio project (with some Android library dependencies specified in the gradle build file) you can see the directory underneath app/build/intermediates/exploded-aar where these files have been unzipped. That work must still be done by your build machine even though you are using a .aar file.
Finally, as you pointed out, the .apk packaging work must still be done at the end of the build.
I believe the Library projects (which you are using) is the best way to go because of two reasons:
The library project gives the direct access to the code base of the libraries which can be compiled and packaged together with the main app code
In case, multiple .aar files are referenced within the project, then during the apk creation the unpacking, merging of resources and Manifest file will increase the build time.
I have read lots of questions on this site and come to the decision that if you wish to use your already developed code with its resources in android then you have to use it as a library.
But from the Building Android applications with Gradle tutorial I read something like...
Gradle supports a format called Android ARchive (AAR) . An AAR is similar to a JAR file, but it can contain resources as well as compiled bytecode. This allows that an AAR file is included similar to a JAR file**.
Does it means that we can use .aar file as an .jar file but with facility of using resources also?
Then I have tried to crate .aar file with the help of Android Studio, but .aar file doesn't contain layout XMLs or images -- it contains some layout and resources but it doesn't contain projects other resources file.
At last I am having the only same, annoying, stupid question: Can we use whole project with its resources with only one file like .jar or .aar or any other file format?
RajaReddy is quite mistaken. The JAR contains only code; you cannot access resources that way.
Google distributes their own "Google Play Services Library" as an Android library project, containing the binary code in a JAR file in the lib directory, the resources in the res directory, and an UnusedStub class in the src directory. If a better approach were viable yet I think they'd be using it.
UPDATE: While Android Studio is still in beta, it includes (buggy) support for AAR files. Seems this will eventually be the way to go.
Library projects bin folder contains jar file, copy that jar file in your main Application ( project ) libs folder we can get all the resource folders like this.
Follow these steps !
1) make your library project a normal project by deselecting IsLibrary flag.
2) Execute your project as Android Application. (It will not show any error)
3) you'll find a .jar file in bin folder..
4) Copy .jar in libs folder of your main application.
this will works fine with all the resources.
I was looking for the same thing for years. Combining byte code of java and resources (xml and other files) into one package. Currently I don't think its possible because even google has to include add resources separately in google play services lib available in the SDK .
What you can do best is generate a .aar or .jar file and add a folder of missing resource files.
Actually I want to know that if in my application's libs folder, any library file(e.g .jar file) is present, then after installing(running) that application, will library file present in .apk file?
According to my understanding, library FILE should present in generated .apk file. If I am wrong then please correct me.
If my question is below standard, then extremely sorry for that. Any help will be well appreciated
With recent versions of the Android tools, .jar files in the libs folder are automatically included in the build. (See Dealing with dependencies in Android projects.) So, yes, the library is included in the compiled bytecode (not as a separate file).
If you use ProGuard in a release build, then it will attempt to strip out any code which is not actually used. So, it may be that some parts of the library are included in the final .apk, and some parts are removed.
the answer is yes. The apk is just a zipped version of your compiled project. If you open it with winrar for example, youll see that everithing is in there ;)
You can try it and see yourself but you can not directly see the .jar file under libs folder in the apk generated. Library class files are all together are compiled into a single .dex file. If you decompile that dex file, you can reach the java codes.
This question already has answers here:
What are .dex files in Android?
(3 answers)
Closed 7 months ago.
When opening an APK file with WinRar (software to open compressed files). I got a bunch of files packed inside the APK. Among them classes.dex is one. My question is what is the role of this file and if we modify/delete the same file will it affect the APK?
.dex file
Compiled Android application code file.
From Android API GUIDES
Android programs are compiled into .dex (Dalvik Executable) files, which are in turn zipped into a single .apk file on the device. .dex files can be created by automatically translating compiled applications written in the Java programming language.
And yes if you will delete those files it will effect APK.
classes.dex is essentially all of the application logic. Code of the given application is written in java and then compiled to class files, then these class files are cross compiled (with many optimisations) to dalvik VM format. Note that there also might be some .so files which are also application code but these are generated when NDK is used.
You can not delete this file. You could however change it by first running this utility https://github.com/JesusFreke/smali which will generate smali code from this compiled dex which is somewhat similar to java and could be understood. You could also use tools ApkOneClick or ApkMultiTool to get Java source from the smali files but these would probably not be perfect and will require further fixing. When you change the code you want you should build the classes.dex again and put them into existing zip/apk file you have. Note that then existing certificate files (META-INF) will not be valid anymore and you will need to delete this folder and resign the apk package in order to instal it on the phone or emulator.
For more info you could check this question too What are .dex files in Android?
Also this is a great tutorial on disassembling dex files using existing tools http://blog.vogella.com/2011/02/14/disassemble-android-dex
What is the role of this file?
The role of classes.dex in Android is similar to that of JAR files in plain Java. It's a file containing bytecodes. In Android case, the bytecode is Dalvik bytecode, which is different from Java bytecode.
If we modify/delete the same file will it effect the apk?
If you modify classes.dex, you are modifying the programs behavior, which may or may not work after a repackage. If you delete classes.dex, then your application doesn't have code and you shouldn't expect it to work.
.dex file in the apk is the compress file which is made up of all the java classes in the application code. Its different than jar file. A jar file is a collection of .class files which are isolated. If we unzip .jar, we get all the classes separately. On the other side, .dex file is a single file made up with all .class file from application code.
Code compilation flow :
multiple .java files --> multiple .classes files --> a single .dex file
.dex files are the executables which are executed by the DVM...Dalvik Virtual Machine, which is a Runtime for Android.
.dex will never include resources. Resources are separately maintained in the /res folder in .apk