I've created a project that have 3 dependencies for 3 different android projects marked as libraries. I managed to run the application from eclipse and everything works fine.
The problem: I've exported the project as a signed apk. The apk was created and I was able to run it on my device but when it tries to access an activity that resides in one of the android library my app crashes with ActivityNoFoundException. It seems that the android library projects were not added in the final apk, but why?
All the manifest files are merged into the main manifest file.
What can be the problem? Thank you!
Does your project use proguard obfuscation? it's possible the activity names are being obfuscated and therefore would not match up with what's in your manifest. Usually obfuscation isn't run when you run the app from an IDE so could also explain why it works there. You could also try unzipping the apk and looking inside to see what is actually making it in
Related
I have an application that's written with Unity. It uses a custom Application and Activity class. Previously this has worked just fine but I've recently switched to using gradle to perform the build instead of Unity's deprecated internal build process. My Application and Activity classes are located in a library that's in the form of an aar file. The custom classes are referenced from a the and tags of a custom AndroidManifest.
I can see that the classes are present in the aar. I can see that the generated AndroidManifest references these class. I can see the dependency on this library in the generated build.gradle file. I can tell that the build process is actually referencing this library in some form. However, these classes are not present in the resulting APK, resulting in a crash on launch.
I do not have proguard or anything similar enabled. I can tell that this is a new problem because older versions of the APK do have those classes. What could be causing these classes to not be included in the resulting APK?
The package that contained those classes had the same name as the one generated by Unity. I changed the package name and everything seems to be working now.
I have a very strange issue i suspect related to multidexing (but not sure).
I have an app module and a library module. The library is executing some code on app start which, through an interface on the main application class, gets a class name defined in the library.
Now the strange part begins.
The app is multidexed according to the following instructions - Configure Apps with Over 64K Methods - and I have 2 build types - debug and release. On release build im using proguard to obfuscate and shrink the code. On debug build im not.
When running the app on devices with android +21 everything works fine in both build types.
When running the app on devices with pre lollipop version everything works fine in release build type but in debug build type im getting NoClassDefFoundError because of the class the application is trying to return to the library.
Following the suggestion in Declare classes required in the primary DEX file i've used the APK Analyzer in android studio to examine the distribution of classes between the dex files and saw 2 things:
in release build type there is only one dex file.
in debug build type there are 2 dex files but the problematic class (and its parent) is defined in the primary dex file.
Moreover, when im replacing the call from the library to the application (getClassName() in the diagram) with the actual class name everything is working fine in all build types!
As a last attempt to understand whats going on here i've compared the 2 apks, the original one with a one without the call to the application (replaced with actual class name), and the only difference i could see is the library code making the call. In terms of classes distribution between dex files there is absolutly no difference!
Does anyone understand whats the problem here ? Thanks.
eventually it was com/newrelic/agent/android/api/v2/TraceFieldInterface.class that i had to make sure is in the main dex file.
If someone is using newrelic you might want to pay attention to this.
I have a mature app that needs to have an SDK brought in that wraps the camera and makes it do some spiffy processing while it's running. The SDK has come to me in the form of some aar files but my app still lives in Eclipse. Because of my massive, steaming pile of a branding structure and deadlines for this integration the uncertain timeline required to fully migrate to Android Studio will not work (for now) so I'm going for converting the aars and using them in my app via Eclipse.
The problem I'm having is that I need to kick off the activity in the library but even though I fixed up all my build time reference problems, when running the app once I get to the point that is supposed to kick off the activity I get this error.
I've read through and double checked dozens of how-tos explaining how to consume the aar files and I think I've followed every step including:
Unzip the aar files and dress them up as individual library projects, including the file structure with the resources, the manifest, and the .jar
Make the project that needs the libraries add them as such
Add the .jars contained in the library projects to the build path (this step was not listed in most articles, and wasn't necessary for the project to build, but nevertheless it did not help my problem)
Declare the activity in your AndroidManifest.xml that the library brings in and declares in its AndroidManifest.xml
As I've said, everything looks good at build time, so I'm not sure what else to check. Because I'm reading that Gradle and Android Studio mashes manifests together really well, I have a hunch that it's something I'm supposed to regulate between the manifests but I don't know what it could be if that is it. I've wondered if I'm declaring the 3rd party's activity properly, but I'm not sure how to test it because the only way I can think to test it is to provide gibberish for the namespace but even then there are no complaints. I've also tried dissecting the .apk to look at the .dex file but I could not decipher anything useful.
My guess is that the library may not be building properly in eclipse - even before it's being added as a dependency to the application project.
Try looking at out/classes/* and making sure you have a .class file for the activity in question. I think the .class should actually be in the library as well as end up in the application project's out/ dir also.
If there are any native files (x.so) (as I would imagine there might be for spiffy camera stuff), you can look for the x.so files being included in the out/ dirs of both the library and application projects as well as the library.jar file.
Another option to maybe consider for this use case: https://github.com/ksoichiro/gradle-eclipse-aar-plugin
It seems that our app had a bad version of the appcompat-v7 support library. The .jars in it were different sizes than the one that comes with the SDK and several resources were missing. I have no idea how we ended up that way or where this bad version came from. Once I replaced it, things went great.
Later, I did encounter the need to drop in the .so files into the libraries I made that came out of the .aar files as Stad Kurdziel said in his answer, but that was causing a different error (the exception explicitly states that the .so is missing) and I arrived at the solution independently.
is there a simple way to have installed two version of the app on the same android Phone?
Im updating a old web app to a native android app. For testing purpose it would be great if we could have both installed at the same time on the same device.
It would be great to rename the update just temporary.
If I rename the package name in the AndroidManifest, then also R will be renamed and I have to reorganize the imports etc.
Is it possible to do a simple rename only somewhere in the AndroidManifest without changing a single line of code (even not with eclipse / android studio refactoring mechanism).
I have tried to mark my native app as library project and to include it in a new Android Project with another package name. But I will get trouble with this approach, for instance with actionbar sherlock:
Unable to execute dex: Multiple dex files define Lcom/actionbarsherlock/R$attr;
Conversion to Dalvik format failed: Unable to execute dex: Multiple dex files define Lcom/actionbarsherlock/R$attr;
If you are using new gradle build system you could create new build type and then just add packageNameSuffixto it. This will add suffix to your package name but everything else stays the same.
buildTypes {
debug {
packageNameSuffix ".debug"
}
}
There is an easy way if you want to do it temporarily. You need to modify the AndroidManifest.xml file.
Find the line that looks like this:
manifest package="com.example.myapp"
and change it to something like:
"com.example.myapp.debug"
AFAIK there is no way other than changing the application package name, but it's fairly easy.
In Eclipse, right-click your project and select Android Tools > Rename Application Package.
I have been working on one project which is too complex and contain very much space with so many images and Java files as well.
Somewhere I have read about the proguard which optimizes the code.
I have used it, but it's still does not have an effect on my final APK file.
It might be I have made a mistake somewhere. I have the following this like http://developer.android.com/guide/developing/tools/proguard.html.
How can I optimize my code?
You can add it to the default.properties. I've been adding manually without having a problem so far.
If you add the line:
proguard.config=proguard.cfg
As said it will only use ProGuard when exporting signed application (Android Tools => Export Signed Application)
If you start the project with the SDK before Android 2.3 the proguard.cfg file will not be created (next to default.properties as in 2.3>).
To enable automatic creation of it, just simply update to the SDK of Android 2.3 and create a new project with existing sources (which are the sources of the project you currently have).
Automagically the proguard.cfg fill will be created.
Without optimizations the compiler produces very dumb code - each command is compiled in a very straightforward manner, so that it does the intended thing.
The Debug builds have optimizations disabled by default, because without the optimizations the produced executable matches the source code in a straightforward manner.
Please refer this one
From documentation:
ProGuard is integrated into the Android build system, so you do not have to invoke it manually. ProGuard runs only when you build your application in release mode, so you do not have to deal with obfuscated code when you build your application in debug mode.