I don't think this needs RVG. Making public.

I will work on this bug with some guidance from Charles

here's an example for how wallpaper solves a similar problem:
platform2/login_manager/chrome_setup.cc

schema:
wallpaper attribute in cros_config_schema.yaml

actual binary payloads:
chromeos-assets/wallpaper

I'll give it a try.

This issue is harder to solve than wallpaper.
Because:
(1) At build time, we don't know which model the image is for.
So we have to install the regulatory labels for all models into the image, (/usr/share/chromeos-assets/regulatory_labels/*).
(2) At runtime, we determine which model it is and then pass the correct image/text path for regulatory labels to Chrome via a command-line flag.
However, there is no existing flag for regulatory label.

So:
If we want to add a flag to chromeos_switches, we need to fix both internal/external Chrome.
It's probably easier to work with a Chrome SWE?

Or is there an easier way to avoid the need of modifying Chrome code?  

Unless I'm missing something, this scenario is exactly the same as the one for wallpaper (apart from the fact that Chrome already had wallpaper flags when unibuild support was added). A Chrome change will likely be needed here in any case if there's no flag yet.

Is a flag really the best way to do this?

If so, it doesn't need to be the full path -- just the directory name for the model. What do model names look like?

> Is a flag really the best way to do this?

Is there another approach? All I can think of is making Chrome link against the chromeos-config library so it can get the model name itself. That's probably possible, but I'm not sure how much work it'll be, and it may make it harder to test this code (either manually or in an automated fashion).

we already expose customization id value to chrome.

i'd vote on following this value versus introducing anything new.

this is what drives default apps for unified builds.

Charles, could you point me to the code where we expose model name to Chrome?

Oh, I see how per-model default app is supported.
We Chrome code always checks '/var/cache/arc_default_apps', which is sym-linked to '/usr/share/google-chrome/extensions/arc/BOARD' at arc_setup time.

Back to this issue, to solve it without touching Chrome code at all, we may similarly create symlinks under '/usr/share/chromeos-assets/regulatory_labels/' and point them to /usr/share/chromeos-assets/regulatory_labels/MODEL/*.

I'll work on it soon.

That is for android default apps.

For chrome default apps, the following bug provides some context and code links:
https://b.corp.google.com/issues/69125404

I posted the CL here:
https://chromium-review.googlesource.com/c/chromiumos/platform2/+/1427239

However, as Dan pointed out in the review, we can't create symlink in /usr/share/chromeos-assets/regulatory_labels/' so this route won't work.

Thus, I think we can't implement per-model e-label without touching private Chrome code here:
https://cs.corp.google.com/clankium/src/chrome/browser/ui/webui/settings/about_handler.cc

I can think of two options.

(1) We use customization_id as the directory name for model-specific e-label files.
e.g.: In /usr/share/chromeos-assets/regulatory_labels/, the file system tree should looks like

--customization_id1--region_1--label.png
                             --label.txt
                   --region_2--label.png
                             --label.txt

--customization_id2--region_1--label.png
                             --label.txt
                   --region_2--label.png
                             --label.txt

And Chrome can find cutomization_id from /tmp/machine-info.
If we go this route, we don't need to touch Chrome/chromium OS code at all.
Only Chrome code needs to be modified.

(2) We can still introduce a new attribute 'regulatory-label' to cros_config_schema.yaml and use it as the the directory name for model-specific e-label files.
But we still need to modify Chrome code.

Any thoughts?