Develop Reference

Android Gradle Build not using all my M1 Pro CPU cores

Is there any way how I can setup my Android gradle project to be build using all (more) cores of my CPU?
I have MBP M1 Pro and as you can see on attached image bewow when performing Rebuild Project it is not using all my cores in the same way.
My M1 Pro has 10 CPU cores and 2 of them are low performance and 8 performance. I would like to AS use all 8 performance cores to build my project.
There is my gradle.properties setup:
org.gradle.caching=true
android.useAndroidX=true
android.enableR8.fullMode=true
org.gradle.parallel=true
org.gradle.daemon=true
org.gradle.configureondemand=true
I was little bit playing also with org.gradle.workers.max and org.gradle.parallel.threads but I didn't see any change in CPU usage at all. But maybe I just misunderstood how it works and set incorrect values.

Rebuild Project stands for many Gradle tasks and a few IDE jobs like file indexing, I think your screenshot was captured in the middle stage, thus I consider the factor that impacts CPU loads balance is Gradle.
However, Gradle can not guarantee full usage of your CPU due to some restrictions:
--parallel is used for tasks from different modules to run in parallel, the effect depends on "Decoupled Projects" prerequisite, you may want to check the project states / dependencies.
worker is used to separate a task into several sub "works", AGP adopted it since 4.x and used it aggressively(divide tasks into tiny works), if the project has quite a lot of modules(let say >50) and resources, 8 cores maybe even slower than 4 cores due to too many workers(eg. a work can be finished in 0.1ms, but Lock Contention wastes more time). Using the latest AGP may resolve the problem, you can check the AGP version and try to reduce core numbers.
This is a thread usage screenshot scanning an open-source project tivi build process by build scan, it shows the first few frames for parallelly running tasks, it's slightly better than yours I guess, but eventually CPU cores are not fully occupied. You can analyze the build using the same tool.

How to prevent Jenkins to trigger nightly build if there was no changes since last nightly, but there were CI builds triggered by Gerrit?

we have
current build environment setup:
Android project consist of hundreds and hundreds repos.
for code review process using Gerrit
build server Jenkins
one build plan which is triggered by two ways:
CI build type: Gerrit Trigger when there was a patchset created
NIGHTLY build type: by a timer (every night)
one shell script which handles both scenarios based on whether $GERRIT* variables were set or not. The other difference what that script does, for NIGHTLY we do make clean.
So, the build results can be seen like this:
Not entirely sure what was the original motivation to do it in this way, but
benefits could be:
less disk space, need only 1 Jenkin's workspace
maybe initial faster building time
in one view can see the status of CI and NIGHTLY builds
However the disadvantages are:
Cannot conditional build NIGHTLY (and by timer) when there was not difference between previous NIGHTLY and the current one (I'm able to do that in the shell script to retrieve last/true NIGHTLY repo manifest, but that's already when the Jenkins triggered the build...so have already a void record, as I'm exiting at this stage my script). Because what will tell the difference over the hundreds of Android repositories is the .repo/manifest.xml file left on the disk from the last (most probably CI, based on Gerrit changeset) build and the current nightly.
also not always correct info about changes between builds (both types)
Where I got to so far?
learned about Run Condition Plugin, but haven't figure out how to pass to it the last/true NIGHTLY build repo/manifest.xml and the same with the current manifest before I start building it (calling repo forall -c 'git checkout origin/otira_development')
Usage of Jenkins CLI plugin to trigger a Jenkins build from there. So far the closest and I think achievable. But still I feel - why I need Jenkins at all if the whole logic I need resides in external scripts.
someone point me to this question about how to get changes since the last build. However I don't have any idea how to implement it in Jenkins.
Anyone has any experience of building Android project(s) using Jenkins and Gerrit? What is your solution? How to achieve have NIGHTLY triggered if there was true change on the master (ignore CI Gerrit builds). Also see the true changes between builds (especially NIGHTLY, as they get affected by this implementation).
Ideal to me seems to have two separate build plans using two separate workspaces, however I'm limited with the disk space, so cannot afford this.
If that helps, here's our build script.

Appcelerator titanium build takes about 2 minutes

Hi titanium team / Experts,
I'm using Titanium and I look for a way to make my app build faster so it won't take so long to test it every time. Even when I run it twice without adding anything, it takes about 2 minutes to build and 15 more seconds to install on my device.
I think the key is in "Forcing rebuild: JavaScript files need to be re-encrypted". Is there a way to avoid this rebuilding?
The development is being done under mac machine

Rebuilding application can, depending on your mac specs, take 2 minutes indeed. A much faster way of developing is using LiveView or TiShadow (if you're using open source tools). Both methods don't need re-compiling but will only recompile files that need recompiling.
Be aware both methods do not fully clean the app when restarted/rebuilding, things like event listeners, collections and models can cause issues. So every now and then an actual restart is required, and sometimes bugs can appear that only appear during liveview development. But mostly, especially for UI improvements these methods greatly increase development speed.

There are a few ways to speed up your builds. Some of which is described here: https://wiki.appcelerator.org/pages/viewpage.action?pageId=29002843
However I also discuss some other methods.
TiShadow
Consider using TiShadow. It can simultaneously live deploy and test across multiple real devices using any OS for development. I've used it for some time, and it's AMAZING! Don't understand how anyone uses Titanium without it
Use ccache
The Android NDK r7, required by V8 and Titanium Mobile 1.8+, can use ccache, a tool for reusing cached C/C++ compilations. We get huge improvements in build time with it.
Install HomeBrew if you don't have it installed already
Install ccache with the following command: brew install ccache
Set an environment variable NDK_CCACHE to point to it. Installed with HomeBrew, the command would be: export NDK_CCACHE=/usr/local/bin/ccache
Parallelize Compiling
The NDK can also parallelize while compiling, which can speed up the process.
Determine how many cores your machine has. You can use this command on Mac OSX: system_profiler | grep -i "Number Of Cores"
Multiply the above number by 2. So if the above command returned Number of Cores: 2, then your value should be 4.
Set an environment variable NUM_CPUS equal to the above value. In this case: export NUM_CPUS=4
Don't Build the Docs on Every Compile
Skip building the JSCA files (the files used by Titanium Studio's code assist feature). You don't need them if you're just making a build for yourself for testing. To skip, run scons like this:
scons build_jsca=0
Live View
Live view reduces the need to recompile as is decribed here: https://wiki.appcelerator.org/display/guides2/LiveView
Speed Up Emulator
Although this doesn't really speed up your build time, speeding up your emulator helps speed up run-time a lot. Some methods are described here: https://gist.github.com/adam-lynch/7247983
GenyMotion is also a much faster emulator I have been told. Haven't tried it myself.

Different Way for making Gradle Faster

I have been working on android from some time. Since starting i have searching ways of make the grade efficient and fast. i went through many post and i find many solution. which i am listing here.
After building first time switch to offline mode.
make parallel exception check in grade compiler option.
use Dexoption to increase the heap size.
I am looking for if is any other thing which can help reducing the gradle time.
A. what are the other option which can be used in gradle to make is efficient and fast. ( i am looking for both gradle normal and experimental plugin - as dexoption are not available in experimental plugin)?
B. Is there any drawback of the instant run on the build time introduced in studio 2.0?
C. Which is the gradle plugin version best for android 2.0?
D. Any other thing which we can implement in code or in script to decrease the build time and run time?

If you have:
Android Studio 2.0+
Gradle 2.0+
minSDK API 15 (Android 4.0) declaration in your app
your device is API21+
then you should be able to use Android Instant Run feature.
As described here app are building almost instantly in most cases. There are 3 running modes available: hot swap, warm swap and cold swap.
Building speed depends of code change scope.

Android Studio / Gradle Build questions

I'm slowly starting to port my existing apps to Android Studio and Gradle. I have a few questions about it though before I get too far.
Is it possible to build a signed apk outside of Android Studio, from a command line, like you can with ant.
Is it possible to build a signed apk for every variant all in one go, again outside of the UI.
Finally, this is a situation that won't affect many people, but is there a limit on the number of variants you can realistically have. I am probably looking at having between 2000-4000 separate variants. Is this going to be a complete no go?

yes
yes
hmm that's quite a lot. I think there are going to be issues. For instance right now Gradle doesn't let us parallelise the compilation of the variants, so it's going to take forever to build. Also, you might run out of RAM when setting up the internal model that represent all the variants and their associated properties and tasks.
I guess you should just try it and see. Using simple groovy code you should be able to dynamically create 2000 flavors in an empty projects and then see if you can compile without problem.