when building .ane files, you should be careful about naming your resources so no two extensions would conflict each other when used in one app. I know that and it's ok.
I have another kind of conflict problem! you see, in one of the extensions I've been building, I used the external .jar file, Google play services and the extension works like charm. everything was fine until the day that I created another extension which was happened to use the external jar file, Google Play Services again!
when building .ane files, I actually merge any needed external .jar files into the one that I have exported myself from eclipse.
now that I have two different extensions both happen to be using Google Play services external .jar file, when I use them in one app, it won't allow me to package my .apk
the error message says:
java.lang.IllegalArgumentException: already added:
com/google/android/gms/appstate/OnStateListLoadedListener;
at
com.android.dx.dex.file.ClassDefsSection.add(ClassDefsSection.java:123)
how can we bypass this kind of confliction?!
Extension's will not allow same method name's even they are in different extensions. i think that is the mistake you did in making extension's. please look at them and changes method names it will work.
Related
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.
Okay, I would like to know if anyone managed to pull this thing of? I am making native extension and my native JAR uses Google Play Services via reflection. I have added Google Play Services library to my native extension, here's how platform.xml looks like:
<platform xmlns="http://ns.adobe.com/air/extension/3.1">
<packagedDependencies>
<packagedDependency>android-support-v4.jar</packagedDependency>
<packagedDependency>google-play-services.jar</packagedDependency>
</packagedDependencies>
<packagedResources>
<packagedResource>
<packageName>com.google.android.gms</packageName>
<folderName>google-play-services-res</folderName>
</packagedResource>
</packagedResources>
</platform>
My android build folder has structure like this:
android
- nativeLib.jar
- android-support-v4.jar
- google-play-services-res (folder)
- google-play-services.jar
- library.swf
When I build my ANE w/o Google Play Services library (which has around 5.1 mb), I see that my ANE has for example 800 kb. After adding Google Play Services dependency like this, ANE has around 6 mb which for me indicates that these JARs stated in platform.xml are somehow bundled in native extension. Now, my native JAR has some function where I can see if calling method from Google Play Services library fails or not. It always fails when I call it from AIR Android app I made and where I integrated this generated ANE.
So, my native JAR and google-play-services JAR are standing next to each other before packing them in my ANE, but after triggering method from my native jar, it turns out that it isn't aware that google-play-services.jar is anywhere around.
Just for the record, I don't have any issues in bridging AIR with native library, all calls are working properly and interface I am exposing to ActionScript files is fully functional, it's just that native library is performing certain actions depending on wether Google Play Services are found or not and in my case -> they are never found.
Any ideas what I may be doing wrong and how to pull this thing of?
Thanks in advance.
You could just use this ANE:
https://github.com/distriqt/ANE-GooglePlayServices
We've packaged both those libraries and resources in that ?
I managed to get Google Play Services working (with just the necessary JAR files) using this code:
https://github.com/Oldes/ANEAmanitaAndroid-public/tree/GooglePlay
You can see what I did to have it working from the minimal "hello" ANE using this pull request details:
https://github.com/Oldes/ANEAmanitaAndroid-public/pull/1
I've got the GPS jar files from SDK extracting them from AAR archives like:
extras\google\m2repository\com\google\android\gms\play-services-base\9.4.0\play-services-base-9.4.0.aar
In each aar (which is just a zip) file is classes.jar which I just copy and rename as play-services-base-9.4.0.jar in my project.
Also to have the GPS running correctly, you must specify correct application ID in the app manifest like at this line:
Background
I'm working on an app that has become very popular, so much that a part of it is supposed to become an SDK (which would be available for developers), and the app will split to 2 apps (both use the SDK).
According to what I know, there are multiple ways to create an SDK module (previously called "project" on Eclipse) :
Completely open sourced (Android library) - all sources and resources are open sourced and can be modified. An example might be Facebook's SDK and a lot of Github repos.
a single Jar file, which can be closed sourced.
The problem
Sadly, I can't make the SDK open sourced, and it should relatively be protected vs prying eyes (obfuscated etc...).
The issue here is, the SDK needs to use some resources of its own (drawables, strings,...), and so far (because I didn't have a lot of experience with creating SDKs) I've found 2 ways to handle resources for SDKs :
use reflection and/or "context.getResources().getIdentifier" . This is quite messy, as I lose the whole "R" usage of the code. Also, it has issues with "styleable" , as I've written here. It also makes it hard to find unused resources.
even worse ways: put resources in assets folder, put files in a wacky way inside the jar file, ...
Note that a part of the SDK includes custom views (for example, classes that extend from TextView), so even if I do split the SDk into 2 modules- resources and java files, both might have issues of dependencies (each uses the other one).
The question
Is it possible to somehow solve this issue?
Is it possible for the code part of the SDK to remain closed sourced, reach the "R" file as usual, and make it easy for both me and whoever use the SDK ?
How would I then generate the jar file as being obfuscated via Android Studio? and is it possible to prepare it to to be used via gradle afterwards?
Can I maybe make the Android-library of the SDK into an obfuscated jar file and not worry about the "R" file ? I ask this because this way I could enjoy both worlds: for our apps, it would remain open sourced, and for third party apps it would be closed sourced.
EDIT: seeing that this is supposed to be easy, I've tried it myself. I've created a totally new POC project which has an Android library module called "sdkmodule", and added this class to it:
public class SdkClass
{
public String doIt(Context context)
{
return context.getResources().getString(R.string.app_name);
}
}
Then, I've made the app's module to use this one, and I wrote this code in it:
#Override
protected void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
SdkClass sdkClass=new SdkClass();
Log.d("AppLog","string from SDK:"+sdkClass.doIt(this));
Log.d("AppLog","string with same ID name from app:"+getResources().getString(R.string.app_name));
}
What I expected is that the first log would print the string that's in the SDK module, and the second to show the string of the current project, but instead I got an exception:
java.lang.NoClassDefFoundError: Failed resolution of: Lcom/example/user/sdkmodule/R$string;
On another try, I've got the same string that's used on the app itself (the one that uses the SDK module). And, on another run, the SDK produced the needed string as I've wanted.
How could it be? What should I do ?
In addition, I've tried to make a second activity in the SDK itself, and I've created a resource there that has the same resource name (used for a textView in its layout) as of the app itself, yet with a different value, yet when I've reached this activity, I've seen the one used by the app.
Here's the project, zipped (ignore the name of the folder, I wanted to try flavors too) :
https://drive.google.com/file/d/0B-PZZGk2vPohX25WUDNKTmotUTg/view?usp=sharing
The answer to your problem is to package and distribute your library as an AAR bundle
This format allows you to provide an obfuscated SDK jar and with its resources and the R mapping file.
This format is a standard and fully supported by maven-android-plugin (actually it's the replacement of the old APKLib format which supports only the distribution of source files).
Of course it's also supported by Gradle and Android Studio.
The Android Archive (AAR) format does what you want. It's like an Android-specific JAR file and contains compiled code, but includes its own resources and manifest. You can also include obfuscation as part of the build process. By default, the current version of Android Studio (1.2) and Gradle automatically build .AAR files for all library modules you create in your project.
You can change an app module into a library project that will publish an AAR file just by changing apply plugin: 'com.android.application' into apply plugin: 'com.android.library' in your module's Gradle file. The .AAR file will be placed in your MODULENAME/build/outputs/aar folder after each build. Some more information is available here.
Edit 1, after question updated:
The resources in your AAR get consolidated with the app module when the final APK gets compiled. The app resources will override the library's. This is probably by design, to allow people using a 3rd party library to customize its resources when creating their app, without having to rebuild the library. I think the easiest way to solve your resource conflict issue would just be to name your sdkmodule resources something more unique. Why not make the string key R.string.com_example_sdk_name or something?
No, the AAR libraries don't get obfuscated by default, but you can set up ProGuard in the Gradle build file for your AAR library to take care of this. Other tools are also available.
With all the new hype surrounding native extension support in AIR 3, I haven't found a single thing that confirms or denies it is possible to include and use an external JAR inside the native Android implementation.
All of the examples basically showcase the ability to hook into the built-in Android APIs. But what if someone wants to use one of hundreds of libraries that make it easier? Certainly it seems like this should be possible. I'll try to outline what I've done and maybe someone will spot a flaw:
Successfully created native Android library, using compiled-in imports from 3rd party Android library XYZ.
Exported Android project as JAR file.
Note: The referenced 3rd party JAR is in /lib inside the jar.
Successfully created ActionScript library (SWC) to interface with native Android library.
Created ANE package from SWC, extension.xml, Android JAR, and library.swc (for platform Android-ARM, extracted from SWC).
Note: Have also tried putting the 3rd party library in file structure outlined here: http://help.adobe.com/en_US/air/extensions/WSf268776665d7970d-24823354 12ffea65006-8000.html#WSf268776665d7970d-6be13ace1308aaebeca-7fff. I think this is more geared to runtime type execution with JNI or whatever, so that article has left me a little confused.
Used ANE in example Flex Mobile project.
Built and installed APK file on test DroidX device.
Can successfully see AIR application loading (and trace statements) in LogCat "ActivityManager: Displayed com.me.androidapp/.AppEntry"
Can successfully see native Android Java code being invoked via runtime by AIR app to instantiate extension & context. "mye_native: MyExtension.initialize", "mye_native: MyExtensionContext.createContext"
As soon as AIR app tries to call native function, it blows up, not able to find the classes from 3rd party Android library: E dalvikvm: Could not find class 'com.thirdparty.SomeClass', referenced from method com.me.nativeExtentions.MyExtensionFunction.call
Any ideas? It seems like it should work this way.
One thing I have noticed is that when I blow apart the APK and Dex from a pure Java Android app of mine (that also has 3rd party android libraries), it appears that the classes from the 3rd party have been included inside it (not just a jar reference).
When I do the same thing with my Flex APK, I find only my own Java classes plus Adobe's, and the 3rd party ones are nowhere to be found that I can see.
I posted this on the Adobe forums, but I thought I'd give the SO think-tank a try. Thank you.
You have to combine all your jars into one. Something like http://code.google.com/p/jarjar/ or your own Ant script will help.
Edited to add example:
Suppose your main extension jar file is extension.jar and you are using code in external.jar. Then you can put the classes from external.jar into extension.jar using the Java jar tool:
jar -xf external.jar
This will extract the .class files into package folders. If the top-level package is "com", then you can add those to extension.jar with:
jar -uf extension.jar com
(Repeat the second command for each top-level package in the external jar.)
You could also combine the library jars manually by turning them into zip-files (just rename them to .zip) and copy the classes from the 3rd party library into the main one and rename that one back to .jar
I work for an operator, and we preload applications on Android phones.
However, some preloaded applications, once upgraded from Market, crash.
The problem is this:
- the application contains a .so library file
- in order to preload the complete application on a phone, the .so library file has to be placed separately into the lib directory (/system/lib/libXXXXjni.so)
- when the preloaded application is upgraded from Market and run, instead of the .so library file in the new APK being found, the older preloaded .so file is found first - causing a crash, because the two .so fiels have differing contents
Does anyone have a suggested work-around, or knowledge of the library-searching algorthim which may help me solve this?
One possible solution might be to simply rename the library file, but is that enough?
Thanks in advance...
When you preload, try putting the applications library in:
/data/data/com.package.foobar/lib/libXXXXjni.so
Renaming the library would work. Possibly using the app's version number as the name of the .so file. The build becomes more complicated though.