Develop Reference

Gradle configuration cache works on local machine but fails on GitHub Actions

In gradle.properties I'm setting
org.gradle.unsafe.configuration-cache=true
This works without errors on my local machine. The output is:
0 problems were found storing the configuration cache.
When I set up a job on GitHub Actions, it only succeeds if I deactivate the configuration cache.
When it is activated I get this log:
3 problems were found storing the configuration cache, 1 of which seems unique.
- Task `:app:buildKotlinToolingMetadata` of type `org.jetbrains.kotlin.gradle.tooling.BuildKotlinToolingMetadataTask$FromKotlinExtension`: invocation of 'Task.project' at execution time is unsupported.
See https://docs.gradle.org/7.4.2/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution
See the complete report at file:///home/runner/work/***/***/build/reports/configuration-cache/3lar58wlvtv9703t0m3olblg9/gwoz69d8l961obatzzelsv4d/configuration-cache-report.html
> Invocation of 'Task.project' by task ':app:buildKotlinToolingMetadata' at execution time is unsupported.
My primary interest is why this behaves differently.
I'm also wondering what the best workaround is.
(Can tasks be skipped from caching? Or how would you deactivate the configuration cache on the CI server?)

I haven't understood the cause yet.
My current workaround is to disable the configuration cache on CI builds adding the option --no-configuration-cache to all gradle commands e.g.
./gradlew test --no-configuration-cache
This overwrites the setting of gradle.properties.

Is it normal to have app:packageProductionDebug task taking 70% of build time?

I'm, currently trying to optimise my build time of an android application I'm developing. Currently it builds for about a minute and a half initial and about a minute for incremental build. I've tried all the recommendation from this page : https://developer.android.com/studio/build/optimize-your-build#optimize
We just managed to get rid of the annotation processors we previously used, but this does not decrease the initial or incremental build times , just gives us the opportunity to use Instant run - with which we previously had a lot of issues , ex. not hot swapping at all.
We made some profiling and found that more than half of the time is taken from the :app:packageProductionDebug task.
Here is a profiler sample of one of my incremental build :
total: 58s
:app:packageProductionDebug 38.933s
:app:transformDexArchiveWithDexMergerForProductionDebug 6.697s
:app:transformClassesWithDexBuilderForProductionDebug 3.833s
:app:compileProductionDebugJavaWithJavac 2.891s
:app:transformClassesWithFirebasePerformancePluginForProductionDebug 1.530s
:app:processProductionDebugResources 1.500s
:app:compileProductionDebugKotlin 1.478s
What is this task doing ? I imagine it is only packaging the previously compiled code into apk. If I'm not wrong, why this task takes 80% of the time ? Can I make something in order to improve this ?

So I found what was causing the package task to run so much time . I was having those properties in gradle.properties file
org.gradle.daemon=true
org.gradle.jvmargs=-Xms1024m -Xmx5000m -Xcheck:jni -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
After removing those properties the package task runs for a second and have overall incremental build time for about 15 seconds. I have no idea why those properties caused such a drastic decrease in the performance of the build , but I don't care, as far as I have 15 seconds build

Re-run failed android tests

Is there a way to run only the failed set of tests on Android using Gradle?
At the moment, I run my tests as follows.
./gradle connectedDebugAndroidTest
There are tests that occasionally fail due to environment issues which are difficult to control and what I would like to do is be able to only run those failed tests and merge the result with the previous test results.
So for example, if I have 100 tests and 90 succeed, I would like to re-run the failing 10 tests. If those 10 pass the second time around, I would like to merge those results with the original test run.
It looks like this has been discussed several times for Gradle but there doesn't seem to be a solution yet.
https://github.com/gradle/gradle/issues/4068
https://github.com/gradle/gradle/issues/4450
https://github.com/gradle/gradle/issues/1283
Thanks!

The reason they don't have a way to only rerun failed tests is because it screws up the way Gradle currently works. This happens because on the first run, Gradle knows 90 tests passed. If you update the code, and then rerun only the 10 failed tests (using this new option you want them to add), then Gradle would think that all the tests have passed. However, this isn't the case because the tests which previously passed might've broken from the update which fixed the failing tests.
Despite this, the problem has been solved. Gradle reruns failed tests first, and provides a --fail-fast flag for the test task. This effectively does what you want (i.e., only reruns failed tests).

If you want to automatically rerun failed tests as part of the same build in which they failed, and succeed the build if they succeed on retry, you can use the Test Retry Gradle plugin. This will rerun each failed test a certain number of times, with the option of failing the build if too many failures have occurred overall.
plugins {
id 'org.gradle.test-retry' version '1.2.0'
}
test {
retry {
maxRetries = 3
maxFailures = 20 // Optional attribute
}
}

How can I build AOSP (Marshmallow) efficiently?

When building Lollipop, I could compile my changes by running:
make clean-framework clean-services clean-services.core services.core services framework && make snod
However, this is not reliable for Marshmallow. Sometimes it works, and other times my changes will not be compiled. I have also seen this produce an unbootable build, forcing me to do a full make -j8, which takes almost an hour on my machine.
Am I missing a new build target? Any advice is greatly appreciated.
Thanks.

The reason my partial builds failed to boot was due to dex pre-optimization. When dexpreopt is enabled, you cannot recompile certain parts of the system image, since they are byte-aligned and optimized together at compile time. After disabling dexpreopt, and doing a make clobber && make -j6, I was able to do partial builds with no issues.
To disable dexpreopt, set the following variables in your terminal:
export WITH_DEXPREOPT=false
export DISABLE_DEXPREOPT=true
TIP: add the above to your build/envsetup.sh or your .bashrc so you don't have to remember each time.
TIP 2: There is also a DONT_DEXPREOPT_PREBUILTS, but I have never had a problem with that, so I leave it set to the default, which isfalse. If you set this variable to true, it will take an incredibly long time (easily over an hour) for the device to boot after your flash it, since it has to optimize everything first.

TeamCity : How to create a delay between build steps

I'm having an issue with TeamCity, building some Android APK's.
I have both a QA and Release APK's, each in it's own build step.
The problem is the Release build step never completes, as it seems to access a file that is still being used by the QA build step.
I have tried adding a Powershell build step between the two, using
Start-Sleep -Seconds 10
However, this doesn't seem top cause TeamCity to wait.
Does anybody know how to create a pause between build steps?
Thanks

I ran into the same problem. However, I needed a controlled/longer delay. I found Teamcity could be delayed using the old school ping delay method. Anyhow, I know you solved your problem, but figured others may benefit from this; this URL is #1 on my google search results.
REM Delay for 30 sec
ping -n 30 127.0.0.1 > nul

I resolved this using a while loop instead.
The problem was a shared file being used.
while ( test-path 'D:\Builds\File.txt') {
del 'D:\Builds\File.txt'
}

FWIW I'm on TeamCity 9.x and the original script that sleeps for 10 seconds as declared in the question seems to work for me in a trivial project with one PowerShell step.