Fixed
Status Update
Comments
ad...@google.com <ad...@google.com>
ku...@google.com <ku...@google.com>
sp...@google.com <sp...@google.com>
sp...@google.com <sp...@google.com> #2
This was broken by 3bca759a5ff08352de831bb1e9b61b1ec2b3362d.
Fix (pending) is I2c2dc7b600603ee430fd0d91b23d52ea8aa29ca9.
Fix (pending) is I2c2dc7b600603ee430fd0d91b23d52ea8aa29ca9.
sp...@google.com <sp...@google.com> #3
Almost 2 months later and this is still broken
da...@gmail.com <da...@gmail.com> #4
Since there is no progression, I wanted to share our quick-fix for the issue.
#sdkmanager --package_file=${PATH_WORKSPACE}/packages
while read p; do echo "y" | sdkmanager "${p}"; done <${PATH_WORKSPACE}/packages
#sdkmanager --package_file=${PATH_WORKSPACE}/packages
while read p; do echo "y" | sdkmanager "${p}"; done <${PATH_WORKSPACE}/packages
Description
Given a navigation file with entry
the resulting manifest (copied from the APK analyzer AS tool) will look like
which is missing the required
<data android:host="*.seatgeek.ca" />
. As a result, the browser picks up such links instead of being directed into the app. I also verified in the Merged Manifest subview ofAndroidManifes.xml
that it's missing there.I did try manually adding the
<intent-filter />
with the proper host, scheme, etc and confirmed that navigation is properly routing when it does receive that intent, so the problem appears just to be within the manifest generation from the navigation XML.