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
Related
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).
I am getting a warning in my console when I try building the app in Release configuration. The warning reads The ServiceSDK frameworks have not been prepared for release.
Please ensure the "prepare-framework" script is run after the "Embed Frameworks" build phase.
From the documentations, I understand that a build phase script has to be run to fix the issue.
Here is how I use the framework in my solution:
I am creating a binding library which refers the framework through a Native Reference. Then I run the library project and build a .dll with I use in the iOS project within my Xamarin forms application. All this is working fine. I am able to use the intended features from the framework.
However, there is this warning which appears in the console when I run the App in Release configuration. Also, when I tried submitting the App to App Store, it throws error, which is apparently the same mentioned above.
I tried by adding Custom commands which I think is the equivalent of Xcode build phase scripts, but the warning doesn't simply go away.
Any help would be really appreciated.
Sample Repos - https://github.com/XamarinUniversity/ENT302
Youtube Video Link - https://www.youtube.com/watch?v=HEypPXVoYnY&feature=youtu.be
Gudie Here - https://xamarinuniversity.github.io/ENT302/
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)
I'm in the process of updating our build process for Android to use gradle. We have client-specific apps - i.e. a single code template which is used as the basis for all the apps which are created dynamically.
To build the apps, I loop through a CSV file to get the details for each one. I then take a copy of the source template, inserting the client's name, images, etc. before compiling the app. This works fine in the current system. In the gradle version, I've got it successfully looping through the rows and creating the app source for each one with the right details. However when I try to actually build the app, it fails with the message:
Project with path ':xxxxxx' could not be found in root project 'android-gradle'.
From reading the documentation, I understand that this is because the project doesn't exist during the configuration phase as it's not created until the execution phase. However what I haven't been able to find is a way around this. Has anyone managed to achieve something similar? Or perhaps a suggestion for a better approach?
One option is to script settings.gradle. As in any other Gradle script, you have the full power of Groovy available. Later on you can no longer change which projects the build is composed of. Note that settings.gradle will be evaluated for each and every invocation of Gradle, so evaluation needs to be fast.
While Peter's answer pointed me in the right direction, it ended up not being a workable solution. Unfortunately with nearly 200 apps to build, creating a copy of the source for each one was too big an overhead and gradle kept running out of memory.
What I have done instead is to make use of the Android plugin's product flavors functionality. It was quite straight forward dynamically adding a productFlavor for each row in the CSV (and I can do that in build.gradle rather than settings.gradle), and I just set the srcDir to point to the relevant images etc for each one.
Overview
I'm using static libraries and Xcode 4 workspaces to effect modularity in iOS development, an increasingly common technique. For example, I might have a workspace which contains an App project, and a Library project, like so1:
You would then have a scheme to build these that looked something like this:
What I would like to do is have the "App build" control the "Library build" it initiates, in at least a couple of ways:
Map App configurations (e.g. Debug, AdHoc) to arbitrary Library configurations
Passing through some subset of -D defines, and/or specifying these for the library build.
I'll deal with each of these in their own section, but it's worth making a few clarifications.
Clarifications
I'm using App/Library here as an easy proxy for any Superproject/Subproject relationship you may have.
From what I've seen, Xcode 3 style embedded subprojects don't seem to work any differently in Xcode 4 than workspace "peers". I'd love to be wrong about this.
I know I could do almost anything with a "Run Build Script" build phase, and xcodebuild. But I'm trying to work within the system here, where the dependencies are specified in the scheme, and otherwise somewhat loosely coupled.
The Library exists to be used in more than just this project, and so you cannot arbitrarily load it up with junk specific to this App's build, or reference anything particular to the App or Workspace. For the general case, this rules out including static .xcconfig from the App project as a way to convey build information from the App to the Library.
Building the Library outside the workspace sacrifices too much, not an option.
Configuration Mapping
As I understand it, building a particular App configuration will:
If a configuration exists in the Library of the same name, it will build the Library using that.
Otherwise, it will build the active configuration of the Library, as specified in the Library's project file.
To my knowledge, without resorting to the aforementioned run-build-script hack, that is the extent of the control one has over subproject build configurations. Please tell me different.
Ideally, I would be able to specify (in the scheme, presumably):
AppConfigA -> LibConfig1
AppConfigB -> LibConfig2
While Debug, AdHoc, & Release may be the only configurations some ever use, complex projects often outgrow that.
Defines
I've not yet found way to pass -D defines from the App build to the Library, without resorting to xcodebuild, which can take, e.g., an .xcconfig file.
The App's build settings can be accessed in Library build run-build-script phase. However, doing that introduces a dependency in the Library on the App project, which for good reason is verboten (cf. Clarifications). But even then, I haven't found a way to use those settings to directly control the Library's build (much2).
So crazy it just might...
One scheme I came up with while writing this would be:
The Library bases it's build configurations on an empty (dummy) LibraryExternals.xcconfig file within it's own project.
A clean of Library deletes that file. A standalone build of the Library will create an empty one if it does not already exist.
That file is overwritten by an App Build run-build-script phase, and contains anything the app wants to communicate to the Library build.
Seems kind of complicated, but I'm looking for anything right now. I'll push this to an answer if nothing better comes along.
1 Apps shown are Max OS X. I find command line apps make for simpler tests. Same applies.
2 Cf. Info.plist preprocessing, which I learned about during this investigation.
If you modify your project structure to use a single project with multiple targets then each target's build settings will automatically inherit from the project. From there, you can modify ones that you want to be different, or select an individual setting and press the delete key to set it to the default specified by the project.