I forgot to mention: I verified the problem disappears after reverting fd907634b5ea956b34bd1672c084089aad2150cd locally.

To be clear this is not really a Mojo wire format change at all, but a
change in how legacy Chrome IPC structures are represented in mojom. I was
unaware that ARC depended on legacy Chrome IPC structures crossing the
container boundary. That seems like a rather undesirable state to be in.

Rockot, any recommendatation for short and long term?

For longer term, I guess ARC bluetooth should migrate into mojo/common/values.mojom?
Though it'd take a time (I guess a week or two considering Chrome roll timing etc.), can we revert yours temporarily for short term fix?

rockot: I see. What do you suggest as a resolution to this issue?

A revert is an acceptable solution for maybe a week or so, but we're going
to want to reland ASAP since it's blocking other important work.

If we revert, is someone going to prioritize fixing the ARC IPC(s) so they
stop depending on [Native] mojom types? And what kind of turnaround can we
expect on that?

Hmm, values.mojo seems not to be included in current libmojo rolled to ARC branch.
Luis, any updates for the roll?

We're currently blocked on the mac_sdk builder for Android (long story: we need to roll libchrome+libmojo in AOSP first in order to consume them from Chrome OS and nyc-mr1-arc).

A mac machine to diagnose this has been ordered and will arrive in 3-6 weeks.

Do we really need to do a complete uprev? Can't we just do a minimal cherry-pick of a suitable mojom Value definition?

The targets to be cherry-picked are

https://chromium.googlesource.com/chromium/src/+/041c065f9642c035a27a057a4a6e9950913db027
https://chromium.googlesource.com/chromium/src/+/9bd0ed45ad35ed78c4ccd55321f884cacd0778d7

Though, these look relatively big, so I'm not sure if we can cherry-pick it simply.
If not, we'd add some workaround until full-uprev is done.
I'll take a look.

Keep in mind, you don't necessarily need to cherry-pick existing changes.
You could land your own one-off Value type that's just sufficient for this
use case (with comments explaining why) and then cherry pick that?

Re #10. Thank you for advice.

IIUC, simply copying values.mojom and its typemap wouldn't work unfortunately,
because it will conflict the name ListValue with the one used to be in custom_common_types.mojom.
We'd need some (probably small) manual modification there, which could conflict on uprev-ing. Or I'd check-in mojom file to ARC's one with changing namespace, as a last resort.

Update:

Unfortunately, due to dependencies from values.mojom to files which aren't in the old libmojo currently rolled to ARC, using values.mojom doesn't look promising.
(regardless where to cherry-pick).

So, instead, as a simpler shortterm workaround, I'd serialize-to/deserialize-form JSON, and use "string?" for the field.

Update:

using "string?" looked working locally. Will send a CL after unittests are fixed.
Note that, we have to remove LegacyListValue field, otherwise it is tried to deserialized, so protocol error occur. This means, there is no way to avoid breaking change anyway.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a2b1d009333a36e5ee3b20c7669fd70362dbe1a6

commit a2b1d009333a36e5ee3b20c7669fd70362dbe1a6
Author: Hidehiko Abe <hidehiko@chromium.org>
Date: Thu Oct 05 08:33:36 2017

Use stringified JSON for bluetooth sdp attributes.

Recently, Mojo wire format change was introduced
for native structure.
https://chromium.googlesource.com/chromium/src/+/fd907634b5ea956b34bd1672c084089aad2150cd
It causes a protocol mismatch between ARC and Chrome.
Unfortunately, rolled libmojo is too old, so we cannot
use values.mojom now. As its workaround,
this CL stringifies the JSON value if necessary,
and use it for the communication.

Note that this is breaking change. Though, the protocol is already
broken, so we don't much care about it.

BUG= 767313 
TEST=Ran CTS.

Change-Id: Iaaf28065aa7cde0ce17d7231da0571312f23772d
Reviewed-on: https://chromium-review.googlesource.com/691495
Commit-Queue: Hidehiko Abe <hidehiko@chromium.org>
Reviewed-by: Kazuhiro Inaba <kinaba@chromium.org>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#506678}
[modify] https://crrev.com/a2b1d009333a36e5ee3b20c7669fd70362dbe1a6/components/arc/bluetooth/bluetooth_type_converters.cc
[modify] https://crrev.com/a2b1d009333a36e5ee3b20c7669fd70362dbe1a6/components/arc/bluetooth/bluetooth_type_converters_unittest.cc
[modify] https://crrev.com/a2b1d009333a36e5ee3b20c7669fd70362dbe1a6/components/arc/common/bluetooth.mojom

Now fixed.