Status Update
Comments
ho...@gmail.com <ho...@gmail.com> #2
We are currently using AGP internal task types to flag memory-intensive tasks to enforce a reduced parallelism at execution time. I've raised this separately (with a lot more detail) as a feature request (
av...@gmail.com <av...@gmail.com> #4
Another use case that we have is to reactively respond to the creation of APKs and AABs. The new AGP APIs allow us to connect out tasks into the artifact pipeline via wiredWith
but the best we can come up with to receive the completed artifact is to wire in toTransform
. This A) does not guarantee that we will receive the final artifact as more transforms may be applied after our task is called, and B) requires us to copy the input property file/dir to our tasks output property file/dir in order to not break the build cache.
The reactive behavior of the above is the complicating factor.
A non-reactive approach could simply depend upon the task name and then look for a hardcoded path in the build directory (which is still sort of gross, since the build output paths are not documented as public API and change from time to time).
Another approach would be to wire a custom task to consume the output of the build via the built artifacts loader feeding an input property. However, this approach cannot be applied reactively. Either the custom task is included in the build and causes the creation of the binary artifact, or it is not included in the build and never gets invoked.
al...@android.com <al...@android.com>
ya...@google.com <ya...@google.com> #6
We didn't provide a task wiring helper for that case as there's only one thing to wire, but I can see how the inconsistency can be misleading
av...@gmail.com <av...@gmail.com> #7
WRT variant.artifacts.get(SingleArtifact.APK))
, if the task is included in the build it will cause the creation of the artifact. Our build is currently defined to reactively perform some actions (predominantly some fancy reporting) only if work is actually performed.
We had previously been pushing our build to wire in to task outputs by locating tasks by type and referencing output properties as inputs to tasks registered via task finalizes
or dependsOn
relationships. This started getting more and more fragile as the AGP APIs migration proceeded/matured. I'm to the point now where I think the notion of reactive execution is hostile to the direction/expectations of both Gradle and AGP and want to start moving away from it, yet our build as it currently stands does rely on this behavior.
I bring up this up as a gap only because I don't know if I'll be able to completely refactor our CI pipeline's expectations in time for Gradle 8+.
ya...@google.com <ya...@google.com>
lb...@gmail.com <lb...@gmail.com> #8
av...@gmail.com <av...@gmail.com> #9
Another minor functionality gap: We have a build that has test coverage enabled during test execution but then we manually disable the coverage report generation for all project modules as we have a custom coverage report task that creates an aggregate test coverage report for the entire project. This saves us the execution time, I/O, and protects us from Jacoco implementation instabilities.
We're currently using the following to accomplish this:
project.tasks.withType(JacocoReportTask::class.java) {
enabled = false
}
lb...@gmail.com <lb...@gmail.com> #10
Another gap, though my perhaps there's a better way to express this? Some of our builds leverage Flank to run instrumentation tests on Firebase Test Lab. These builds run as a single CI stage so as to afford Gradle the best opportunity to parallelize work. In this context, we have found that prioritizing instrumentation test assembly work early in the build allows the tests to dispatch to FTL earlier, minimizing overall build times. To implement this, we have chosen to be explicit on the inverse side by pushing lint and local unit test execution to be shouldRunAfter
the flank tasks which in turn depend on the instrumentation test assembly, etc.
Specifically:
private fun bumpFlankTask(project: Project, flankTasks: TaskCollection<FlankExecutionTask>) {
listOf(AndroidLintTask::class.java, AndroidLintAnalysisTask::class.java, AndroidUnitTest::class.java)
.forEach {
project.tasks.withType(it).configureEach {
shouldRunAfter(flankTasks)
}
}
}
This seems fairly specific to our project's desires and not necessarily transferable to other projects. I think our best option for the future Gradle 9+ might be to fallback to leveraging task names rather than leveraging task types in a generic fashion. Mentioning it here in case there is a better approach/option once the types are no longer available.
Description
Version used:
compileSdkVersion 23
buildToolsVersion "24.0.0 rc1"
compile 'com.android.support:appcompat-v7:24.0.0-alpha1'
compile 'com.android.support:design:24.0.0-alpha1'
Theme used:
default
Devices/Android versions reproduced on:
Nexus 5 with Android 6.0.1
- Relevant code to trigger the issue.
1. import from here:
and then update the support&design libraries as I've written at the top.
Alternatively, use the project from this post:
2. try to set the initial state of the mBottomSheetBehavior, using :
mBottomSheetBehavior.setState(BottomSheetBehavior.STATE_HIDDEN)
The bug:
it shows this error, no matter if you call it in "onCreate", "onStart", and "onResume" :
03-10 12:54:51.899 23652-23652/android.com.bottomsheets E/AndroidRuntime: FATAL EXCEPTION: main
Process: android.com.bottomsheets, PID: 23652
java.lang.RuntimeException: Unable to resume activity {android.com.bottomsheets/android.com.bottomsheets.MainActivity}: java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.Object java.lang.ref.WeakReference.get()' on a null object reference
at android.app.ActivityThread.performResumeActivity(ActivityThread.java:3224)
at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3257)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2479)
at android.app.ActivityThread.access$800(ActivityThread.java:144)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1359)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:155)
at android.app.ActivityThread.main(ActivityThread.java:5696)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1028)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:823)
Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.Object java.lang.ref.WeakReference.get()' on a null object reference
at android.support.design.widget.BottomSheetBehavior.setState(BottomSheetBehavior.java:440)
at android.com.bottomsheets.MainActivity.onResume(MainActivity.java:103)
at android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1331)
at android.app.Activity.performResume(Activity.java:6044)
at android.app.ActivityThread.performResumeActivity(ActivityThread.java:3207)
at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3257)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2479)
at android.app.ActivityThread.access$800(ActivityThread.java:144)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1359)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:155)
at android.app.ActivityThread.main(ActivityThread.java:5696)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1028)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:823)