Status Update
Comments
ga...@gmail.com <ga...@gmail.com> #2
The location of where this is being placed in the app bundle by AGP (as quoted in
) is also incorrect - rather than BUNDLE_METADATA/assets/dexopt/baseline.prof it should be at BUNDLE_METADATA/com.android.tools.build.profiles/baseline.prof or similar, to correctly identify what kind of metadata this is within the bundle. So that baseline profiles generated from android studio via the android app bundle actually work, we'd need to make these changes in AGP for the next stable release of studio. b/226434396#comment1
Currently the baseline profile ends up in BUNDLE_METADATA/assets/dexopt/baseline.prof{m}
.
It needs to end up in BUNDLE_METADATA/com.android.tools.build.profiles/baseline.prof{m}
or something so we can disambiguate between the types of metadata.
jb...@google.com <jb...@google.com>
ga...@freeletics.com <ga...@freeletics.com> #3
Related public bug:
cl...@google.com <cl...@google.com> #4
ok so we can move the location of the baseline.prof to the new location : BUNDLE_METADATA/com.android.tools.build.profiles/baseline.prof{m}
but this will not fix the previous versions of the plugins that have shipped with this behavior (including Bumblebee) so this needs to be handled by the playstore to look into both locations (for a while at least).
ap...@google.com <ap...@google.com> #5
Martin mentioned on the email thread that they likely won't look in the previous location:
Bundletool guards its behavioural changes behind the bundletool version that the AAB was created with (so the developer knows how their bundles will be turned into apks, and there are no surprises). So we'd only be converting profiles-in-AAB to profiles-in-APKs for cases where the AAB was built with a bundletool that knew about profiles (which is, as of now, none of them - but bundletool 1.11 will).
In that case, if we don't fix it for Chipmunk release, we will have 2 stable versions of AGP that people are going to use for a while where the profile essentially gets lost, and the next stable release is not until July at least. I would argue we should make it a P0 and get the fix in AGP and potentially delay the stable release for a week. And in the worst case we should do it in a point release as soon as possible.
cl...@google.com <cl...@google.com> #6
Currently the baseline profile ends up in BUNDLE_METADATA/assets/dexopt/baseline.prof{m}. It needs to end up in BUNDLE_METADATA/com.android.tools.build.profiles/baseline.prof{m}
Should we also move baseline profile in apk from
assets/dexopt/baseline.prof{m}
to
com.android.tools.build.profiles/baseline.prof{m}
na...@google.com <na...@google.com> #7
After discussion: APK path for baseline.prof must stay the same assets/dexopt/baseline.prof
na...@google.com <na...@google.com> #8
+1 to P0ing this and ensuring baseline profiles will be successfully packaged for bundle-using app developers ASAP. This is a huge priority as baseline profiles is the biggest intervention apps can do to improve their performance, and we're really advocating that every app take advantage of it right now!
Description
Version used: 2.6.0
Devices/Android versions reproduced on: Emulator Android 13
Very simple scenario for demo purposes:
1. MainFragment navigates to Dialog1Fragment
2. Dialog1Fragment navigates to Dialog2Fragment
3. Dialog2Fragment navigates back
This will result in the lifecycle of Dialog1Fragment's NavBackStackEntry to go back into `ON_START` but it will never go back to `ON_RESUME` even though it is now the top destination on the stack.
I've attached a small sample project with these 3 fragments