How do we count the number of methods in a Library file.
For eg, a Jar or AAR.
This is required to know the number of android resource IDs used by the library used by the project. This would help in estimating how close we are to 65K dex limit in Android.
dexcount-gradle-plugin: gradle plugin, works for any Android project (library or application), nice D3 sunburst partition chart output.
dex-method-counts: command-line tool, supports apk / zip / dex / directory.
Methods Count: only works for online public library, just give library 'compile' statement (e.g., com.google.code.gson:gson:2.4).
APK method count: only works for APK, expandable tree results.
Why don't you give this site a try, MethodsCount. It also gives you with an awesome Android Studio plugin which add method count beside all your libraries in the build.gradle file.
You can also try this and this. I have tried both of them and they are worth checking.
I've created a small shell script that uses a solution, provided on other StackOverflow Answer for jar files. Maybe still could be useful. It takes AAR file and returns methods count. But you have to have Android SDK installed for that.
Related
I'm trying to build an app bundle but I'm getting the following error:
File 'root/lib/x86_64-MacOSX-gpp/jni/libjunixsocket-native-2.0.4.jnilib' uses reserved file or directory name 'lib'.
For what I've seen from similar questions, this issue is normally solved juggling dependencies or files in the project structure, but in this case it seems to point to a native library involved in app architecture if i'm not mistaken. Any ideas how to solve this?
It looks like you are adding a dependency as a jar instead of an aar.
The aar contains the information of what files should be considered as Android resources, native libraries, etc. in the app. A jar is just a plain list of files without Android concept. Because the jar you're depending on contains a directory lib, the files would normally end up being considered as native libraries, but because the files come from a jar instead of an aar, the build system warns that it's unlikely to be a native library and may have unintended consequences at runtime.
Try to package that library as an .aar instead of a .jar. See this documentation: https://developer.android.com/studio/projects/android-library
Edit:
Note that this file could not be loaded by the Android platform if it was included as is in the APK, so even though the previous build systems would allow you to put anything in an APK, the Android App Bundle is more restrictive to ensure that you don't accidentally put unnecessary files which would increase unnecessarily the size of your app.
Ok it is working now! Steps I used to found the problem (thanks for pointing me in the right direction #Pierre)
Run a gradle build --scan from your terminal or go to the Gradle tab in Android Studio, select :app, help , androidDependencies to see your dependency graph.
Search the dependency graph for the library name related to the problem ( in my case I searched for socket, there was no match for libjunixsocket for example).
Going upwards on the dependency tree I realized it was caused by the 'io.voucherify.android.client:voucherify-android-sdk:2.1.0' dependency.
I just added #aar at the end of the dependency implementation, and I managed to build the app bundle.
implementation 'io.voucherify.android.client:voucherify-android-sdk:2.1.0#aar'
I'm porting a project from NDK build to Android Studio.
Currently the project has a precompiled header attached (with NDK build), which speeds up compilation time a lot.
I'm looking for a way to add precompiled header (.pch) to my external native build within Android Studio project. I'm using CMake.
I am in the same situation and I have found several user-made script to do that.
I would recommend this one:
https://github.com/larsch/cmake-precompiled-header
In order to make it work for the latest ndk-tools which uses clang, copy paste the content of this pull request:
https://gist.github.com/leeor/316168500765cf51ae97
into the PrecompiledHeader.cmake file (replace everything in this file, except if you want to keep GCC/ MSVC compatibility, then just you will have to merge the two files which shouldn't be hard).
It should work, except some special CMAKE_CXX_FLAGS that triggers an error in the export_all_flags function, and that I don't know how to fix yet. I'll keep you updated with my progress.
I'm using the commonsguy cwac-camera library, as per the demo-layout example, documented in "Working directlly with cameraview".
All is fine referencing camera/ and camera-v9/ as Android library projects in source form (I need Android 2.3 compatibility, that's what camera-v9 is for).
When I switch to using the library via JARs:
- cwac-camera-v9-0.6.8.jar only includes CameraFragment and BuildConfig classes, so I need also cwac-camera-0.6.8.jar with the other classes.
- including both JARs causes the following self-explaining error when running the project (not at compile time) Conversion to Dalvik format failed: Unable to execute dex: Multiple dex files define Lcom/commonsware/cwac/camera/BuildConfig;
I could just use the source as library project, or use Gradle, but I want to know if this is a bug to open an issue on Github, or if I'm doing something wrong.
To replicate the error, just clone the demo-layout example add both .jar files to libs folder, and run the project.
No, this appears to be my fault. They must have changed something in the Gradle build process that I am using to create the JARs. I will try to fix this tomorrow. In the meantime, you could go into the cwac-camera-v9 JAR and try removing the classes in com.commonsware.cwac.camera, leaving only those classes incom.commonsware.cwac.camera.acl.
My apologies for this, and thanks for pointing it out!
I want to create an Android jar library which has activities which use layouts that are all within the jar file.
I have been researching and trying different methods for the last few days and exhausted the related posts here. I have managed to get drawables and other raw assets to reside and be loaded from within the jar. However I have not been able to include valid resources which include the layouts. The official view is that it is not supported yet however I am sure it can be done.
I see that this is possible with .aar libraries when using Gradle but I am unsure if .aar libraries are compatible with older Android projects.
Could anyone shed some upto date info on this issue of resources/layouts in jar libraries and also the compatibility of .aar libraries.
Many thanks
I want to create an Android jar library which has activities which use layouts that are all within the jar file.
That is not possible, sorry. However, you are welcome to create an Android library project that serves this role, and that library project can ship a JAR instead of Java source code (see the Play Services SDK's library project for an example). The layouts would not be inside of the JAR file, though.
The official view is that it is not supported yet however I am sure it can be done.
I am sure that you are incorrect in your assessment.
I see that this is possible with .aar libraries when using Gradle but I am unsure if .aar libraries are compatible with older Android projects.
Project age has nothing really to do with it. If you are using Gradle, AAR files work. If you are not using Gradle, AAR files do not work.
I have an Android code base which uses APIs with settings to get different data for several apps. All apps use the same code base but with one or two design tweaks. So how do I re-use the main code base without having to copy the whole Android project each time?
iPhone uses multiple targets in the same project which works well. If android cant do this do I need to compile binaries of the code base in one project and then import into each new app project? If so how? I'm using Eclipse and am an intermediate Java developer.
Any help much appreciated!
Doug
Check out "Working With Library Projects" from the Android documentation. This should be just what you're looking for: http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject
The current way to approach this issue if you are using Android Studio with Gradle is by using Gradle, Build Type + Product Flavor
http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants
Build Variants
One goal of the new build system is to enable creating different versions of the same application.
There are two main use cases:
Different versions of the same application
For instance, a free/demo version vs the “pro” paid application.
Same application packaged differently for multi-apk in Google Play Store.
This new concept is designed to help when the differences are very minimum. If the answer to “Is this the same application?” is yes, then this is probably the way to go over Library Projects.
Note: This answer is basically obsolete now that one can create .aar libraries with resources. It still works, though, and there may be times when the portability of a .jar is desirable, so I'm leaving it here.
Blumer's answer is a good one, and you should definitely look into Android's idea of library projects. However, there is another alternative. If you have a module that contains only Java code, but no resources of any kind (images, layouts, etc.), you can compile it to a .jar file separately and use the resulting .jar in multiple application projects. It works like this:
Create a new Java project in Eclipse (not an Android project) and move the source code of your module there.
If your module references any classes from the SDK, you'll need to add the Android SDK .jar to the project's classpath (Project > Properties > Java Build Path > Libraries > Add JAR).
When your module is ready to use, bundle up its .class files into a .jar. You can do this manually, or you can look around to figure out how to get Eclipse to do it for you.
Copy your module .jar file into the "libs" directory of your app's main project.
Add the module .jar to the project's classpath (again, Project > Properties > Java Build Path > Libraries > Add JAR).
Now you should be able to build multiple apps using the same .jar, while maintaining only one copy of the module's source code.
Depending on your particular situation, this may or may not work any better for you than the standard Android library mechanism. But it's worth considering as an alternative.
The Android documentation recommends another approach if there aren't too many "different APIs" used.
The idea is to use reflection instead of making direction references to the code. Make sure to use optimized reflection instead of lookups every time.
References
http://developer.android.com/training/multiple-apks/api.html
http://developer.android.com/google/play/publishing/multiple-apks.html#ApiLevelOptions
You might want to consider using a source control system like Subversion (or GIT). Keep your most feature complete version in the trunk, and make branches for your separate versions that use different data sources or require minor layout changes, etc.