Status Update
Comments
ph...@gmail.com <ph...@gmail.com> #2
All extensions in 'core-ktx' target either 'core' or the framework types. This is working as expected. It sounds like this is a feature request for a transition-ktx with equivalent extensions for the androidx.transition types.
> as most framework classes are being deprecated in favor of their AndroidX counterparts, Fragments for example.
"Most"? This *dramatically* overstates what is actually happening. Fragments (and loaders) were added to the framework in a time where the Android team did not have external libraries for shipping features. Transition was added 5 years later.
ph...@gmail.com <ph...@gmail.com> #3
If the Transition api is unlikely to change, there is no need for a transition-ktx for androidx.transition types. If developers should use Androidx transitions over framework transitions where possible however, then it would be much appreciated.
I am well aware of the limitations that existed when Fragments and Loaders were created, and when the Transition api was introduced.
se...@google.com <se...@google.com> #4
Branch: androidx-master-dev
commit ae42e311ecfbac18cedc90e489d1fdde956a4557
Author: Jake Wharton <jakew@google.com>
Date: Fri Nov 22 11:13:30 2019
Introduce transition-ktx for standalone transition library
These extensions are the same as androidx.core.transition for the platform types, just adapted to the standalone library.
Bug: 138870873
Test: gw :transition:transition-ktx:build :transition:transition-ktx:connectedCheck
Change-Id: Ie80022cc60ed1f482b7593db5ef1ac1c5ea33d8d
M buildSrc/src/main/kotlin/androidx/build/PublishDocsRules.kt
M jetifier/jetifier/migration.config
M settings.gradle
A transition/transition-ktx/OWNERS
A transition/transition-ktx/api/1.4.0-alpha01.txt
A transition/transition-ktx/api/current.txt
A transition/transition-ktx/api/public_plus_experimental_1.4.0-alpha01.txt
A transition/transition-ktx/api/public_plus_experimental_current.txt
A transition/transition-ktx/api/res-1.4.0-alpha01.txt
A transition/transition-ktx/api/restricted_1.4.0-alpha01.txt
A transition/transition-ktx/api/restricted_current.txt
A transition/transition-ktx/build.gradle
A transition/transition-ktx/src/androidTest/AndroidManifest.xml
A transition/transition-ktx/src/androidTest/java/androidx/transition/TestActivity.kt
A transition/transition-ktx/src/androidTest/java/androidx/transition/TransitionTest.kt
A transition/transition-ktx/src/androidTest/res/layout/test_activity.xml
A transition/transition-ktx/src/main/AndroidManifest.xml
A transition/transition-ktx/src/main/java/androidx/transition/Transition.kt
ca...@gmail.com <ca...@gmail.com> #5
ra...@google.com <ra...@google.com> #6
Hi Marcelo, can you please take a look at this when you get a chance ? If not, I can come and take a look when I get back.
ma...@google.com <ma...@google.com> #7
I'm pretty sure the offending PR here is aosp/2333568 - that is the only PR touching the profile transcoding.
It fixes an important bug with compressed profiles but it seems that the new code is slower than before.
cc...@google.com <cc...@google.com> #8
If you look in the dashboard, the commit link is wrong, since it doesn't encompass all builds since the previous (9385400). Correct build range link is here, which includes Ben's CL:
(If a build goes missing for any reason, it corrupts the commit link. In general, you can always go to dashboard, and create range link like the above)
be...@google.com <be...@google.com> #9
Yes, it looks like my change introduced this regression.
If I read
That would mean the change makes opening the file slower by about 1000 times.
Chris: Given this runs on a background thread and is not blocking app startup, is it urgent to address this or can it wait for the next release cycle?
be...@google.com <be...@google.com> #11
Uploaded aosp/2355662 to address the problem.
be...@google.com <be...@google.com> #12
The CL mentioned in
mo...@google.com <mo...@google.com>
ap...@google.com <ap...@google.com> #13
Branch: androidx-main
commit b7fc1b0247a4f4883b37c1998e3f12b4f0c0b7b0
Author: Ben Weiss <benweiss@google.com>
Date: Wed Dec 14 15:49:17 2022
More detailed compressed profile handling
Just replacing openFd with open dramatically decreased the performance
of opening a profile. This new handling goes back to openFd and
introduces a diagnostic code to hint at updating bundletool.
Bug: 261998144
Test: :profileinstaller:profileinstaller:test
RelNote: Add diagnostics for compressed profiles
Change-Id: I8641387ad6073dde588d0d764da4a3b24b1c8ee4
M profileinstaller/profileinstaller/api/current.txt
M profileinstaller/profileinstaller/api/public_plus_experimental_current.txt
M profileinstaller/profileinstaller/api/restricted_current.txt
M profileinstaller/profileinstaller/src/main/java/androidx/profileinstaller/DeviceProfileWriter.java
M profileinstaller/profileinstaller/src/main/java/androidx/profileinstaller/ProfileInstaller.java
be...@google.com <be...@google.com> #14
The landed CL has moved the benchmark down to normal levels again.
pr...@google.com <pr...@google.com> #16
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.profileinstaller:profileinstaller:1.3.0-beta01
Description
Alert on dashboard:https://androidx-perf.skia.org/t/?begin=1670529681&end=1670529682&subset=all
CLs in build:https://android-build.googleplex.com/builds/branch-dashboard/aosp-androidx-main?build_id=9385668
The commit points to a CL that has no real change (just reformatting), so something else is going on.
Sean, can you look and see why this benchmark is going crazy?