During my profile report of assembleDebug gradle task I discovered two realm related gradle sub-tasks which takes quite big amount of time:
assembleDebug - 1m21.44s
- transformClassesWithRealmOptionalAPITransformerForDebug - 22.386s
- transformClassesWithRealmTransformerForIdeDebug - 10.062s
Questions:
what exactly those realm related gradle sub tasks do? Can I skip them at some point?
why they took so long? (22 + 10 = 32 sec)
Update
As a workaround I am skipping task via -x script parameter
assembleDebug -x transformClassesWithRealmOptionalAPITransformerForDebug
transformClassesWithRealmOptionalAPITransformerForDebug is created for removing RxJava related APIs since it might create troubles for some cases (cases which need reflection like https://realm.io/docs/java/latest/#jackson-databind) which doesn't have the RxJava dependency. But we found it doesn't play well in some occasions like https://github.com/realm/realm-java/issues/3033 and https://github.com/realm/realm-java/issues/3022 . So it will be disabled in the next release after v1.0.1.
transformClassesWithRealmTransformerForIdeDebug is the core part Realm relies on. Basically it replace the field access to the RealmObject with Realm accessors by bytecode manipulating. You can see this post for a bit more details. Thus, this task cannot be skipped.
PS. an issue is created to track the transformer speed improvement.
Related
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.
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
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
}
}
Whick gradle task is the fastest to check whether the code passes compilation without any syntax error on Android project
Based on the output of the command
./gradlew tasks --all
executed in a directory containing a small Android project, I'd suggest that your best bet is either the command
./gradlew compileReleaseSources
or the command
./gradlew compileReleaseJava
Here's the full list of tasks that compileReleaseSources depends on for my project (might vary slightly for your own):
app:compileReleaseSources
app:checkReleaseManifest
app:compileReleaseAidl
app:compileReleaseJava
app:compileReleaseNdk
app:compileReleaseRenderscript
app:generateReleaseAssets
app:generateReleaseBuildConfig
app:generateReleaseResValues
app:generateReleaseResources
app:generateReleaseSources
app:mergeReleaseAssets
app:mergeReleaseResources
app:preBuild
app:preDebugBuild
app:preReleaseBuild
app:prepareComAndroidSupportAppcompatV72210Library - Prepare com.android.support:appcompat-v7:22.1.0
app:prepareComAndroidSupportSupportV42210Library - Prepare com.android.support:support-v4:22.1.0
app:prepareReleaseDependencies
app:processReleaseManifest
app:processReleaseResources
Note that this includes the Java compilation step, as well as the compilation of other code sources and various resource processing. Depending on your exact needs, calling compileReleaseJava instead of compileReleaseSources may be enough and will be faster. (Unfortunately, I don't know of a way to view Gradle task dependencies in a tree-like structure, so it's not clear to me exactly how much faster the compileReleaseJava task would be).
If you also want to check that test code compiles, you'd need to add an analogous command: e.g. compileDebugTestSources.
I am not sure if it is Android Studio ( 0.1.9 ) or AndroidAnnotation problem, however, lately I cannot make and compile my AndroidAnnotations projects.
Ok, so I try to make project and this is what I got in "Messages" window:
Information:Round 1:
Information: input files: {com.antyzero.sidereelo.ui.activity.SplashActivity}
Information: annotations: [com.googlecode.androidannotations.annotations.EActivity, java.lang.Override]
Information: last round: false
Information:Processor com.googlecode.androidannotations.AndroidAnnotationProcessor matches [com.googlecode.androidannotations.annotations.EActivity] and returns true.
Information:Note: Starting AndroidAnnotations annotation processing
Information:Round 2:
Information: input files: {com.antyzero.sidereelo.ui.activity.SplashActivity_}
Information: annotations: [java.lang.Override]
Information:Processor com.googlecode.androidannotations.AndroidAnnotationProcessor matches [] and returns true.
Information:Round 3:
Information: input files: {}
Information: annotations: []
Information: last round: true
Information:Compilation completed successfully with 1 warning in 17 sec
Information:0 errors
Information:1 warning
Warning:: Unclosed files for the types '[dummy1372862415557]'; these types will not undergo annotation processing
Nothing less, nothing more. In result I don't have my SplashActivity_ created. This message is from brand new project but my old projects are also affected.
Answer from Android Studio: Use AndroidAnnotations is not helpful.
I was working with AA and IntelliJ weeks before Android Studio without problem. IMO it might happen after latest Android Studio update, but maybe there is some kind of solution for this right now, if not I will report this to Android Studio team. Thanks for help.
One more thing. My projects are using Maven and building them from CLI works fine, all classes are generated as they should be.
I was facing the same problem when trying to inject a view with #ViewById, and the problem was that I was declaring the field private. Declaring it at least protected fixed the issue!
Before:
#ViewById
private NoListResultsView noResultsView;
After
#ViewById
protected NoListResultsView noResultsView;