Fixed
Status Update
Comments
di...@google.com <di...@google.com> #2
Some things to work out before making the annotations type-use:
- Determine guidelines for type nullability in public API
- Determine rules for when type nullability can change in public API
- Confirm that intellij nullability lint works as expected for type-use nullability annotations
- Test what the impact would be on existing arrays (due to ambiguities of type-use annotations on arrays)
- Confirm usage of type-use
androidx.annotation.NonNull/Nullable
in metalava won't break anything for platform
ap...@google.com <ap...@google.com> #4
23...@gmail.com <23...@gmail.com> #5
Comment has been deleted.
di...@google.com <di...@google.com> #6
Project: platform/frameworks/support
Branch: androidx-main
commit c8f5025ba9bf1deb5effbebb7e79683ee7ff9f50
Author: Julia McClellan <juliamcclellan@google.com>
Date: Fri Sep 20 12:31:45 2024
Add JSpecify package-list
Bug: 326456246
Test: checking links in output of `./gradlew docs-tip-of-tree:docs` with aosp/3190072 which switches annotations to jspecify
Change-Id: Ic52ecc37cfb84002ba830dfca6186db2dc5bae67
M buildSrc/private/src/main/kotlin/androidx/build/dackka/DackkaTask.kt
A docs-public/package-lists/jspecify/package-list
https://android-review.googlesource.com/3275171
Branch: androidx-main
commit c8f5025ba9bf1deb5effbebb7e79683ee7ff9f50
Author: Julia McClellan <juliamcclellan@google.com>
Date: Fri Sep 20 12:31:45 2024
Add JSpecify package-list
Bug: 326456246
Test: checking links in output of `./gradlew docs-tip-of-tree:docs` with aosp/3190072 which switches annotations to jspecify
Change-Id: Ic52ecc37cfb84002ba830dfca6186db2dc5bae67
M buildSrc/private/src/main/kotlin/androidx/build/dackka/DackkaTask.kt
A docs-public/package-lists/jspecify/package-list
su...@gmail.com <su...@gmail.com> #7
Project: platform/frameworks/support
Branch: androidx-main
commit b05578cabee04fdccd2f24c7e2d6a8b25b94a97a
Author: Julia McClellan <juliamcclellan@google.com>
Date: Mon Sep 23 11:21:48 2024
Add java format task
Will be used by the jspecify update script
Bug: 326456246
Test: `./gradlew core:core:javaFormat`, `./gradlew core:core:javaFormat --fix-imports-only` to check java diffs. `./gradlew paging:paging-guava:javaFormat` to check the task succeeds for a project with no java files
Change-Id: I6027419d4ad520a4bd82decd009d252b7077d8a6
M buildSrc/private/src/main/kotlin/androidx/build/AndroidXImplPlugin.kt
A buildSrc/private/src/main/kotlin/androidx/build/JavaFormat.kt
M gradle/libs.versions.toml
https://android-review.googlesource.com/3277031
Branch: androidx-main
commit b05578cabee04fdccd2f24c7e2d6a8b25b94a97a
Author: Julia McClellan <juliamcclellan@google.com>
Date: Mon Sep 23 11:21:48 2024
Add java format task
Will be used by the jspecify update script
Bug: 326456246
Test: `./gradlew core:core:javaFormat`, `./gradlew core:core:javaFormat --fix-imports-only` to check java diffs. `./gradlew paging:paging-guava:javaFormat` to check the task succeeds for a project with no java files
Change-Id: I6027419d4ad520a4bd82decd009d252b7077d8a6
M buildSrc/private/src/main/kotlin/androidx/build/AndroidXImplPlugin.kt
A buildSrc/private/src/main/kotlin/androidx/build/JavaFormat.kt
M gradle/libs.versions.toml
Description
Version used: 1.0.0-beta02
Devices/Android versions reproduced on: Android 11 (real and emulator)
Essentially the logic is setup a sample project with a fragment and invoke the windowInfoRepository() method with an activity. That causes the ExtensionWindowBackend.globalInstance to hold on to the activity's context. Perhaps using the application context would be better, but I don't know how the context is used.
For example I am using Kotlin and only do the following to get the window metrics to replace deprecated code in Android 12.
val metrics = activity?.windowInfoRepository()?.currentWindowMetrics?.firstOrNull()?.bounds
Stack trace of the leak:
┬───
│ GC Root: Input or output parameters in native code
│
├─ okio.AsyncTimeout class
│ Leaking: NO (PathClassLoader↓ is not leaking and a class is never leaking)
│ ↓ static AsyncTimeout.$class$classLoader
├─ dalvik.system.PathClassLoader instance
│ Leaking: NO (ExtensionWindowBackend↓ is not leaking and A ClassLoader is
│ never leaking)
│ ↓ ClassLoader.runtimeInternalObjects
├─ java.lang.Object[] array
│ Leaking: NO (ExtensionWindowBackend↓ is not leaking)
│ ↓ Object[].[7701]
├─ androidx.window.layout.ExtensionWindowBackend class
│ Leaking: NO (a class is never leaking)
│ ↓ static ExtensionWindowBackend.globalInstance
│ ~~~~~~~~~~~~~~
├─ androidx.window.layout.ExtensionWindowBackend instance
│ Leaking: UNKNOWN
│ Retaining 125.0 kB in 2848 objects
│ ↓ ExtensionWindowBackend.windowExtension
│ ~~~~~~~~~~~~~~~
├─ androidx.window.layout.SidecarCompat instance
│ Leaking: UNKNOWN
│ Retaining 124.9 kB in 2844 objects
│ ↓ SidecarCompat.sidecar
│ ~~~~~~~
├─ androidx.window.sidecar.SettingsSidecarImpl instance
│ Leaking: UNKNOWN
│ Retaining 124.6 kB in 2832 objects
│ mContext instance of com.example.MyActivity with
│ mDestroyed = true
│ ↓ SettingsSidecarImpl.mContext
│ ~~~~~~~~
╰→ com.example.MyActivity instance
Leaking: YES (ObjectWatcher was watching this because com.example.MyActivity
received Activity#onDestroy() callback and
Activity#mDestroyed is true)
Retaining 115.4 kB in 2676 objects
key = 169cb8aa-ce65-4d85-ad39-a03daaad93f7
watchDurationMillis = 5190
retainedDurationMillis = 190
mApplication instance of com.example.Application
mBase instance of androidx.appcompat.view.ContextThemeWrapper
METADATA
Build.VERSION.SDK_INT: 30
Build.MANUFACTURER: Google
LeakCanary version: 2.7
App process name: com.example.debug
Count of retained yet cleared: 4 KeyedWeakReference instances
Stats: LruCache[maxSize=3000,hits=9130,misses=169317,hitRate=5%]
RandomAccess[bytes=9274118,reads=169317,travel=111728236112,range=42477374,size=
51517143]
Heap dump reason: 18 retained objects, app is visible
Analysis duration: 86480 ms