I was wondering, when adding a external jar to a android project, where do they actually live inside the APK package? I can't seem to find them.
Since Java usually loads classes at runtime as needed, it weirds me out that they don't seem to be in the distributable.
Is dex different? are these static builds?
If by "external libraries" you mean "library projects", the answer to this question can be found in the documentation:
When you build an application that depends on a library project, the SDK tools compile the library into a temporary JAR file and uses it in the main project, then uses the result to generate the .apk.
The separate .jars that you are referring to don't exist; they are merged into a single .apk at compile time.
Related
I am working on a multi module Maven project. We have created a project which builds an uber jar. The unpacked jar is about 60mb which is a problem for our client.
Are there any tools we can use to remove unused .class files within the dependencies when the build is completed?
Another option would be if we could analyse what .class files are loaded when running and produce a list of these and thus remove others from the build manually.
cheers,
I'm not sure if it could remove classes as such, but proguard has some awesome results in terms of minifying class sizes. You can see from the link it reduces the Ant module by 90%
I want to include a jar library in my project, but the library is really large.
I am not using all of the classes from that library, so when I compile my project, will all the jar content will be put in compiled project or only files (classes, etc...) which I am using?
And same question about Android Library Project: If I include the Android Library Project in my project and I am not using all of lib resources, will the compiler put all of Lib Project resources in my project or only resources which I have used?
i apologize if i don't understand the question, but maybe what you're looking for is this:
Selectively include dependencies in JAR
so here's the plugin
https://github.com/nuttycom/sbt-proguard-plugin
sbt proguard looks like it will cut down the unnecessary classes, so that your project will not be "heavy"
Although you may not directly be using classes within the JAR, you could be indirectly using them. Therefore, it would probably be unsafe to remove these classes from the jar-- unless you're 100% sure they're not indirectly used by the classes you are using.
Post ADT 17, non-Android libraries need to be included either in the "libs" folders of the project or exported via the "Order and Export" tab in the build path. What's the difference (if any) between importing a library externally:
And internally:
Is there an advantage to importing a library in a way that it is included in the "Android Dependencies" group?
How do you add external jar dependencies into your Android project's build path (internally or externally) make no difference on the actual build process (more specifically at compile and dex step), all it does is to tell build process where to looking for the required jars at compile and dex step.
The Android Dependencies element shown in Java Build Path - Libraries window is just another abstract layer that ADT plugin used for managing/grouping jar dependencies. where your external jar files (in your case android-support-v4.jar) appears (inside or outside Android Dependencies) in that window makes no difference.
Since r17, dependencies management has been much improved, and it is recommended to use libs/ directory store all jar dependencies (refer to you internal way), which is considered as a automation approach (as ADT plugin becomes more smarter now), see Revisions for ADT 17.0.0:
New build features
Added feature to automatically setup JAR dependencies. Any .jar files in the /libs folder are added to the build configuration (similar to how the Ant build system works). Also, .jar files needed by library projects are also automatically added to projects that depend on those library projects. (more info)
However, you can still use the old way (refer to you external way) if you prefer, which is considered as a manual approach (as ADT plugin was stupid before), see Recent Changes‎ for r17 Release:
Important: If you are still referencing jar libraries manually instead of putting them under libs/ be aware of the following:
If the project is a Library project, these jar libraries will not be automatically visible to application projects. You should really move these to libs/
If the project is an application, this can work but you must make sure to mark the jar files as exported.
Is there an advantage to importing a library in a way that it is included in the "Android Dependencies" group?
Automation vs. Manual from dependency management perspective, automation is always considered as more errorless than manual in the world of computer science.
The number one, show stopping, 'I can't believe they didn't test this', disadvantage of putting external jars in the libs directory is that you can't set the javadocs location for them, as the option shows as 'None (non modifiable)'.
Hence I still use Export option in build properties
It has to do with library dependency management of Android. for details see http://tools.android.com/recent/dealingwithdependenciesinandroidprojects
From the Eclipse FAQ
An internal resource resides in some project in the workbench and is therefore managed by the workbench; like other resources, these resources can be version managed by the workbench. An external resource is not part of the workbench and can be used only by reference. For example, a JRE is often external and very large, and there is no need to associate it with a VCM system.
So, quite simply, if you want to be able to manage a JAR as part as the project, exposing it to SCM and such, then treat it as a internal resource otherwise, treat it as a external resource. It will not make any difference in the APK produced in the end, its simply a eclipse thing.
If you want to avoid creating a copy each time you want to use your library, treat it as a external resource. But, can I suggest you look into maven and the android maven plugin, maven has a bit of a learning curve (especially if you are used to "make" or "ant" style build scripts), but it is very much worth the effort.
It seems like there are many different answers to this question, none of which work for me!
When I build my android app with eclipse, everything works fine. My JAR file is located in the /libs directory of my project, as recommended.
I am using SDK r15 (the latest android sdk available).
When I run ant debug, the apk file is built. However upon running the file in the emulator, a force quit is thrown. From LogCat, I see errors consistent with the JAR file not being compiled.
Many of the answers I see here, refer to older versions of the SDK. Also many refer to files which no longer exist. For example, android_rules.xml no longer exists in the ../tools/ant/ directory. Instead I see only a build.xml.
Has anyone solved this issue for the latest android.
Not I MUST use ant (not eclipse) for this build..
If you use ant to build your android project, just add your jar to the libs project. Eclipse will need you to add it through the project properties wizard. Maven should have some archteyp for that but I don't know it.
An extra jar file needs to be both added through dex and apkbuilder, that's not that easy to do it buy hand, you would be more confortable using ant tools coming with the android sdk, they are pretty well done and provide intersting features like adding jars, build a project for debug and release, testing,etc..
add your jar to a folder named libs and run ant compile from the project basedir.
I have an Android library project that has been working for me pretty well, but now I am interested in "converting" it to an external JAR.
How do I do that?
Can any Android library project be converted to an external JAR? If not, what are the restrictions or limitations?
Can any Android library project be converted to an external JAR?
Not right now.
If not, what are the restrictions or limitations?
If your library is purely Java code, with no resources, you can create a JAR out of the .class files, just as you would with regular Java.
If your library uses resources, you can still create a JAR as above. However, you will need to look up the R values (e.g., R.layout.main) via reflection or getIdentifier(), and your resources will not be packaged in the JAR but would have to be distributed separately.
In the future, the build tools should support creating distributable JAR files out of library projects, complete with resources. The current build tools do create JARs, but they are not designed to be distributed but are rather internal build artifacts at the moment.
http://developer.android.com/guide/developing/projects/index.html#LibraryProjects claims that you can't export these to an external JAR. Specific quote:
Similarly, you cannot export the library project to a self-contained
JAR file, as you would do for a true library. Instead, you must
compile the library indirectly, by referencing the library in the
dependent application and building that application.