Note that this includes moving the Java code and registering its JNI in the Device Service rather than in //content/app.

In file "device_sensor_browsertest.cc", it depends below files which are in //device/sensors/ (not in //device/sensors/public/)
 #include "device/sensors/data_fetcher_shared_memory.h"
 #include "device/sensors/device_sensor_service.h"

We have to replace this browsertest by a layouttest? similar as vibration_browsertest (686692)

Ke He, thanks for the analysis here! Yes, those direct dependencies have to go as well, or else the browsertest needs to be ported to a service test that lives in the Device Service itself (i.e., the usage of the renderer would be replaced by a test "device sensor client" service that the test can connect to and drive. Can you file a separate bug for that and block  crbug.com/612322  on it? We can do the work described in this bug first, and have an additional GN visibility for content_browsertests with a TODO to remove it.

Colin, I found your CL "Move Device Sensors client files from Blink to //device/sensors client lib"(Issue 2415083002) is still in pending.

I guess we need to suspend this task until your CL get landed? Otherwise it will introduce dependencies from //services/device on //blink.

Ke He, you are correct. This is issue  crbug.com/686709 , which is blocking this one. However, as that issue notes, the approach I took in that CL won't work due to Blink dependency rules. Instead, we'll have to define those structs/types/etc in mojom to share them between the Blink client and the Device Service.

Hi, Colin, my thoughts on 686709 mentioned above:

Option 1): there is only one line code "memset(this, 0, sizeof(*this));" in file WebDeviceMotionData.cpp in blink, So how about to delete this file and move the "memset(..)" into file "WebDeviceMotionData.h" as inline? then the dependency of ""//third_party/WebKit/public:blink" can be removed. //services/device/ will only depend on "//third_party/WebKit/public:blink_headers" which is allowed I guess?

Option 2): if depending on blink_headers is not allowed, I'll add definitions of struct WebDeviceMotionData in mojom, and remove the original definitions in blink:: namespace. Then replace all the references by mojo::WebDeviceMotionData. But I found that the blink::WebDeviceMotionData uses "pragma pack", it occupies smaller memory, while I didn't find any "pragma pack" grammar in mojo. In this way the struct occupies larger memory, So it leads to we transfer a larger mojo::sharedBuffer from browser to render. Do you think it's ok?

Thanks!

Thanks for this investigation! We don't want a dependency even on Blink headers in the Device Service, as it would be a dependency inversion for Device Service to depend on one of its clients. That leaves option (2).

However, the question that you raise there is important. I'm going to chew over the best way to get feedback on that question; stay tuned there.

Hi, Colin, Thank you. Please let me know if something we can continue.

As Reilly is planing to merge sensor into generic_sensor, so we set this as WontFix.

The obsolete CL for this: https://codereview.chromium.org/2819273006/