I have an android system app that is currently being built with the android build system. The SDK in use is system_current as it uses some system apis.
For external dependency reasons, ease of development, debugging etc, it would be nice to move this app to Android Studio and use Gradle to build.
Converting the sources to build with Gradle is straight forward enough. However, at build time, the system APIs are not found as those are not available in the normal SDK. I thought that by generating the SDK from the AOSP sources I'd get an SDK I could use, but that target output seems to also not have the System APIs available.
How would I change my gradle build to be able to use the System SDK to compile against?
There are two ways depending if you are only trying to use current non-public APIs, or of you've added custom ones yourselves and are trying to access those.
If you're only trying to use current system-level APIs, you can use android.jar from this repository https://github.com/anggrayudi/android-hidden-api
If you have added some new method that isn't part of standard AOSP, then it's a but more work.
The reason that all methods don't show as part of Android SDK is that in AOSP code they are annotated with #hide. This means that when SDK is generated, they are exlcuded.
You'll need to remove that annotation for the methods that you want to use. Then you'l need
Run make update-api to update the public API of the project.
Make the Android SDK from code by following: https://android.googlesource.com/platform/sdk/+/master/docs/howto_build_SDK.txt
Change the Android SDK path in Android Studio to use the custom one you build.
There's also the possibility of accessing methods via reflection on runtime without SDK generation. It's slower and messier to code though.
Not sure I understand exactly what you mean by normal SDK etc.
From https://developer.android.com/studio/build
The key part is to have a
apply plugin: 'com.android.library'
...
android {
...
}
If on the other hand you wanted to build with a desktop JDK but compile against java APIs you could add a dependency on robolectric and you can get a jar you can import into another Android project.
implementation "org.robolectric:android-all:11-robolectric-6757853"
Android Studio isn't really designed to work with System APIs. Even if you make Gradle build your platform app, you will also need to sign it with the same certificate as your AOSP build (so that you could run it). As you noticed, if you decide to use Roboelectric you would also need to modify it yourself to match your current AOSP version (System APIs are not as stable as Public APIs and Roboelectric needs to constantly chase all the changes).
I would suggest to keep using the AOSP build system but optimize our workflow.
Ease of development
Doing a full build/flash for every change in your component must be a pain. But if you are just modifying a single app, you can get away with just building that single component:
~/aosp/ $ m -j -- do a full build first
flash a clean image (with your platform certificate)
~/aosp/path/to/your/app/ $ mma -j -- build your app with all dependencies after you made changes
$ adb root && adb remount && adb sync
Basically, adb sync works great if you don't touch any APIs or parts of Android Framework (which would cause a rebuild of thousands other objects). If you see adb sync updating more than handful of files, you'll likely end up with a bad system and need to do a full flash.
Debugging
While Android Studio is a to-go solution for regular apps, framework and the platform apps go with InteliJ (you can probably use Android Studio, but there won't be much of use of Android plugins on top InteliJ) plus some configuration (see idegen.sh - example).
Related
I have been following this tutorial: https://medium.com/better-programming/create-swift-5-static-library-f1c7a1be3e45
However, it is inconvenient to copy the new .a file every time I make a change to the library. What is the common setup during development of the static library? Do a "copy to iOS project folder" in the build script or linking the frameworks "Products" folder in the iOS project etc.?
During development, Subprojects seem to be a really useful way (https://www.raywenderlich.com/2658-creating-a-static-library-in-ios-tutorial). However, copying the project to another computer renders it useless as it seems to rely on the Subproject and not e.g. cache the data from the last build.
The background is that I want to work with a client that I don't want to give access to my private API.
I am looking for a solution that lets me
work on the project as well as the library conveniently (either by submodules or by having opened 2 Xcode windows at the time)
commit changes to the Git repo (via the Xcode Source Control) and automatically have the compiled framework being pushed, too
have my be able client to use my Project and work on the Project but only has access to the compiled library so he can't see what's inside it
I need to build a javafx aplication to a .exe file, to be used in 3 differents enviroments.
Now, before I build the application to each different enviroment I am changing every variable manualy, like urls, versions and tokens. I know that is a matter of time until I upload the wrong version to the wrong enviroment, so I really need a more automatic process to manage each version.
I read something about maven build profiles but i do not find a way to integrate this in the building of the exe file
This javaFx app is using maven and java10
To build the java code to an exe, I'm using Intellij
Thank you in advance
The big problem is that java 10 is end of lifetime (EOL), so you should already work with java 11, this however is a little more complicated since JavaFx/OpenJfx is now separated. (see https://openjfx.io/)
Anyway to solve your complex needs you should think about a CI platform like as example gitlab CI.
This platforms (with the help of Docker Images) give you the tools you need to properly build and configure complex javaFX build targets and configurations.
But you have to build the .exe file on your own with tools like exe4j if you choose this path.
Side Tips:
In my experience is a lot more easy to build java 11 applications
with gradle instend of just maven since you gain a lot more
flexiblity to solve complex problems
If you stay on java 10 it would be much easier since Java11 + Openjfx
11 required OS dependend builds. (but as I sayed it is EOL)
We have a mobile game for iOS and Android that works fine, one of our plugins is Firebase plugin (Analytics + Realtime database)
Now we want to export the game also to standalone mode (PC windows), and we want to disable the Firebase plugin completly when building to windows.
Of course we put #if everywhere needed, but still, the dlls are compiled into the project.
Is there an easy way to remove it during the standalone build?
I tried to import HelloAndroid project in Android Studio, but, when i try to build the apk and run it on a device, i get a gradle error:
Does anyone know how to solve this and run the app?
Original author of the build.gradle script here. As you can probably tell, our gradle build is pretty messy. It consists of three steps:
Build the Halide generators using gradle's native "cpp" plugin. That is, they're just regular C++ programs.
Run each Halide generator with per-architecture arguments to generate a set of .so files in the appropriate jni/libs/ directory.
Shell out to the ndk-build script to compile Android.mk, which links the JNI portion of the app with the Halide-generated .so files.
The process is brittle, especially with both Gradle and the Android platform changing under us. I've been waiting for the platform to stabilize with the new Gradle Component Model that is still "incubating" as well as the New Android Build System and New Experimental Plugin.
In the meantime, everything should still build if you use Android Studio 1.5 and Gradle 1.2.2 (1.2.3 will probably work, but IIRC 1.2.4 is broken).
I have a set of apps which are basically white labels of one app. The basic app has a web backend. With ant, when I ran the debug build of a white label app, the library project was compiled as debug with dev_server parameters and when I compiled a release build, the live_server parameters were used. Other parameters (and resources) were overridden by the white label app and it all worked pretty well.
So basically, if I compiled a white label for app 1 and debug build, the app was compiled for <dev_server>/1 as the basic service address and so on.
With gradle, I've tried different strategies but can't get it to work quite as conveniently without setting each parameter in each app's build.gradle.
The basic problem seems to be that a library project with gradle always builds in release so I can really change backend parameters based on what build I'm using.
Any ideas how to set up the project structure to make it work that way?
Instead of library project, try going for the productFlavour concept as mentioned here http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Product-flavors