Implementing Asynchronous Advertising ID Retrieval for H5vccSystem

[zhongqiliang]

1. A new mojom interface for H5vccSystem is created, including an asynchronous API method to retrieve the advertising ID.
2. The mojom server implementation handles the request by calling JNI (Java Native Interface) functions. These JNI calls will interact with the StarboardBridge to fetch the actual advertising ID value.
3. The renderer client then utilizes the mojom interface to call the asynchronous method and retrieve the advertising ID.

Tested on devtools, https://screenshot.googleplex.com/43HotkbLgJSQdx3

4. Added web_tests for the mojom interface.
   // Compile the web_test
   cobalt/build/gn.py -p linux-x64x11 -C devel &&
   autoninja -C out/linux-x64x11_devel blink_wpt_tests &&
   autoninja -C out/linux-x64x11_devel dump_syms &&
   autoninja -C out/linux-x64x11_devel minidump_stackwalk &&
   autoninja -C out/linux-x64x11_devel cobalt/browser/h5vcc_system/public/mojom:mojom_js
   // run the web_test
   third_party/blink/tools/run_web_tests.py -t linux-x64x11_devel wpt_internal/h5vcc/h5vcc-system

b/377049113

[andrewsavage1]

LGTM other than one (large) rename. Were you able to test this i.e. via devtools?

[yell0wd0g]

Looking close, can be simplified and also needs plugging the JS Mojo Mock.

[hlwarriner]

I left one comment and also agree with Miguel that the web test should be updated. Otherwise, looks good!

[yell0wd0g]

LGTM with a TODO(b/...) in void H5vccSystemImpl::GetAdvertisingId() to try and remove the Mojo-to-C++-to-Java (in favour of Mojo-to-Java directly). @andrewsavage1 volunteered to do so, but adding a bug and a TODO should be fast.

(I think I left a comment like this but perhaps it was in #4853).

[hlwarriner]

Left one minor comment but otherwise lgtm.

[kaidokert]

Linux builds are failing with a real build error - missing jni.h include path. It probably needs an extra dependency in GN code.

[andrewsavage1]

Linux builds are failing with a real build error - missing jni.h include path. It probably needs an extra dependency in GN code.

You'll likely need to depend on //starboard($starboard_toolchain) directly instead of //starboard/android/shared:starboard_platform. I'll come back and clean this up so we can depend on //starboard:starboard_group instead.

Alternatively you could depend on //starboard:starboard_group and add a // nogncheck for the android-specific includes that I can clean up later.

[hlwarriner]

LGTM with a TODO(b/...) in void H5vccSystemImpl::GetAdvertisingId() to try and remove the Mojo-to-C++-to-Java (in favour of Mojo-to-Java directly). @andrewsavage1 volunteered to do so, but adding a bug and a TODO should be fast.

(I think I left a comment like this but perhaps it was in #4853).

@yell0wd0g IIUC you're suggesting that for cross-platform Mojo interfaces, like this one, we have both:

• A Java Mojo impl that leverages Java Mojo bindings (built only for ATV)
• A C++ Mojo impl that leverages C++ Mojo bindings (built only for 3P).

I was looking into Mojo's Java bindings and saw these recommendations from https://chromium.googlesource.com/chromium/src/mojo/+/HEAD/public/java/bindings/README.md#should-i-or-should-i-not-use-the-java-bindings:

"Java bindings typically only make sense on the browser side and for Android devices where there is some service that‘s unique to Android. As such, Java bindings are typically rarely used, but they are used sometimes. When implementing a cross-platform feature or service, it’s probably more appropriate to use C++ Mojo bindings and (if necessary) plumb the platform-specific code implemented in Java via JNI."

From that doc it sounds like one of the primary reasons for that recommendation is that the Java bindings are missing some features: https://chromium.googlesource.com/chromium/src/mojo/+/HEAD/public/java/bindings/README.md#notable-lacking-features.

So do you think we should include both Java and C++ Mojo impls for Mojo interfaces where we don't need those features, and just C++ Mojo impls where we do? Are there examples from upstream where both Java and C++ implementations are provided for cross-platform Mojo interfacaes?