I am relatively new to Cocos2d-x and I am trying to build a project targeting iOS & Android devices. Building the Cpp project with Xcode (for iOS) is pretty fast but for Android you have to first compile the whole project with NDK which always recompiles the whole cocos2d framework and this takes up to 2 minutes for every single change I'd like to test on a device.
Can I somehow configure my build_native.sh or Android.mk file to use the compiled cocos2d framework and just compile my files in the Classes folder? I am working with version cocos2d-2.1beta3-x-2.1.0
Put this settings in Eclipse-> Project->Properties -> C/C++ Build
Uncheck the Use default build command
Build Command: bash ${workspace_loc:/XYZProjName}/build_native.sh NDK_DEBUG=1 V=1
Makefile generation should be disabled....
Build directory: ${workspace_loc:/XYZProjName}
Now just Build Project it will recompile your projects file only ...Whenever you clean and build it rebuilds the cocos2d-x framwork also
which happens to be same in Xcode as far as my knowledge says ...
Whenever you change something in cocos2d-x classes then you neeed to do that clean (which means you are recompiling libgame.so) again which happens to be in the folder proj.android/obj/local/armeabi/ .... here at the location all your library which you are supposed to be using gets compile ..when you clean these all libraries get recompile ..
Hope you understand the concept ..If not ..Feel free to ask I will try to explain more ..
Related
I have a Java Library project in my AOSP build which creates a jar file and hosts it in system/framework
Everything works as expected, however I now wish to create a JAR file from the same library to allow and application to link and compile against it. Goal is to be able to create APKs against this lib (compileOnly) so that the APK can run and use the library on the ROM.
The problem is that Jack seems to be generating only dexed jar files which cannot be used in Android Studio as libraries.
Is there a way to disable DEXing in the Android.mk ?
I know there is an option in Android.bp (cannot recall it) which gives the option for the build to generate normal jar (with .class files).
Note: I cannot use BUILD_DROIDDOC with stubs due to enviroment issues (custom ROM) assuming BUILD_DROIDDOC is only executed with lunch sdk-eng
This is for a custom ROM with Android 8.1 base. I think the custom option of not dexing in Android.dp file is not supported in this version anyway.
For a project, I am using Android gradle scripts with CMake, gradle plugin is version 3:0:0, CMake version 3.6. Both gradle and CMake files are pretty simple and uninteresting (just defining the files used - I can still copy-paste them as required).
I have the following project structure; basically a codebase producing a few tens of .so files (the native part for the Android packages that get packaged into an apk, thereby called 'Executables'), which all depend on the same shared library code (static libraries, thereby called 'Libraries'). The Library code is still (relatively) volatile, so I wish the Executables to have project-level dependencies on them, so that whenever the Executables are built, the Libraries are rebuilt on-demand every time their code is changed.
The structure looks like:
+ LibProjects/
---Bin/ (Originally empty)
---Lib1/CMakeLists.txt (+sources files, same level as the CMakeLists.txt)
...
---Lib10/CMakeLists.txt (same)
+ Executables/
---Executable1/CMakeLists.txt (source files here)
--------------/AndroidFiles/build.gradle (and other android project files)(points to the CMakeLists.txt)
...
---Executable40/CMakeLists.txt
The Libraries' CMakeLists redirect their output into the Bin folder using
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY {CMAKE_CURRENT_SOURCE_DIR}/../Bin/${ANDROID_ABI}/${LibraryName})
The executable's projects add dependencies on the libraries "as normal"
add_subdirectory(${PROJECTS_ROOT}/LibProjects/${LibraryName} ${PROJECTS_ROOT}/Framework/Bin/Android/${ANDROID_ABI}/${LibraryName})...
Everything almost works, in the sense that I can get sensible executables and the Executables trigger builds of the libraries.
The problem is that when building the executables sequentially, each one does NOT reuse the library project outputs of the other ones: When I build Executable1, it will build all libraries (normal) and then it will build itself. Afterwards, when I build Executable2, it will NOT reuse the libraries that were already built for Executable1, and so on - this effectively increases my build time by a factor of ~10.
I can find the output of the build of each library inside the /Bin folder as expected, but they are not reused across executables - there are no CMake "project files" (is this the correct term) in the bin folder, all of them get generated inside the executable build directory.
The problem I am trying to resolve is the build times stemming from the fact that each library gets rebuilt for each executable.
At the moment the solutions I am considering is to somehow instruct CMake to use the Bin folder (or another folder) as a working folder for each library in its own folder instead of with the executable, hoping that the gradle android plugin will be smart enough to then spot that neither the cmakefiles nor the object files need to be regenerated, and avoid the rebuild.
The restriction that I have is that I cannot restructure the codebase itself, and that each Executable must be buildable separately of the others - there is absolutely no possibility of a top-level CMake - each Executable should be able to be triggered on its own.
CMake can guess if the build is up-to-date by reading informations froms the current build directory.
When you run CMake manualy in Executables/<x> directory, cmake retrieve information from the build directory associated to Executable/<x> directory. It then check if the timestamp of the built file correspond to the last build performed in this build directory. If not, it rebuild. What happen is that: Lib1 library file is built after you build Executable1, then you run cmake in Executalbe2, it compares the timestamp of Lib1 target file, see that this file was not produced by this instance of the cmake build and then rebuild the lib. And so on.
So you have two options:
1- Either you build the library and install their target files in the bindirectory (using install cmake command and make install bash command for exemple). Then in the Executalbe<x>/CMakeLists you use find_library command instead of add_subdirectory.
2- Or you create a super project which has the following structure:
+ supper_project
---CMakeLists.txt #add_subdirectory(LibProjects/lib<x>)... add_subdirectory(Executables/Executalbe<x>)...
+ LibProjects/
---Bin/ (Originally empty)
---Lib1/CMakeLists.txt (+sources files, same level as the CMakeLists.txt)
...
---Lib10/CMakeLists.txt (same)
+ Executables/
---Executable1/CMakeLists.txt (source files here)
--------------/AndroidFiles/build.gradle (and other android project files)
(not any more:points to the CMakeLists.txt)
...
---Executable40/CMakeLists.txt
I managed to work around this problem - but in the end it was by working around rather than with CMake.
I removed the CMakeFile-level dependencies (add_subdirectory) and only left the libraries at the linking level (target_link_libraries Executable [the library files])
Afterwards, I created gradle scripts for each library and added dependencies to these scripts in each application gradle script, so that the building of the libraries gets triggered by gradle dependencies instead of CMake dependencies. It's slower than it would be if gradle could be avoided, but much faster than rebuilding every time, and the overhead is at least constant (a few seconds per project).
I think problem lies in the way you have defined your dependencies.
For each executable you are creating separate targets using add_subdirectory.
e.g. for executable 1 you have add_subdirectory(${PROJECTS_ROOT}/LibProjects/${Library1}) and for executable 2 also you have add_subdirectory(${PROJECTS_ROOT}/LibProjects/${Library1}), so cmake will create two separate targets for same library1 in each of the executable's subdirectory and thus it will create separate timestamp and cache files. That is why it looks that it is building the same library for multiple times, but in fact for cmake they are different targets.
To fix this you can include all libraries in top level CMakeLists.txt using add_subdirectory and them in each executable's CMakeLists.txt add the dependency using add_dependencies command.
I've installed Visual Studio 2017 with Cross Platform Development kit and have managed to compile SDL2 as a dynamic shared library following this steps:
https://trederia.blogspot.hr/2017/03/building-sdl2-for-android-with-visual.html
When deployed on Visual Studio Android Emulator the application runs correctly.
Using the same steps, I also compiled Box2D library. I then added the paths, to the SDL2 application from above and added Box2D in libraries array in SDLActiviy.java and linked the project with libBox2D.so.
But when run on emulator it says this:
https://imgur.com/a/LsI21
I can also see from the compile that Box2D lib is not linked and is not in the libs folder of *.apk file
Anyone knows what I'm missing here?
P.S. I compiled everything with ARM architecture.
After a lot of trial and error.
Add new project to the original SDL2_Project solution and select Dynamic Shared Library.
Add all the *.cpp files in the Box2D library and compile.
Open SDL2_Application.java and add "Box2D" in the library list.
Right Click on the references in the SDL2_Application and click Box2D checkbox. This will add Box2D library to the final APK packet and will include the compiled lib in the /lib folder of the APK.
I am trying to build a JAR file that I can import and use it for other android projects.
I created Android project that contains java code (src/main.java) and it calls bunch of native code I wrote (Using System.loadLibrary(...))
Under jni folder, I have bunch of C/C++ codes, for instance jni/sample/sample.cpp.
My question is that when I export this project to JAR, can I build native library at the same time?
In other words, do I need to have pre-built .so file before exporting to JAR file?
My goal is when I export or something like that, it will do:
Build C/C++ code and create .so files --> Build .java ---> JAR
at once.
If you are using Eclipse, you can create a "Launch Group" in your debug/run configurations. That way you can include your Java build and an Android Native Application build in one configuration.
If you are looking to move to a more sophisticated build system, you should look into Maven. It is considerably more complex than the plain old debug/run configurations, but it is much more powerful. It includes an apklib packaging to build libraries for Android. There are a few quirks with using the NDK in an apklib, but reasonable project design can avoid most problems.
I created a test project to understand how to build and run the tests using command line tool. I managed to create a project, updated it with
android update project -p .
and debug with
ant debug
When I added a library project to this test project, the ant debug started to fail because it couldn't find the build.xml of the library. The only solution I found atm is to update the library project as well (found here). Is this the correct way? I see pom.xml files in many of the libraries that I use. I know it is used by Maven (although I know nothing about it) and it might help me with another solution.
Ant is the official way to build android apk. Maven is an alternative way of doing it (not officially supported, but it works very well).
There are few differences regarding default project layout when working with maven or ant, but it's possible to have both build system working on the same source code if you do some additionnal configuration work (i.e. some information will be duplicated).
Default project layout with maven
java source files are under `/src/main/java``
dependencies are defined in the pom.xml (using the maven way of defining dependencies, with type apklib for android libraries)
Default project layout with ant (and eclipse ADT plugin)
java source files are under /src
dependencies are defined in /project.properties and are specified using relative path.
Here is an example of project.properties (it's a typical example of a library project referencing 2 other library project):
target=android-15
android.library=true
android.library.reference.1=../somelib
android.library.reference.2=../someOtherLib
(as you can see some additionnal information are stored in this file : the android target and the fact that the project is an library or an app. When you use maven, this information is in the pom.xml)
How to build a maven android lib with ant ?
The problems (when you need to build a maven-layout-android-library with ant) are the following:
having a proper /build.xml (it can be done through android update library-project ... here is the official doc about this command)
having a proper /project.properties (it is partially done by the android update ... command, but you may need to add some android.library.reference by hand or with eclipse ADT plugin)
telling ant that the java source files aren't at the default location, but are under /src/main/java
For this last point, here is how to do it:
create a file /ant.properties (in your maven-layout-android-library)
put the following entry in it:
source.dir=src/main/java
(Important : it is not always required because sometimes the java source files are already under /src in the maven-layout-project and in this case, the pom.xml contains the information that the source dir is /src)
And that's all. Now, your maven-layout-android-library can be build with ant debug