commit f99b7ddd798842c586440fa116a988ab73fc45f4
author David 'Digit' Turner <digit@google.com> Tue Mar 06 18:05:58 2018
committer Jun Cai <juncai@chromium.org> Tue Mar 06 18:05:58 2018
tree abaeaf0a87ceb2efcd3a09db690575d96d521486
parent f607cb3e750c21fb9e0476543beed50503b58b65

android: Fix sensors in device service.

This patch fixes a bug that prevented more than one sensor data
to be available at once when using the device motion/orientation
API.

The issue was introduced by this other patch [1] which fixed
some security-related issues in the way shared memory region
handles are managed throughout Chromium (more details at
https://crbug.com/789959).

The device service´s sensor implementation doesn´t work
correctly because it assumes it is possible to create a
writable mapping of a given shared memory region at any
time. This assumption is not correct on Android, once an
Ashmem region has been turned read-only, such mappings
are no longer possible.

To fix the implementation, this CL changes the following:

- PlatformSensor used to require moving a
  mojo::ScopedSharedBufferMapping into the newly-created
  instance. Said mapping being owned by and destroyed
  with the PlatformSensor instance.

  With this patch, the constructor instead takes a single
  pointer to the corresponding SensorReadingSharedBuffer,
  i.e. the area in memory where the sensor-specific
  reading data is located, and can be either updated
  or read-from.

  Note that the PlatformSensor does not own the mapping
  anymore.

- PlatformSensorProviderBase holds the *single* writable
  mapping that is used to store all SensorReadingSharedBuffer
  buffers. It is created just after the region itself,
  and thus can be used even after the region's access
  mode has been changed to read-only.

  Addresses within the mapping will be passed to
  PlatformSensor constructors, computed from the
  mapping's base address plus a sensor-specific
  offset.

  The mapping is now owned by the
  PlatformSensorProviderBase instance.

Note that, security-wise, nothing changes, because all
mojo::ScopedSharedBufferMapping before the patch actually
pointed to the same writable-page in memory anyway.

Since unit or integration tests didn't catch the regression
when [1] was submitted, this patch was tested manually by
running a newly-built Chrome apk in the Android emulator
and on a real device running Android O.

[1] https://chromium-review.googlesource.com/c/chromium/src/+/805238

BUG=805146
R=​mattcary@chromium.org,alexilin@chromium.org,juncai@chromium.org,reillyg@chromium.org

Change-Id: I7d60a1cad278f48c361d2ece5a90de10eb082b44
Reviewed-on: https://chromium-review.googlesource.com/891180
Commit-Queue: David Turner <digit@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Matthew Cary <mattcary@chromium.org>
Reviewed-by: Alexandr Ilin <alexilin@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#532607}(cherry picked from commit c0c8978849ac57e4ecd613ddc8ff7852a2054734)
Reviewed-on: https://chromium-review.googlesource.com/951663
Reviewed-by: Jun Cai <juncai@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#671}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}