Novell's LDAP library is included as part of the Mono project, but it isn't available when building MonoDroid projects because the base libraries don't match (so it's not offered as a library Reference option).
So I complied it directly from the Mono source as an Android library, but I can't get the resources to be included because they are in resx files and making that work in Mono seems really hit-and-miss. Without the resources, the error messages don't work.
I know it's possible because #jonathanpeppers has achieved it in these binaries, but they have this bug, which I would like to fix and recompile.
If you go back in the history for the project, you can see the source file used to be included directly in. https://github.com/xamarin/prebuilt-apps/commit/0f8784ebc272f72d9398897b4e54eef8965af7a9
Most libraries can easily be recompiled from source!
Related
I have looked at Use prebuilt JNI library in Android Studio 3.1 and How to use .so in a second project in Android?. The first is trying to get a library file without headers working and the other seems to be focusing on a specific issue with his build (although there's some useful information there). I'm relatively new to app development and especially to native development on android. I've gotten a build with the JNI library and some c++ code working, but that seems to be just for building from source.
It's probably a simple answer, but I haven't been able to find documentation on this specifically in the android developers documentation. I'm interested in understanding the correct (or most conventional) place to put and way to use a precompiled library (module/lib/*.so and module/include/*.h) in an android project. Would I even need to use JNI or the NDK if the library is built with another build tool? Another project I have has a native library source object (*.so) in ./obj/local, ./libs, and in many other folders related to JNI. I'm guessing it would be somewhere in there, but I'd like to know what is conventional.
For some context, I'm trying to work with the essentia library. I have followed the guide on compiling for Android and have a build with the general hierarchy mentioned above (essentia/lib and essentia/include) that seems to be working.
I'd like to create small Excel worksheet from an android application using Mono for Android.
I tried using both EPPlus and ExcelLibrary .NET libraries, however I'm having trouble building the project:
C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(2,2): Error: Exception while loading assemblies: System.IO.FileNotFoundException: Could not load assembly 'System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Perhaps it doesn't exist in the Mono for Android profile?
Is there any fix for that or other way to manipulate Excel files through Mono for Android ?
Thanks.
It looks like you are trying to reference a pre-built .NET 4.0 assembly into your Mono for Android project. You can't reliably do this (sometimes it works if you get lucky). MonoTouch and Mono for Android do not have a System.Drawing assembly, so you can't use libraries that link to it.
What you'll need to do is create a new project for the EPPlus or ExcelLibrary libraries and use the Mono for Android Library Project type. You'll probably also need to make some modifications to the project such that it doesn't use the parts of System.Drawing that Mono for Android don't have (it has a few bits and pieces like System.Drawing.RectangleF and SizeF, but is missing most of it).
I was going to work on doing this for MonoTouch using the npoi project (which has a more agreeable license than EPPlus), but have been too busy with other things.
I've got a fork of npoi that I'm working on cleaning up the API here: https://github.com/jstedfast/npoi/tree/enumification
Once I finish that and get that merged upstream, my plan is to create a new branch where I will be working on porting the library to the subset of .NET that MonoTouch and Mono4Android use. I'll probably call it "mobile" or something.
In the meantime, the quick and dirt fix is to just create a new Mono for Android Library project, add all the source files to it in the same way that npoi has, and then try building. It will fail, but the errors will give you a good starting point for figuring out which parts of the library to rip out mercilessly. Keep doing that until it compiles.
If you use either of the npoi repositories that I linked to above, I've already done some of the work to make font.metrics and some other resource file I can't think of build properly for MonoTouch/Android, so there will be a little less work to do than if you use a release like 1.2.5.
I'm just getting started in Android development, and use Netbeans with NBAndroid and SDK 17.
I'd like to use the same Java source code in my Java and Android app.
http://developer.android.com/guide/developing/projects/projects-eclipse.html says how to do it in Eclipse (although it is sketchy on the .JAR connection thing), but I can't seem to make it work in NB.
Based on that link, My understanding is that the correct setup for the Android app is an Android Application project which references an Android Library project which in turn references a .JAR library produced by a Java Library project. I could then also have a Java Application project referring to the same Java Library project.
So, I've set up this project structure... I have an AndroidApp project which is a basic HelloAndroid Activity in a com.ex package. This project includes an AndroidLib library project in the Libraries folder. I also have a LibClass.java file which defines a simple LibClass class which has one function getText() that just returns a String to be displayed. The MainActivity in the AndroidApp calls this to get the String to output.
When I put LibClass.java directly into the AndroidLib project, everything is fine.
But what I want to do is to share the source code with Java.
So I want to move the LibClass.java into the JavaLib library, whose .JAR file is included in the AndroidLib project. However, when I tried that, I get an error in the MainActivity class, complaining it can't find LibClass. Looking at the Projects window, I can see LibClass.class inside the com.ex package in the JavaLib.jar in the Libraries folder of the AndroidLib project. And AndroidLib is visible in the Libraries folder of the AndroidApp project, but it doesn't show any packages or other contents there.
So I feel like I'm just one step away from making this work. Do I need to do something with one or other of the AndroidManifest files perhaps? Or do something with the build.xml files? Or am I on the wrong track altogether?
I'd be really grateful if someone could post a how-to for this.
I'm trying something similar; I've got Java EE projects, built using Eclipse, and I'm trying to utilize some of that code from my Android projects. This should give me a shared codebase rather than a bunch of confusing SVN externals which I've had to endure before.
Rather than creating JAR files I've found that working with the source and building for the platform works best (well, it has been working but I've got a problem with it at the moment). So, what I'm doing is:
c:\MySvnFolderStructure\MyJavaProjectFolder\src\ (and then all the source under that)
c:\MySvnFolderStructure\MyJavaProjectFolder\android\ (and all the Eclipse Android project gubbins)
c:\MySvnFolderStructure\MyJavaProjectFolder\jee\ (and all the Eclipse JEE project gubbins)
The Android and Java EE projects do not have their own src folders, they both link to the src folder in their parent folder. What this means is that each of the Java implementations is building its own byte code version from the source, and using its own external libraries (like the Apache HTTP ones, for example).
Naturally they can't share stuff like awt (as mentioned in another post), but there's plenty of stuff that does cross-over especially if it's core Java classes that are being used.
Also, it's proving a bit tricky writing JUnit tests as there needs to be some duplication of the test code at the moment because the Android ones need extra instrumentation, but I'm working on it.
Also, see this post about relative paths in Eclipse, which means the folders can be checked-out to different places on different machines (like we all do with our version control check-outs) and still be shared.
if I understand your situation correct, you are trying to use a custom java library for both your android and java applications.
For this scenario, you can build the java library first. Instead of adding the java library jar as android library, you can drop the jar directly inside the libs folder of android project and add it to android project's build path.
If you are using ANT scripts for building the java library jar , you can consider adding the source files also as part of jar. This will help you get code assistance when you develop the android part. But this part is purely optional.
The problem is that the Java platform in Android is different from the JDK platform.
In particular, the .JAR library CANNOT refer to anything that is not icluded in the Android platform. An example of things you can't refer to is java.awt.* (except you can have java.awt.fonts).
There is also a difference between JDK String and Android String -- Android does not implement the isEmpty() method.
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 have a project that I would like to add external libraries to (and have them packaged with the application) but I am not sure it is happening. I read on this link:
https://developer.android.com/guide/appendix/faq/commontasks.html
how to, but they do not show up in any of the /data/data/project directories. Does anyone know how I can confirm that the libraries were in fact added to the project for use at runtime? Thanks.
If you include jars as External Jars under your project's Java Build Path, then the classes will be converted to Dalvik format and be made available in your project's classes.dex file, packaged into the .apk.
To confirm they are available, attempt to use something from the jar (Eclipse should suggest the relevant import when you first supply a class name) build and run the app and see if it works? If it works in development (e.g. from 'run' in Eclipse) then it will also work when the app is built in release and distributed as an APK.
You can also place jar under one of your source folders (perhaps creating special "libs" one) and adding it to build path.
Be warned - external libraries (which are compiled against some version or other of the libraries in a Java JDK) may sometimes have problems when running under android. This is because the Dalvik runtime has its own Java framework libraries, which provide most (but not all) of the Java APIs in the standard JDK Java framework libraries.
You should really recompile any external library against the android libraries so that you can see any missing APIs at compile time - and fix the issues there and then. Otherwise you run the risk of runtime errors under Dalvik when you call the external library from your Android app. See http://geekswithblogs.net/cyberycon/archive/2011/05/17/using-external-libraries-with-android.aspx
for more details.