Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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.
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.
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.
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.
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.
> 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.
I can not check this issue with Facebook sample because this sample does not build successfully. There is a Issue Bug 16817 for this.
I am successfully able to build and deploy Android Facebook sample application on physical device as well as on emulator.
Well, it should deploy, but if it ran, it is WRONG. It should fail to launch due to missing dex classes.
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.
I have checked this issue with following builds:
X.S 4.2.3(build 54)
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?
Created attachment 5986 [details]
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!
As per comment#11 and comment#13 closing this issue