We have a very simple java SDK that can be imported in any android APP to do some basic tasks. One of the functionality of this SDK is to read the AAID, so we depend on Google-Play-Services.
Our current approach is use gradle java plugin and add the play-services.jar as a dependancy to our project. The latest versions of the google-play-services are packaged as .aar. So I need to know if there is any efficient way to do this or extract the aar and add the classes.jar as dependancy. While that will still work but I feel the entire solution is hacky.
I need to know what is the right way to get this done?
Thanks
I'm using a library (https://github.com/PhilJay/MPAndroidChart) for plotting data in an android app. When app-release.apk is created by the program it is ready to be installed on the tablet I use for testing.
What is puzzling to me is how the parts of the library, which i use, follow with the release. In other scenarios, for example in Visual Studio and c# - program being installed on Window machine, libraries require dll files to be installed and registered on each targeted machine. In my scenario the library is written specifically for Android, but if I somehow managed to include a c++ or a c# library in my Android app using tools like libstdc++ or MONO, would it work the same way when it comes down to app-realease.apk?
Are all classes in a library included in the app-release.apk or just the parts that I use?
Thanks in advance and please let me know if the question is unclear before downvoting it!
Normally, when you build your APK, all the libs you have imported (jars) are included and transformed to dex files, as the rest of your code. So, yes all the classes are included, even if you don't use them.
You can use Proguard to remove them from the APK. Look at this post :
Use Proguard for stripping unused Support lib classes
I am developing an android app which is available as a free trial version and as a paid pro version. Of course, both are sharing large amounts of code so I moved the core functionality into an android library project. I created two independend android projects which use the core project as a library. So far, it works. But when compiling the final apps I realize the apps size more than doubled compared to the library project.
As I changed almost nothing besides the code layout I can't explain why this happens. I suppose it may have something to do with exported libraries the core library project includes. In Eclipse I can see both the library project as well as the app projects do show all the jar files the library includes in their respective "Android Private Libraries"-folders. Are those libs included twice, maybe?
I found out it was proguard that is (of course) not being invoked when building the library project. And the new app projects didn't have any proguard configuration yet. Adding proguard optimization to the app projects solved the issue. The complete build is now only 200KB bigger than before (1MB). Looks like this is the minimum overhead.
I need to add some jars from JRE7 library to my Android project. But for example rt.jar is in conflict with android.jar from Adroid 2.2 SDK, so I get this error:
Ill-advised or mistaken usage of a core class (java.* or javax.*)
when not building a core library.
This is often due to inadvertently including a core library file
in your application's project, when using an IDE (such as
Eclipse). If you are sure you're not intentionally defining a
core class, then this is the most likely explanation of what's
going on.
However, you might actually be trying to define a class in a core
namespace, the source of which you may have taken, for example,
from a non-Android virtual machine project. This will most
assuredly not work. At a minimum, it jeopardizes the
compatibility of your app with future versions of the platform.
It is also often of questionable legality.
If you really intend to build a core library -- which is only
appropriate as part of creating a full virtual machine
distribution, as opposed to compiling an application -- then use
the "--core-library" option to suppress this error message.
If you go ahead and use "--core-library" but are in fact
building an application, then be forewarned that your application
will still fail to build or run, at some point. Please be
prepared for angry customers who find, for example, that your
application ceases to function once they upgrade their operating
system. You will be to blame for this problem.
If you are legitimately using some code that happens to be in a
core package, then the easiest safe alternative you have is to
repackage that code. That is, move the classes in question into
your own package namespace. This means that they will never be in
conflict with core system classes. JarJar is a tool that may help
you in this endeavor. If you find that you cannot do this, then
that is an indication that the path you are on will ultimately
lead to pain, suffering, grief, and lamentation.
I know there have been several threads about it and things like JarJar, OneJar or FatJar might be good for me. But I don't know how to make any of them work and documentation doesn't really make it clear (for me). I guess they use Ant commands, but I have always used Eclipse built-in builder and now I have no idea how to use neither Ant nor any of mentioned above.
So my question is: how can I repack this rt.jar so I could compile it in my Android project?
Thank you!
EDIT:
Ok, so what I want to achieve is to create a .jar, which can be used during developing Android application (simplifies some functionalities, doesn't really matter). But I would also like to be able to add the very same .jar to standard Java project in order to use some functions there as well. It would look like this:
Whoever writes an application adds this .jar to his Java project -> it enables him to generate certain files (internet is needed to do it) -> these generated files are then added to Android project -> later on, when somebody uses this Android app, these files provide certain functionalities without using internet (off-line).
It would be ill-advised to do this in any project at all, even if it were possible. You would be opening yourself to a wealth of class incompatibility and loading problems. But in any case it doesn't even matter because the core Java libraries are loaded way before your archives are even touched, making any such attempt at overriding them moot.
Not to even talk about the fact that Android is using its own JVM implementation which is not fully compatible with JDK 6 (forget JDK 7). Also note that it may be a copyright violation to package the core Java libraries with your code and could change your licensing options (IANAL).
You need to find another way to resolve whatever issue you are having (which you failed to mention in your question).
There are many JARs that work nicely on both Android and on classic Java. None involve having Android developers pirate rt.jar. Stick to java.* and javax.* classes that exist in both the Android SDK and in whatever level of Java you are supporting, and your JAR will work fine in both environments.
You should ideally refrain from using such .jar files, but if you must, you can add them to build path. But this, at times results in a conflict, like the one that you are facing right now. What you need to do to resolve this kind of a conflict, is:
add the jar in the build path.
Check "referenced libraries". The jar file should appear under the same.
once it features under referenced libraries, check the "android dependencies" virtual directory. If you get to see that you have an instance of the same jar file there as well, you should delete the "android dependencies" folder altogether. (Trust me, this does not affect your project in any way).
having done that, you should be able to compile your code without any further conflicts.
Happy coding.. :)
In my new Android app, I'm required to use a library when Android Version in 1.6 and 1.5 and include some other library when the version is more than 1.6.
I know how to get the Android SDK version, but I'm stuck at inclusion of specific library at run time.
Any Help ??
Libraries are included in your APK file. As such you cannot remove libraries from the APK at runtime.
As far as loading classes at runtime is concerned, you can always do that, but the content of the APK (the JARs / classes you include in them is static). You are offcourse free to load particular classes from it based on the API level.
If you're worried about the file-size of your APK, and you want to optimize the APK packaging and tweak your app based on the capabilities of the device of the consumer of your app, you should checkout this link :
http://android-developers.blogspot.com/2011/07/multiple-apk-support-in-android-market.html
It allows you to target different APKs based on device capabilities (ex: API level). That way, you can create 2 APKs with the specific libraries you want to use for a specific API level.