Status Update
Comments
ia...@gmail.com <ia...@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.
il...@google.com <il...@google.com> #3
Related public bug:
ma...@gmail.com <ma...@gmail.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).
il...@google.com <il...@google.com>
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.
il...@google.com <il...@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}
[Deleted User] <[Deleted User]> #7
After discussion: APK path for baseline.prof must stay the same assets/dexopt/baseline.prof
Description
Version used: 1.0.0-alpha01
Devices/Android versions reproduced on: Device running Android P, compiled in SDK 27
If this is a bug in the library, we would appreciate if you could attach:
- Sample project to trigger the issue.
- A screenrecord or screenshots showing the issue (if UI related).
In order to instantiate the view of my first fragment, some data needs to be passed from the current Activity to the primary fragment. Currently, I don't see a clear way to do this. In the same way one can navigate from fragment to fragment while passing arguments via the NavController's navigate method, it would be helpful if there was some method to pass a bundle to the first nav fragment and update the graph associated with the NavHostFragment before inflating the view.
Please do let me know if there is some way to do this that I'm missing. Currently I'm setting up a dummy fragment to start with that will manage passing the data to the intended first fragment.