Bug 17068 - Android Bindings for .jar's already in /system/framework/ on devices
Summary: Android Bindings for .jar's already in /system/framework/ on devices
Alias: None
Product: Android
Classification: Xamarin
Component: Bindings ()
Version: 4.10.2
Hardware: PC Mac OS
: High normal
Target Milestone: 4.12.0 (KitKat)
Assignee: Radek Doulik
Depends on:
Reported: 2014-01-06 10:48 UTC by Redth
Modified: 2014-02-07 04:06 UTC (History)
7 users (show)

Is this bug a regression?: ---
Last known good build:

classes.jar file (525.58 KB, application/java-archive)
2014-02-06 06:44 UTC, narayanp

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Redth 2014-01-06 10:48:21 UTC
On some platforms, such as Amazon, when creating bindings for .jar's, the .jar that is referenced in the binding already exists in the /system/framework folder, and the .jar is meant to be used only as a reference, not embedded in the binding itself.

So in the binding project, we have to specify the Build Action for this jar to be 'InputJar'.  This means the jar is built against as a reference, but not actually embedded in the binding project's generated .dll assembly.  

What happens then is that when you reference the binding .dll assembly in your own android application, you need to add the originally bound .jar to your own android application project and set it's Build Action to 'AndroidExternalJavaLibrary', otherwise it thinks the .jar file is missing as it should have been included in the .dll generated by the binding project.

If we're trying to make a Component for the store with these bindings, it adds an extra step in the process of adding the component to your application, and is definitely not user friendly.  The ideal solution would be to have a new Build Action in the binding project that would be something like 'InputJarExternalJavaLibrary' where it could somehow pass forward the information to whatever android app is consuming the binding that the library it needs is of 'AndroidExternalJavaLibrary' build type.  I'm sure there are some technical hurdles to consider (eg: maybe the jar needs to be embedded in the binding, but then stripped out when the application compiles it), but implementing this would smooth out the user experience greatly.
Comment 2 Redth 2014-01-06 13:22:21 UTC
This is exactly the "pull jars into build by attribute, don't embed the proprietary jars in the component" matter.

As for redistributing amazon, there's this: https://developer.amazon.com/sdk/pml.html
I'm not lawyer, but it seems like it perhaps may permit redistributing the libraries (see section 1 "Program Materials".  It seems you can redistribute the library only in products intended for distribution through their program, however I wonder if it would be acceptable in a component since the component is intended for distribution through their program....

In any case, Amazon is just one example of this.  I happen to be working on another component/binding which has the same requirement, and in this case I do have permission to distribute the .jar file.
Comment 3 Atsushi Eno 2014-01-07 13:23:24 UTC
I have added support for new [Java.Interop.DoNotPackage ("your.jar")] attribute in Mono.Android.dll so that any jar can be excluded in the resulting classes.dex in the app apk.

This will effectively exclude any jar files that matches the same name (not only it excludes jars that have the identical names in different binding dlls, it also excludes the files that "ends with" the specified name; it is due to another bugfix to make filenames identical in one directory during the build).

I want to eliminate that limitation better later, but that needs another set of work and that will prevent quick solution, so I brought it in right now. So far this would mostly work.

[master 1f7a87d]
Comment 4 Akhilesh kumar 2014-01-15 06:23:16 UTC
We have tried to verify this issue. But we are not sure about steps.

Could you please provide some steps or sample application? So that we can verify this issue.
Comment 5 Atsushi Eno 2014-01-15 07:32:03 UTC
You cannot verify this normally. What I did to verify that is - 

- I built an app that uses binding project (particularly I used monodroid-samples/Facebook), added [DoNotPackage ("classes.jar")] (which is by the way already abnormal scenario, as there are many "classes.jar" files in several projects) in the binding project's AssemblyInfo.cs,
- then built an app using the binding project.
- In the app apk, there is "classes.dex" file. It is supposed to have all jars converted to dalvik bytecode. I then used "dex2jar" tool to convert this classes.dex back to a (reverse-engineered) .jar file. It should not contain facebook sdk classes.
Comment 6 Jonathan Pryor 2014-01-15 11:09:05 UTC
>  I then used "dex2jar" tool

You can instead use the `dexdump` Android SDK tool (`$ANDROID_SDK_PATH/build-tools/*/dexdump`), and look for the facebook types.
Comment 7 narayanp 2014-01-16 06:43:06 UTC
I can not check this issue with Facebook sample because this sample does not build successfully. There is a Issue Bug 16817 for this.
Comment 8 narayanp 2014-02-03 09:34:54 UTC
I am successfully able to build and deploy Android Facebook sample application on physical device as well as on emulator.
Comment 9 Atsushi Eno 2014-02-03 09:54:01 UTC
Well, it should deploy, but if it ran, it is WRONG. It should fail to launch due to missing dex classes.
Comment 10 PJ 2014-02-03 15:40:01 UTC
Re-setting this one to RESOLVED. 

Lal you'll need to follow the instructions in comment 5, not just verify the behavior of the sample. We talked a little bit about this case last week, let me know tonight if you want to discuss further.
Comment 11 narayanp 2014-02-06 06:42:52 UTC
I have checked this issue with following builds:

All Windows
X.S 4.2.3(build 54)
Mono 3.2.6
X.Android 4.12.0-22

I have followed comment#5 and followed some steps:

1. Added [DoNotPackage ("classes.jar")] in AssemblyInfo.cs file of facebook binding.
2. build the application.
3. Created .apk file and convert it to .zip file and open it.
4. Convert classes.dex file to classes.jar file
5. Convert classes.jar file to zip and open it.
6. It contains some folder but I am not sure is it having facebook sdk classes or not.

I am attaching this jar file please let me know is it having facebook sdk classes or not?
Comment 12 narayanp 2014-02-06 06:44:25 UTC
Created attachment 5986 [details]
classes.jar file
Comment 13 Atsushi Eno 2014-02-06 09:44:11 UTC
It is VALID! It only contains R and app classes i.e. it did not contain the facebook SDK classes (which are in classes.jar in the LibraryProjectZip in that project).

Thanks for the final verification!
Comment 14 narayanp 2014-02-07 04:06:13 UTC
As per comment#11 and comment#13 closing this issue