I am currently working on a wearOS app written in Kotlin that needs to consume a native library.
I have cloned the library from github and built it. The output consists of a libs folder with 4 different subfolders containing .so files for the different ABIs and a java folder with two java classes to interact with the library.
I have been reading the android docs but I still can't figure out how I need to import these files in my project to actually use the library. I don't have a lot of experience in android development, could anybody explain to me wat to do or just point me to the right docs/integration guide?
Related
The Android app I am working on is completely written in C++. I need to integrate it with a static library that also is written in C++. There is no dependency on STL in any of the projects.
The static library uses cmake to build. Unfortunately, the app is based on an old AOSP version of Android NDK and has no support for cmake.
I also have a newer version of Android NDK in a different directory. This version does support cmake toolchains.
I am thinking I will build the static library against the new NDK and use it in my main project. The ABI is the same for both the projects - armv7a.
I have tested this logic with a sample code. It seems to work. I am able to invoke methods in the static library from my main app.
Also, there are no name-mangling issues.
The question I have is if there is any issue I am overlooking.
I am thinking it should not matter that the compilers used to build the sources are different. As long as they are producing arm-compatible code, I should be able to able to integrate them.
As a matter of fact, another library that I am using, gstreamer, is available for download as pre-built binaries at https://gstreamer.freedesktop.org/data/pkg/android.
Please advice.
For those interested, mixing NDKs doesn't seem to be an issue as long as you follow certain guidelines. Some of them are listed at https://developer.android.com/ndk/guides/cpp-support.
Essentially, there is no problem if your project is 'C' based. However, if you are using C++, you must not use STL.
I have managed to build part of my code with two NDKs and I am not seeing any link time or runtime errors.
After a hiatus of a couple of years I'm picking up Android development again.
I installed the newest Android Studio(4.1.1) with the latest Android SDK version (Android 11, API 30). After that I created a new project with gdx-setup.
If I add the old java source to my newly generated project I get this error:
error: package com.badlogic.gdx.backends.android does not exist
I'm not sure how to add this jar into the new project. In the Gradle configuration I see mentions of the backend, but it's not available.
I also downloaded the 'gdx-backend-android.jar' from the nightly build and put the jar in the Android library folder, all to no avail.
Does anyone actually know how to correctly add this dependency into my project?
I added the jar but still have an error, don't mind the other errors, I first need to fix the GDX import.
The project dependencies are managed by Gradle, so there is no need for you to directly touch any .jar files at all.
The most likely issue you're facing is that you are trying to use Android-specific classes from the core module, which is platform agnostic.
In a typical libGDX project, you do almost all your game code in the core module so it can easily be compiled for any platform. The code you showed above would be in the android module, but your LiveWallpaperStarter class would be part of core.
Some might say there's no reason to use core at all if you're making a Live Wallpaper, since it can't run on any other platforms besides Android. But there is some advantage in keeping the rendering in core so you can test in a desktop game window, because you can more rapidly compile and run on the desktop. This library has some tools that make it easy to wrap your rendering code in a class that lets you simulate a live wallpaper on desktop, for testing.
I have read a question/answer which states Flutter Web is a fork of Flutter and so one Android Studio (or VScode) project can't be built to handle both.
I'm not an expert on either (obviously) but I don't understand why the fact the libraries are forked implicitly precludes one from using the same source code for the different destinations.
Has anyone done so? And, if so, is there a skeletal project anyone would care to share?
I've found out that over a course of several years, a lot of programs keep seemingly duplicate "project folders" in the Android Studio, why is that?
To elaborate a bit further, if you import their projects, and if you take a look at there folder structure, there is going to be something like this:
Java
|--com.myproject.spaceInvader
|--com.myproject.spaceInvader(test)
|--com.myproject.spaceInvader(alphaTest)
What are these? Something generated by 3rd party testing tools?
When you create a project in Android Studio, it has a standard structure:
From official documentation:
main
Contains the "main" sourceset files: the Android code and
resources shared by all build variants (files for other build variants
reside in sibling directories, such as src/debug/ for the debug build
type). AndroidManifest.xml Describes the nature of the application and
each of its components. For more information, see the
AndroidManifest.xml documentation. java/ Contains Java code sources.
test
Contains code for local tests that run on your host JVM.
androidTest
Contains code for instrumentation tests that run on an
Android device. For more information, see the Android Test
documentation.
I created a haxe project using openfl. I can build and run the project on my own desktop using lime test windows.
Now how do I actually ship this project to other users?
I tried simply zipping the binary output created by running the command above. When I then unpack this zip on a different computer and start the executable file it will complain that I'm missing certain .dll files (more specifically the libstdc++-6.dll file).
Although this is not a direct answer to your question, a solution to this issue would be to compile through another software/tool, such as FlashDevelop.
For a few versions already, FlashDevelop includes an App manager feature that allows you to easily install the latest versions of Haxe, Lime & OpenFl (in an all-in-one package), and compile for all the Haxe/Lime/OpenFl targets seamlessly by just switching a value in a drop-down menu.
This allowed me to compile without any problems native C++ or Neko versions of my projects, thus embedding all the necessary files that could be zipped and sent to other computers.