AsyncListDiffer should dispatch updates after setting current list [74003309]

Fixed

Bug

Status Update

No update yet.

Description

cc...@google.com

created issue #1

Feb 28, 2018 05:20PM

Currently dispatches updates before dispatching DiffResult, which is incorrect.

Comments

cc...@google.com <cc...@google.com> #2Feb 28, 2018 09:22PM

Marked as fixed.

Project: platform/tools/metalava
Branch: metalava-main

commit b48703daf63321ceeb6edeca15f6f6e83f70718b
Author: Alan Viverette <alanv@google.com>
Date: Fri Apr 28 12:31:37 2023

Allow checking API compatibility conditionally based on annotations

Bug: 278769092
Test: CompatibilityCheckTest
Change-Id: I3c566bb0219b358795a7acb74ecebb269b217083

M src/main/java/com/android/tools/metalava/CompatibilityCheck.kt
M src/main/java/com/android/tools/metalava/Issues.kt
M src/main/java/com/android/tools/metalava/Options.kt
M src/main/java/com/android/tools/metalava/model/Item.kt
M src/main/java/com/android/tools/metalava/model/ModifierList.kt
M src/test/java/com/android/tools/metalava/CompatibilityCheckTest.kt
M src/test/java/com/android/tools/metalava/DriverTest.kt
M src/test/java/com/android/tools/metalava/OptionsTest.kt

https://android-review.googlesource.com/2571751

km...@gmail.com <km...@gmail.com> #3Apr 7, 2018 04:57PM

aosp/2571751 implemented support in Metalava.

Remaining work:

Update Metalava used by androidx-main
Add flags to suppress compatibility for @RequiresOptIn
Remove extra Metalava invocation in AndroidX plugin
Re-generate API files to combine current and experimental
Update API Council guidance and send out PSA

kk...@google.com <kk...@google.com> #4Apr 10, 2018 04:14AM

Aurimas requested that I refactor the new API from comment#2 to isCompatibilitySuppressed. Will need to handle that before the work in comment#3.

ab...@gmail.com <ab...@gmail.com> #5Aug 29, 2020 03:32AM

Project: platform/tools/metalava
Branch: metalava-main

commit ca39b114eb67d316ba1252b5e724cca7b8182c55
Author: Alan Viverette <alanv@google.com>
Date: Thu May 04 17:06:42 2023

Refactor compatibility suppression APIs

Bug: 278769092
Test: CompatibilityCheckTest
Change-Id: I5b1672b84b3a79b568d6b358abf6e2e34244ba6f

M src/main/java/com/android/tools/metalava/CompatibilityCheck.kt
M src/main/java/com/android/tools/metalava/Options.kt
M src/main/java/com/android/tools/metalava/model/Item.kt
M src/main/java/com/android/tools/metalava/model/ModifierList.kt
M src/test/java/com/android/tools/metalava/CompatibilityCheckTest.kt
M src/test/java/com/android/tools/metalava/DriverTest.kt
M src/test/java/com/android/tools/metalava/OptionsTest.kt

https://android-review.googlesource.com/2579373

ka...@gmail.com <ka...@gmail.com> #6Jan 23, 2021 04:15PM

Alright, now to consider how we actually pull this off in a working branch and a downstream working branch with diffs. Aurimas suggested reducing the granularity.

So, tentatively, per-project or group or cluster:

Suppress and un-hide experimental APIs in public API task (e.g. current.txt)
Disable experimental API task (e.g. public_plus_experimental_current.txt)
Overwrite all X.txt files with the existing public_plus_experimental_X.txt files
- Including current and historical API files, e.g. current.txt and 1.0.0-beta01.txt
Don't make any changes to restricted API tasks for files

Or we just do this all at once over a weekend.

ka...@gmail.com <ka...@gmail.com> #7Jan 23, 2021 04:16PM

Implemented as a feature flag in gradle.properties. It was a huge pain to support both code paths, and it's going to be a pain to clean up, but it'll be a good first attempt at scaling these sorts of migrations. If it goes well, we might want to add some more formal feature flagging system.

Issue 74003309