Status Update
Comments
ma...@google.com <ma...@google.com>
as...@google.com <as...@google.com> #2
Tentatively, the annotation should be something use-case-specific like @OutlinedNewApi
that allows alternative build systems (e.g. not R8/D8) to make their own decisions. We'll provide a default Proguard configuration for R8, but it's not guaranteed this will work as intended -- outlining is automatic in newer versions, but it may be disabled.
br...@monzo.com <br...@monzo.com> #3
Just as an FYI, this was enabled in AGP 2 years ago (AGP 7.3 as far as I remember), ag/18426192, so for AGP users it might fine to just remove the rule for @DoNotInline
. I like the @OutlinedNewApi
to make it clear what this is for other consumers to handle it as they see fit.
as...@google.com <as...@google.com> #4
Given the failure mode can include run-time crashes, that's not an acceptable level of usage.
br...@monzo.com <br...@monzo.com> #5
I think you can still include a top-level proguard.txt
, and it will be used by versions that do not support the com.android.tools
format. E.g.
br...@monzo.com <br...@monzo.com> #7
Looping in from offline, any new libraries require a high enough compileSdk
that we're going to see a recent-enough AGP. So, we should just remove our manual outlining and use of @DoNotInline
.
na...@google.com <na...@google.com> #8
Branch: androidx-main
commit 0c5446468c1e1fc08b1cea04dc57b05c52417ce8
Author: Alan Viverette <alanv@google.com>
Date: Tue Jul 02 13:50:59 2024
Disable class verification failure lint checks
They are no longer needed since we transitively require AGP 8.1.
Bug: 345472586
Test: ./gradlew lintDebug
Change-Id: Icb6ad18297fef4a23071cd849b6e84855d2becd0
M lint-checks/src/main/java/androidx/build/lint/AndroidXIssueRegistry.kt
Description
Jetpack Compose version: I've tested on 1.3.0-alpha01 and 1.2.0-beta03
Jetpack Compose component(s) used: LazyColumn
Android Studio Build: 221.3427.89.2211.8689873
Kotlin version: 1.7.10
Steps to Reproduce or Code Sample to Reproduce:
Context:
We have a rather large (10k+ items) LazyColumn where scrolling (eventually) leads to the application grinding to a halt, constantly trying to free memory. It can't, we just keep getting lots of these:
Background concurrent copying GC freed 51964(1414KB) AllocSpace objects, 6(120KB) LOS objects, 0% free, 190MB/192MB, paused 101us total 1.483s
I took at heap dump at this point and basically all of the heap is used up by instances of
SnapshotMutableStateImpl$StateStateRecord
.Replace LazyColumn with a RecyclerView (with each item being a ComposeView) and the memory leak is gone. App performance is night and day better.
I've been trying for hours to reproduce this in a trivial sample project and haven't had any luck yet. Raising this anyway just in case you have any ideas about what might be causing it. Obviously this makes LazyColumn completely unusable for us, so we'll stick to RecyclerView for now!