Multiple Native Modules in Android Studio - android

I have a C++ codebase that is currently set up in Visual Studio (to run on Windows), with multiple Projects with inter-dependencies. I'm trying to bring it over to Android Studio, to get it running on Android.
I'm familiar with Visual Studio and C++, but quite new to Android Studio's Gradle and CMake.
My (possibly wrong) expectation is to try and treat Android Studio Projects like Visual Studio Solutions, and Android Studio Modules like Visual Studio Projects. Given that my codebase uses multiple Projects in Visual Studio, I am trying to create multiple Modules in Android Studio -- each one with their own build.gradle and CMakeLists.txt files.
The issue is that I cannot get one section of code (AS Module) to link with the other. I am compiling these different sections as STATIC using add_library() (I plan to have one Module that creates a SHARED library, to load into Java).
I can easily get the includes to work via include_directories("../OtherModule/src/"). However, I cannot get it to link. I cannot find the .so (or similar) file to link to (via target_link_libraries() or equivalent). When I extract the .arr file from a given Module, I do not see any .so or anything.
I realize that I could simply put the entire codebase under one Module (using one build.gradle and one CMakeLists.txt -- or network of CMakeLists.txt's using add_subdirectory()). I don't know if this is fine, or if it would take more/less time to build.
I'm sure that there could be multiple ways to set this up, and it could just be a matter of preference. All research that I've done thus far has only found strictly adding native code to the same module with Java code -- doing basic JNI native bridge stuff. I haven't been able to find a single article about multiple native Modules linking together.
I'm hoping that someone with more experience with native development on Android could help me out. Thanks!
TL;DR: Simplified scenario: (Without being concerned with the JNI native bridge) I have two Modules in Android Studio, both with only native code. I would like to have each Module have its own build.gradle and CMakeLists.txt, creating its own STATIC libraries. One Module depends on the other and must set the correct include and link directories. How do?! Is this even correct (or should there ever be only one Module with native code)?

I asked a related question here. It seems to me that AS...
...does not actually link the final module-library unless it's SHARED (it does allow static 'sub-libraries' within the module); consider making the final library shared - you will have to System.loadLibrary() it specifically in Java though.
...does not allow you to install files to other places (e.g., from your native module to your Android app). I work around this by fetching the library through set_target_properties( jniwrapper PROPERTIES IMPORTED_LOCATION ${CMAKE_CURRENT_SOURCE_DIR}/../libnative/build/intermediates/cmake/${BUILD_TYPE}/obj/${ANDROID_ABI}/libnative.so ) and setting BUILD_TYPE in build.gradle. Not overly elegant though.
Overall, this does not seem to be an encouraged use-case in AS...

Related

Where does a native *.so library and its headers go in an android project?

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.

Use one "updatable" library in different Android Studio projects [duplicate]

I have started working on a project where I will need to share a bunch of Java classes across a bunch of apps. In Eclipse it was possible to create one project with all such classes and use it as a library in a workspace with all your dependent projects, but in Android Studio it doesn't seem possible to do so (At least not easily).
I have been reading a bunch of posts and a lot of them suggest setting up a library project, generating an aar file and then using that in my projects. But, as I understand it, this will make my library open-source (Am I right?), which I don't want. I am doing this for a client and I want the code base to be private.
Also, I know that a module can be imported into a new project. But this creates a COPY of the original module. This is not what I want at all. I don't wanna maintain multiple copies of the same classes, which completely defeats the purpose of 'code sharing'.
Is there any good way of achieving what I am looking for? Any help is appreciated.
You have a couple different options.
One option is to maintain your libraries as separate projects and compile them to an archive format, such as JAR or AAR; JAR files are for pure Java libraries, and AAR is for Android libraries (which contain code that accesses Android APIs and/or has Android resources). As was pointed out in the comments, AAR doesn't force you to publish your code to the world any more than JAR files would; it's just an archive file format whose files can be local to your machine or your organization.
With that archive file in hand, you can include it in other projects. If you're part of a multi-developer organization, you may find it convenient to use a repository manager to publish and maintain those libraries within your organization, and you can use Maven coordinate-style specs to include libraries in your projects, which you don't have to manually copy over to your development machine.
The disadvantage of this approach is that it makes it a little harder to make changes to those libraries: you need to load up the project, make changes, build an archive, and distribute the archive.
The other approach is to keep the library as a source module like you did in Eclipse. You observed that Android Studio will make a copy of the module if you import it via UI, but if you bypass the UI and modify the build scripts directly, you can do what you want, which is to use the module in-place and share a single copy among multiple projects. To do this, work in your settings.gradle file and add this:
include ':module_name'
project(':module_name').projectDir = new File(settingsDir, '../relative/path/to/module')
I would strongly encourage you to not use a pure relative path here; in this example, the path is anchored to the settingsDir variable supplied by Gradle, which is defined to be the directory where settings.gradle is found. If you use a pure relative path (i.e isn't anchored to anything), you're dependent on the working directory being the same in all environments where the build file is run (command line vs. Android Studio vs. CI server), which isn't a good thing to assume.
You need to think in the eclipse projects as Android Studio/IntelliJ Idea modules. Then, you can generate android (or java) libraries and then include them in your project.
To mark an Android Studio module as a library you can go to File -> Project Structure -> Facets and there click on Library Module
I was in same situation as you, and i founded an approach using git.
Steps to do, to have library:
Create project in Android Studio.
Create android library module in that project.
In that library module create git repository.
Add modulename.iml in .gitignore file
Use GitHub or Bitbucket for private cloud repository. and push your library to it.
Create new android library model in any project that you want.
Close Android Studio (not sure is that mandatory).
Using explorer go to your created module folder.
Remove all data in it, except modulename.iml.
Clone your library from "GitHub" into it.
That's all.
Now you are able to use library in multiple project whether you are at home or at work. Just after finishing you work not forget to push library changes. And after opening new one pull them.
I think you can automate this thing somehow.
The benefit is that you don't need to build any jar, or aar.
You can certainly create and use a library without making it open source or available to others.
First, you don't need to make it an aar unless it contains Resources.
If it's just plain classes, you can just make it a .jar file.
Either way, the easiest way to share these libraries (either aar or jar) is to set up your own repository. Nexus and Artifactory are the two most common repository managers.
You keep the library in its own project, and then publish it to your own, in-house repository.
Then, projects that need to use the library are configured (in gradle) to use the in-house repository, and get the library from it.

What are Pros and Cons of using Library project(In Eclipse)in my existing Android project?

I am working on a Android app in which I would like to add plug and play module functionality ,Say I have Two android project
[A] An app for capturing a image using camera and storing it in memory
[B]Enabling map and locate current location .
now I want to add add this functionality in my Another Android app.While going through android developer link and Android Library Projects - Tutorial I figure out that to use plug and play module I have to make my above project as library project so that I can use it in my new app ,now my questions are
1 Is this only way to use library project to add plug and play module
functionally in my app or there are another way also?
2 what are the pros and cons of using library project in order to add
plug and play module functionally?
basically I am researching on how to add plug and play service in my android app and trying to find best solution ,so any clarity on this topic will be extremaly helpful !!!
thanks in advance !!!
An alternative would be to use a linked source folder. In Eclipse, you can set this up in the project settings in the Java Build Path section. You can choose some source code directory outside your project that will virtually be in your project's space (and other projects that use it will do the same). I find this to be handy just from an IDE UI standpoint when I'm co-developing a module along with an app or two. What I don't like about library projects is that they sometimes don't update correctly within your project so you have to rebuild it and your project or clean your project to continue. Also, the module is simpler because it's just a directory of source code files, not an entire Eclipse project.
One other downside of libraries is that they can introduce conflicts that can be a headache to fight. For example, your library might have a different version of the Android compatibility library in it than your main project, and therefore give you compile time errors. Or there are sometimes errors with duplicate libraries, and you have to go fool with the Order and Export settings of your project.
If your module is going to rely on String, layout, and image resources, etc. that are common to all apps that implement the module, then a library project will be easier to work with so you don't have to pass all your resources in through your module's class constructors and duplicate them in each project.
A third option is Gradle, although as far as I know, that would essentially just help automate one of the above two options. I'm not very familiar with Gradle.

Sharing Java library with Android Apps

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.

How to create multiple Android apps from one code base

I have an Android code base which uses APIs with settings to get different data for several apps. All apps use the same code base but with one or two design tweaks. So how do I re-use the main code base without having to copy the whole Android project each time?
iPhone uses multiple targets in the same project which works well. If android cant do this do I need to compile binaries of the code base in one project and then import into each new app project? If so how? I'm using Eclipse and am an intermediate Java developer.
Any help much appreciated!
Doug
Check out "Working With Library Projects" from the Android documentation. This should be just what you're looking for: http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject
The current way to approach this issue if you are using Android Studio with Gradle is by using Gradle, Build Type + Product Flavor
http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants
Build Variants
One goal of the new build system is to enable creating different versions of the same application.
There are two main use cases:
Different versions of the same application
For instance, a free/demo version vs the “pro” paid application.
Same application packaged differently for multi-apk in Google Play Store.
This new concept is designed to help when the differences are very minimum. If the answer to “Is this the same application?” is yes, then this is probably the way to go over Library Projects.
Note: This answer is basically obsolete now that one can create .aar libraries with resources. It still works, though, and there may be times when the portability of a .jar is desirable, so I'm leaving it here.
Blumer's answer is a good one, and you should definitely look into Android's idea of library projects. However, there is another alternative. If you have a module that contains only Java code, but no resources of any kind (images, layouts, etc.), you can compile it to a .jar file separately and use the resulting .jar in multiple application projects. It works like this:
Create a new Java project in Eclipse (not an Android project) and move the source code of your module there.
If your module references any classes from the SDK, you'll need to add the Android SDK .jar to the project's classpath (Project > Properties > Java Build Path > Libraries > Add JAR).
When your module is ready to use, bundle up its .class files into a .jar. You can do this manually, or you can look around to figure out how to get Eclipse to do it for you.
Copy your module .jar file into the "libs" directory of your app's main project.
Add the module .jar to the project's classpath (again, Project > Properties > Java Build Path > Libraries > Add JAR).
Now you should be able to build multiple apps using the same .jar, while maintaining only one copy of the module's source code.
Depending on your particular situation, this may or may not work any better for you than the standard Android library mechanism. But it's worth considering as an alternative.
The Android documentation recommends another approach if there aren't too many "different APIs" used.
The idea is to use reflection instead of making direction references to the code. Make sure to use optimized reflection instead of lookups every time.
References
http://developer.android.com/training/multiple-apks/api.html
http://developer.android.com/google/play/publishing/multiple-apks.html#ApiLevelOptions
You might want to consider using a source control system like Subversion (or GIT). Keep your most feature complete version in the trunk, and make branches for your separate versions that use different data sources or require minor layout changes, etc.

Categories

Resources