-
Samuel Huang authored
Previously DFM load (for native libraries / resources) takes place when a DFM's Module.getImpl() is called. However, VR is an exception; its Module.getImpl() is called early, before main library load (which is needed by DFM load). A worked around was to defer loading at first, and flush then in Module.doDeferredNativeRegistrations(). This CL cleans up the above by giving more control to each DFM to specify whether to automatically load DFMs in Module.getImpl(). A DFM can override the default (true) behavior to manage its own native loading, which may take place on start-up, on first use, and/or on install. This CL also makes the following changes to specific DFMs: * VR: Disable load-on-getImpl, with explicit load added to VrShellDelegate.onNativeLibraryAvailable(), which gets called on start-up and on install. * DevUI: Disables load-on-getImpl since Module.getImpl() doesn't get used anyway. Keep existing calls for load-on-use and load-on-install. Other implementation details: * Remove Module.doDeferredNativeRegistrations() and it list of deferred DFM loads. * Add flag |load_native_on_get_impl| to be given in DFM target *_module_desc. This is compulsory iff DFM specifies native libraries or resources. * Replace Module.loadNative() with Module.ensureNativeLoaded(), which is specific to a module (i.e., no longer static). The name emphasizes that repeated calls are simply ignored. It assumes that the DFM installed, and requires Chrome's native library to be loaded. * Replace static map |Module.sInitializedModules| by per-module flag |mIsLoaded|. Bug: 1048740 Change-Id: I2fa844239fc3d741d91d28f384b2bc75a712b574 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2044489 Commit-Queue: Samuel Huang <huangs@chromium.org> Reviewed-by:
Andrew Grieve <agrieve@chromium.org> Cr-Commit-Position: refs/heads/master@{#743321}
7130b4a4