Fixed
Status Update
No update yet.
Comments
jb...@google.com
ap...@google.com
I don't think #1 makes a lot of sense. There are already potentially libraries out there without that metadata.
#2 makes the most sense to me, but in case we cannot be 100% reliable we should allow blacklisting libraries as described in #3. This should probably be handled globally for a project (in gradle.properpies rather than in the DSL)
#2 makes the most sense to me, but in case we cannot be 100% reliable we should allow blacklisting libraries as described in #3. This should probably be handled globally for a project (in gradle.properpies rather than in the DSL)
pr...@google.com
As I have mentioned I don't think there is a silver bullet. #2 does not work on 100% and #1 will take time before devs will provide the metadata. #3 is in my opinion very important to introduce asap, as the developers have no way how to workaround it at this stage. Also in the future there can be any other issue and there is nothing wrong in doing #3 until we figure out something robust (or for instance finally migrate work manager and navigation to androidx that would make #2 a feasible solution).
ty...@gmail.com
Yes, I'm working on #3 right now to unblock users. We can continue thinking about #2.
dr...@gmail.com
lb...@gmail.com
Starting with AGP 3.3.0-rc01 and 3.4.0-alpha04, to blacklist libraries that should not be jetified, users can add a comma-separated list of regular expressions to the following property in the gradle.properties file:
android.jetifier.blacklist = ...
If a library's absolute path contains a substring that matches one of the regular expressions, the library won't be jetified.
For example, if the property is
android.jetifier.blacklist = doNot.*\\.jar, foo
then "/path/to/doNotJetify.jar" won't be jetified.
Change-Id: I6531fe0faafa45dc2811c5223ba199ccce5fee53
Note that this is only a temporary workaround while we work on a proper solution.
android.jetifier.blacklist = ...
If a library's absolute path contains a substring that matches one of the regular expressions, the library won't be jetified.
For example, if the property is
android.jetifier.blacklist = doNot.*\\.jar, foo
then "/path/to/doNotJetify.jar" won't be jetified.
Change-Id: I6531fe0faafa45dc2811c5223ba199ccce5fee53
Note that this is only a temporary workaround while we work on a proper solution.
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.