I am currently working on an Android app that is using a library that is using the NDK. The library and the app are maintained in separate repositories and are worked on as separate projects. The library is compiled on its own with Gradle and the ndk-build script. The aar output and .so files are then included in the main application.
My question is:
Is there a way to use ndk-gdb (or some alternative) to debug the library while running in the main app?
I have the source code for both projects, and if need be I could combine the projects for use with ndk-gdb, but this is very messy and requires a lot of additional work that would not be version controlled.
Related
Recently, I ported my existing Android project from an ancient Gradle version to Gradle 6.6 and Android Studio's Gradle plugin 4.0.1. This project uses an external native library (.so file) that gets used in the Java code via JNI. This .so library has a dependency on libc++_shared.so because it is written in C++.
I realized that if I just copy the .so file into the corresponding platform folder (arm64-v8a, armeabi-v7a, x86, x86_64) within the jniLibs Gradle packages it "properly" into my .apk file.
By "properly" I mean that it automatically adds libc++_shared.so, which my library has a dependency on, as well as my own library to the .apk file. In addition, if I additionally set jniDebuggable to true in the build.gradle file it will also add the gdbserver library which is required to be able to attach the native code debugger.
Now, this is exactly what I want. The problem is that I cannot find any documentation that describes this behavior. The best source I could find is this but it does not mention anything about dependencies being packaged automatically. So, I don't know whether that is an officially supported way of doing things.
I suspect that there is a part of Android's Gradle based build process that automatically analyzes the files in the jniLibs folder and acts accordingly. It would be great to know a bit more to be aware what is really going on.
Does anyone have a reference that confirms my above observations or know which Gradle task (or whatever) accomplishes this? It would also be good to know in which Android Gradle plugin version this behavior was introduced.
Edit:
This answer to another SO question led me to the Android source file https://android.googlesource.com/platform/tools/build/+/master/builder/src/main/java/com/android/builder/internal/packaging/Packager.java
which seems to be the code that packages the .so files and gdbserver into the .apk file. But I have no explanation why libc++_shared.so gets packaged as well.
I have two existing native libraries that I would like to integrate into an Android project. One has a working Android.mk file and the other has a working CMakeList.txt file. Is there a clean way to link both to Gradle?
Using CMake's ExternalProject[1] is the only idea I have at the moment.
[1] https://cmake.org/cmake/help/v3.0/module/ExternalProject.html
The solution that I arrived at was to add an additional Gradle module to build the ndk-build project. In Gradle terms the project would become a multi-project/multi-module build and is discussed further here [1]. I was also able to express the dependency in Gradle and the project built without issue.
My initial thought of using CMake's ExternalBuild failed under Gradle, but would build fine when invoking CMake from the command line. This probably had something to do with my lack of knowledge in Gradle and CMake.
[1] https://speakerdeck.com/bmuschko/state-of-the-art-gradle-multi-module-builds
I might have what you need. There is an all c++ sample that involves no JAVA UI which is actually a big thing because now your main (entry point) is in a c++ file - you can do OOP and depend on 3rd party libraries without much hassle.
Check out my repo: https://github.com/skanti/Android-Manual-Build-Command-Line
I work for a company which has a android mobile application developed by an offshore team. I have access to GitHub repositories.
I am piecing together the android app block by block and it is giving me hell.
How do I distinguish between module, libraries, jar, library projects, gradle projects, aar and jar. Can someone please give me a practical definition. NOT out of a freaking google search. I have Google too.
PS yes I am a noob and not proud of it.
I'm just giving a brief description about each of these. I hope I'm clear.
Module : A Module is an component of your application that can build / test independently and re use it in another application if required.
Libraries : AAR files, JAR files etc.
JAR : Java library
AAR : Just like JAR, only difference is that it also contains android specific files like resources etc.
Gradle Project : Gradle is just a build system which is used by Android Studio to build the android project. Its very much powerful as compared to the build system which was used in Eclipse earlier.
Library Project : An Android library project is similar to an Android app project in that it also includes a project manifest file in the project’s root directory. Also, this directory contains src, res, and other directories that you also find when building an app project.
However, there is a significant difference. You cannot compile a library project into an APK file because a library project doesn’t describe an app. Instead, it provides reusable code and resources that contribute to an app when the app’s project and source code refer to the library project. At build time, this code and these resources are merged into the app’s APK file.
To explain more on this, let me give you an example :
Say you want to use a networking library volley for making API calls, now since this is an open source library from Google you can clone it making customisations as per your requirement.
You can make volley library as your Library Project, build it independently, unit test, etc.
Now say you started building an application where you need to make HTTP calls so you need to add volley library to your project. You have two choices for that :
Compile your library project volley, generate the aar file and add it your app Project.
Add Volley as module in your project. (If you choose this option you can make changes to volley library in same studio project since it will act as a component in your project)
Please let me know if something is not clear.
1.) Module
A module is a collection of source files and build settings that allow you to divide your project into discrete units of functionality. Your project can have one or many modules and one module may use another module as a dependency. Each module can be independently built, tested, and debugged.
There are 4 type of module in Android Studio.
Phone & Table Module
Android Wear Module
Android TV Module
Glass Module
2.) Support Library
The Android Support Library offers a number of features that are not built into the framework. These libraries offer backward-compatible versions of new features, provide useful UI elements that are not included in the framework, and provide a range of utilities that apps can draw on.
Support libraries provide a range of different features:
Backward-compatible versions of framework components.
UI elements to implement the recommended Android layout patterns.
Support for different form factors.
Miscellaneous utility functions.
3.) Jar file
JarFile is used to read jar entries and their associated data from jar files.
for more detail visit this : https://developer.android.com/reference/java/util/jar/JarFile.html
4.) Android Library Project
The Android team introduced a new binary distribution format called Android ARchive(AAR). The .aar bundle is the binary distribution of an Android Library Project.
An AAR is similar to a JAR file, but it can contain resources as well as compiled byte-code. This allows that an AAR file is included in the build process of an Android application similar to a JAR file
5.) Gradle and Gradle Project
Gradle is an automated build toolkit that allows the way in which projects are built to be configured and managed through a set of build configuration files. This includes defining how a project is to be built, what dependencies need to be fulfilled for the project to build successfully and what the end result (or results) of the build process should be. The strength of Gradle lies in the flexibility that it provides to the developer. The Gradle system is a self-contained, command-line based environment that can be integrated into other environments through the use of plug-ins. In the case of Android Studio, Gradle integration is provided through the appropriately named Android Studio Plug-in.
for more detail visit this : http://www.techotopia.com/index.php/An_Overview_of_Gradle_in_Android_Studio
My desired end result is to have a Project that can output different productflavors of Mobile, Tv, and Wear apps, that share the same code-base. So I would like the codebase to be a dependency for all three app-types, where each app module would only contain activities and interaction with the codebase.
My first idea was to add a "Android Library Module" to my newly created project, but I noticed that this is really just a new app module with its own resources and everything. I would like the codebase to function more like a "Java Library", but it needs access to packages like "android.graphics.Color".
So in short, is the correct way of achieving this result to use a java library that has a reference to an android sdk or am i just going about this the wrong way?
Continuation of this question at:Does an Android Library need a manifest ,app_name,Icon?
There's no in-between. If you want access to Android APIs, then the library needs to be an Android library so that the build system can properly link it in to dependent projects. It's true that Android Libraries have resources and other things you may not need, but you can ignore those bits and treat it essentially as a plain Java library if you wish. Even if you're not using resources, you may find useful the ability to specify AndroidManifest.xml attributes to be merged into the dependent app.
The Android Library project doesn't build a fully-fledged APK as its output; it generates an AAR, which is conceptually similar to a JAR archive, but has resources and meta-information useful to Android projects.
Supplemental answer defining terms
The Android Studio documentation defines a module as follows:
A module is a collection of source files and build settings that allow
you to divide your project into discrete units of functionality. Your
project can have one or many modules and one module may use another
module as a dependency. Each module can be independently built,
tested, and debugged.
So basically a module is a subproject in your bigger project.
Types of modules
Android app module - The app module is usually what you are working with in a normal project. When you compile it you get an APK file that will run on a device. Here are the different types of app modules that exist:
Phone & Tablet Module
Android Wear Module
Android TV Module
Glass Module
Library module - The purpose of a library is to share code. For example, you could have a project with a couple different app modules. The common code that they both use could be located in the library.
Android Library - In addition to Java code, this allows you to also include Android resource files and a manifest. If you are making an Android project and are wondering what kind of library to use, then choose the Android Library. When compiled it creates an AAR (Android Archive) file.
Java Library - This only allows you to include Java code files, no Android resource files. This is useful for cross-platform code sharing. When compiled it creates a JAR (Java Archive) file.
Google Cloud module - This type of module is the Google Cloud backend for communication with your client side app.
One additional point that I've not seen well documented: An android library module can have a dependency on another android library module or java library module, but a java library module cannot have a dependency on an android library module.
According to this SDK guide, unit-testing a Library project can be achieved by creating a standard application project, reference the Library project and then instrument the application for unit testing.
However, when I do this and launch the test application I get the message
No tests found with test runner 'JUnit 3'.
I'm using Eclipse and the Android ADT plugin, all latest versions.
Note: the projects compile just fine. The test project also installs fine to the emulator. But in the console I can see that it looks for <library>.apk, which of course doesn't exist since I'm compiling this as a library into the test project.
Anyone got this to work? And if so, what is the trickery here?
Update: after discovering and fixing a problem, which was actually including the test classes (!), the test runner now can find all tests. But, all the tests fail with the following exceptions:
java.lang.NoClassDefFoundError: <nameOfClassInLibraryProject>
nameOfClassInLibraryProject are classes defined in the library project. These classes should be compiled into the test project, and indeed, everything compiles just fine. But when running the test project, the runtime doesn't seem to find the library classes.
After much fiddling and wasted time in Eclipse I have managed to get Android Library projects to work.
According to the Working with Library Projects article:
Instead, you must compile the library indirectly, by referencing the library from a dependent application's build path, then building that application.
The problem was that I interpreted this to mean that the library project should be added to the Projects tab in Java Build Path. Doing this makes the test project compile since the library code is obviously available to the compiler. But since the library is not compiled into a .jar or .apk in itself, the library classes are never deployed to the device.
The solution is to not add the library project to Projects, rather on the Source tab, add the library /src folder using the Link Source... button. And yes, it is the library src folder, not the library project root, that must be linked into the test project.