Actually, since Lutz is busy, probably Igor is a better owner.

UMA should be cached and submitted eventually. Why can't we wait until the device gets online again in case UMA doesn't manage to upload metrics to the server right after enrollment?

Devices that fail enrollment are likely to be shut down and shelved, especially in case of an error that is known to the enrollers to be fatal.  In that case UMA is never uploaded and what we see on the dashboards is biased towards good cases.

OK, makes sense. Do we have a clean way to wait for UMA upload as part of the enrollment flow?

Alexei, from a somewhat naive look at metrics_service.cc it seems that the following would fulfill our needs:

* Add a way to manually trigger MetricsService::StartInitTask() once the user
  has entered the enrollment screen, bypassing the usual delay of 30 seconds
  (kInitializationDelaySeconds).
* Expose MetricsReportingScheduler::TriggerUpload() to be callable externally
  and call it after enrollment has completed.
* Add a callback parameter to TriggerUpload() for notification when upload
  has completed so that the "enrollment success" screen can be shown.
  (Probably we'd time out after 10-20 seconds and show the "enrollment
  success" screen anyways.)

Does that make sense or would you suggest a different approach?

tnagel: Those code changes makes sense to me. Happy to review the code.

Since we can't upload stats blindly when we don't have policy data, and that's one case of enrollment failure, then the data will be biased regardless.

One possibility to implement this would be to upload only in cases when we have policy data. Currently I think it would not help much in correcting the data. Lowering the priority to P3.