Status Update
No update yet.
Comments
jb...@google.com
ap...@google.com
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 (
ty...@gmail.com
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.
Description
Version used: 1.7.0
Devices/Android versions reproduced on: API 33
If this is a bug in the library, we would appreciate if you could attach:
Example project attached
Description:
It appears that ComponentActivity$ReportFullyDrawnExecutorApi16Impl.this$0 leaks memory when used in an ActivityScenario if the ActivityScenario is used to recreate the Activity soon after the Activity has been launched.
Reproduction steps:
1. Create an Activity that extends ComponentActivity
2. Set a content view for the Activity in the onCreate using either setContentView(View) or setContent { <Composable> }
3. Create an instrumented test that uses LeakCanary's DetectLeaksAfterTestSuccess Test Rule
4. In the test: Launch the Activity using ActivityScenario, and then call "recreate" on the ActivityScenario
5a. Expected result: The test launches the Activity, recreates it, and the test passes.
5b. Actual result: The test launches the Activity, recreates it, and then LeakCanary detects a memory leak from ComponentActivity$ReportFullyDrawnExecutorApi16Impl.this$0 leaking an instance of the Activity.
This issue does not occur for ComponentActivity instance that do not set a content view in onCreate, and does not occur for regular android.app.Activity instances.
I have attached an example project with eight instrumented tests that show case this issue. In the ExampleInstrumentedTest.kt tests `launchExampleViewActivityAndRecreate` and `launchExampleComposeActivityAndRecreate` both fail, and all other tests succeed. The expected behaviour is that all tests should pass.