Move away from using DFM to distribute AR-related code
This change will make Chrome for Android stop using DFM to ship the ARCore SDK. This is done to enable us to provide AR experiences for apps using WebView. The changes are introduced in a way to enable us to switch back to using AR DFM if need be. Changes summary: - chrome_java target (defined in chrome/android/BUILD.gn) now also compiles ArCoreShimImpl.java (see java_sources.gni) - this means that java parts from ARCore SDK have to be added to its deps - libarcore_sdk_c.so needs to be listed in loadable modules - this is done in monochrome_public_common_apk_or_module_tmpl (only if target is a base module when ARCore is enabled) - AndroidManifest.xml no longer needs to contain the min_apk_version and InstallActivity entries explicitly - they will be brought in auto-magically by the build system and were needed only because manifest merging did not work for DFMs - ArCoreInstallUtils (java) should never report that we can request installation of AR DFM - ArCoreConsentPrompt (native) should never think it needs to request installation of AR DFM - Added a DCHECK and graceful handling of null jstring for java_path (path to ARCore SDK .so) - it can be null if loadable_modules do not contain correct entry - with the DCHECK, debug builds will still crash but the release builds should just report that the WebXR specified session configuration (session mode == "immersive-ar") is not supported Binary-Size: Tracked in crbug/1040289 Bug: 1031623, 1040289 Change-Id: Ia2f305d1685f1c7207cc187d253f59a6331c36fc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1988834 Commit-Queue: Andrew Grieve <agrieve@chromium.org> Reviewed-by:Andrew Grieve <agrieve@chromium.org> Reviewed-by:
Alexander Cooper <alcooper@chromium.org> Auto-Submit: Piotr Bialecki <bialpio@chromium.org> Cr-Commit-Position: refs/heads/master@{#729818}
Showing
Please register or sign in to comment