GitLab

Update the multi-device setup service function SetHostDevice() and
related functions to accept either a device's Instance ID or legacy
RemoteDevice ID. The former is only present for devices using v2
DeviceSync and the latter is the encoded public key--given by
RemoteDevice::GetDeviceId(). The legacy device ID will not be available
from the v2 DeviceSync service until device metadata can be decrypted.
This delay could prevent multi-device setup, especially during OOBE,
unless SetHostDevice() also supports use of the Instance ID.

By design, the Chrome OS CryptAuth client code guarantees that while v1
DeviceSync is running--whether in parallel with v2 DeviceSync or alone--
every device will always have an unencrypted legacy device ID, though
some may not have an Instance ID. When v1 DeviceSync is turned off,
however, only an Instance ID is guaranteed, and this CL is necessary.

This CL is meant to be temporary. When v1 DeviceSync is turned off and
no rollback is expected, the changes in this CL should be revised to
only use Instance IDs since those are always guaranteed to exist in v2
DeviceSync.

Variable name changes from |host_device_id| to the elegant
|host_instance_id_or_legacy_device_id| comprise the bulk of this CL. The
crucial logic changes are in start_setup_page.html/js and
multidevice_setup_impl.cc.

Bug: 951969, 1019206
Change-Id: I99c3b79cbb8414da65ee7b95dab80f661f15b13b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2000972Reviewed-by: Mustafa Emre Acer <meacer@chromium.org>
Reviewed-by: Achuith Bhandarkar <achuith@chromium.org>
Commit-Queue: Josh Nohle <nohle@chromium.org>
Cr-Commit-Position: refs/heads/master@{#735679}