Scan volume based on volume state changes, not broadcasts.
We previously relied on broadcasts to initiate scanning of mounted
volumes. However, these broadcasts can be delayed, and in case of
volumes belonging to clone users, we'd need to make additional
modifications to the framework to receive such broadcasts.
MediaProvider already has a better way to receive these events: it
receives volume state change events directly from the
StorageManagerService. We'd tried to use these previously, but it
resulted into issues because we did the scan synchronously as part of
the state change call itself.
Instead, this CL keeps the scan asynchronous by having it done on the
existing MediaService.
Bug: 183949139
Test: TEST_MAPPING
Change-Id: Ib0ae5387a052bc0d4b653e350c90249a0ac4b39c
5 files changed