Good idea. Implementing this will be a bit involved.

Clicking the negative button on the setup flow in OOBE results in WizardController::OnMultiDeviceSetupFinished() being called, but the problem is that this function is called in all cases (consented in OOBE, skipped OOBE, or didn't even see the multi-device setup flow at all in OOBE). We would need to be able to differentiate between those three different events. Then, we would need to communicate this to the service somehow. The best way would probably be to inject a new object into the service, similar to what is done for AndroidSmsAppHelperDelegateImpl in profile_impl.cc (see [2]). The only difference is that the object would need to be shared (instead of passing a std::unique_ptr), since both the service and WizardController would need to share the object.

[1] https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/wizard_controller.cc?q=OnMultiDeviceSetupFinished
[2] https://cs.chromium.org/chromium/src/chrome/browser/profiles/profile_impl.cc?q=CreateMultiDeviceSetupService

Is there any way we could write to a pref when the user says "No Thanks"? Would that be easier?

Isn't this a duplicate of Issue (4) is  crbug.com/892829 ?

If so, I believe the notification should already be up in the background when the user skips that step in OOBE in which case we would just need to dismiss it when they hit skip and then our existing logic will prevent it form coming up again.

Yes, this is indeed the same bug as part #4 of  issue 892829 . So, you're right - we will already have the notification visible at that time.

However, I think you're oversimplifying how we would "just need to dismiss it when they hit skip." As mentioned in comment #1, this isn't trivial: first, we would need to share this knowledge between WizardController and MultiDeviceSetupImpl. To answer comment #2: yes, a preference could be used, but this would need to be encapsulated within a class to make this contract explicit. Furthermore, there is currently no API to remove a notification, so we'd need to add a new Mojo function to AccountStatusChangeDelegate (see [1]), then implement that function in MultiDeviceNotificationPresenter (see [2]).

[1] https://cs.chromium.org/chromium/src/chromeos/services/multidevice_setup/public/mojom/multidevice_setup.mojom?q=AccountStatusChangeDelegate
[2] https://cs.chromium.org/chromium/src/ash/multi_device_setup/multi_device_notification_presenter.h

 Issue 892829  has been merged into this issue.

jordynass@ meant to target [1] for this bug bug accidentally included the wrong bug #. Requesting merge for that CL.

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

Your change meets the bar and is auto-approved for M71. Please go ahead and merge the CL to branch 3578 manually. Please contact milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

We made the same mistake for the cherrypick that we did in #7 -- the cherrypick CL referenced the wrong bug number. Find the cherrypick here: https://chromium-review.googlesource.com/c/chromium/src/+/1289166

Removing merge tags.