Work around font preloading bug in Android O framework |
|||||||
Issue descriptionApps which use the Android font preloading feature introduced in O crash when attempting to use WebView, because the WebView renderer process attempts to look up the preloaded font list belonging to the application, which is an arbitrary app-specific Android resource ID that is unlikely to exist in the WebView implementation APK. This happens because the package name of the ApplicationInfo object used in ActivityThread.handleBindApplication is the client app's package name, as an implementation detail of external services. The existing ApplicationInfo object doesn't contain metadata fields, so the ActivityThread code fetches a fresh copy from PackageManager using the package name, which results in it getting the app's metadata instead of WebView's. We're fixing this in the framework for future Android versions in b/70968451 but it's too late to fix this for O and O MR1 which have already been released with this bug. It's viable to work around this bug using reflection in Application.onCreate, which is called by ActivityThread before the font preloading takes place. This will require accessing several private framework implementation details in order to replace the PackageManager instance that will be used for the query with one that edits out font preloading info from the returned metadata. It's possible that this code has been customised by device vendors, defeating the reflection, but it's unlikely: the required fields/methods are probably not interesting to alter. This will require adding a custom Application subclass to the standalone WebView APK, as well as altering the existing MonochromeApplication.
,
Feb 9 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4a16a1c9a5857d071d628fe95924f12eb701f326 commit 4a16a1c9a5857d071d628fe95924f12eb701f326 Author: Torne (Richard Coles) <torne@google.com> Date: Fri Feb 09 17:27:37 2018 Improve font preloading workaround. Instead of looking for a specific method call in IPackageManager, just apply the filtering to any method that returns ApplicationInfo. This makes it a bit simpler and more robust against changes in this non-public class. The current AOSP IPackageManager only has one method that returns ApplicationInfo and it's the method we were checking for, so this isn't expanding the scope of the workaround unless the framework has been customised. It's also not necessary to check for GET_META_DATA since if that wasn't used, the metaData field will simply be null and the existing check will cover it. Bug: 809636 Change-Id: I207f848f4d399684e63dbc62ade199f0244fdecc Reviewed-on: https://chromium-review.googlesource.com/909588 Commit-Queue: Richard Coles <torne@chromium.org> Reviewed-by: Tobias Sargeant <tobiasjs@chromium.org> Cr-Commit-Position: refs/heads/master@{#535740} [modify] https://crrev.com/4a16a1c9a5857d071d628fe95924f12eb701f326/android_webview/glue/java/src/com/android/webview/chromium/FontPreloadingWorkaround.java
,
Feb 9 2018
,
Feb 9 2018
This bug requires manual review: DEPS changes referenced in bugdroid comments. Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 12 2018
Do we still need this in M65 even though we are not dropping M65 prebuilt as of this week?
,
Feb 12 2018
This is a workaround for O - it's not needed for P where the underlying framework bug has been fixed. So, I'd like to ship this in M65 if we think that's reasonable, to get it out sooner..
,
Feb 13 2018
Actually, since the major app reporting this issue has already fixed it on their end and in general the problem should be completely obvious in app testing, it's probably no rush to merge it; 66 is fine. The reflection should be safe but it's probably not worth the risk anyhow. Thanks anyway!
,
Feb 13 2018
,
Feb 20 2018
This broke the webview stub since the stub's manifest was trying to load WebViewApplication, which doesn't exist in the donor monochrome apk. Fix in CQ.
,
Feb 20 2018
The following revision refers to this bug: https://chrome-internal.googlesource.com/clank/internal/apps/+/32c6783772ee02341c6a058e9060a48952f32017 commit 32c6783772ee02341c6a058e9060a48952f32017 Author: Torne (Richard Coles) <torne@google.com> Date: Tue Feb 20 17:38:43 2018
,
Feb 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/12efe1d50388191d4acf7711a66cf8ba3311ee74 commit 12efe1d50388191d4acf7711a66cf8ba3311ee74 Author: Torne (Richard Coles) <torne@google.com> Date: Tue Feb 20 17:50:25 2018 Make the webview application class name a variable. The WebView stub needs to be able to override this to Monochrome's application class name. Bug: 809636 Change-Id: Icbc68f84ce76a8cb2d3ed8ec11d0cca0e00e33e3 Reviewed-on: https://chromium-review.googlesource.com/926724 Reviewed-by: Tobias Sargeant <tobiasjs@chromium.org> Commit-Queue: Richard Coles <torne@chromium.org> Cr-Commit-Position: refs/heads/master@{#537812} [modify] https://crrev.com/12efe1d50388191d4acf7711a66cf8ba3311ee74/android_webview/apk/java/AndroidManifest.xml
,
Feb 20 2018
Tested locally that this fixes the stub, so all sorted. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by bugdroid1@chromium.org
, Feb 7 2018