Enabling language-based splits in app bundles has revealed several non-trivial bugs in the implementation that could not be caught using routine unit-tests / regression tests.

I believe this is due to several factors, but the most important one is that we don't yet have a way to properly check Chrome's behaviour when language-based splits are being used, because this would require a new kind of test where we would do something like:

- For each Chrome-supported locale (53 of them as of now) do the
  following:

     1) Change the system language setting of the connected device
        to the specific locale.

     2) Install the bundle (which should only install the base APK and
        the split corresponding to the selected locale).

        IMPORTANT: Ensure Chrome was un-installed before doing so.

     3) Verify that Chrome starts up correctly, and that it can access
        localized resources properly (e.g. look at the explicit values
        returned by Resources.getString() and the C++ .pak loader to
        verify that they are correct, and not some fallback values).

- For at least one locale supported by Android but *not* Chrome:

     1) Set the connected device to said locale.

     2) Verify that Chrome starts up correctly, and falls back to
        an appropriate locale, and that this fallback is consistent
        between Java and C++ (which use different storage schemes for
        the UI strings).

- Also deal with multi-language selections, and associated fallback
  mechanisms.

Ideally, we would want to be able to change the system's locale at runtime and see how Chrome would react to the change. Unfortunately, this use case depends on Play Store services interaction, and cannot be really tested locally (i.e. it requires specific bundles to be uploaded to the Play Store).

This looks like a different kind of regression test, because it requires modifying system settings at runtime during testing. Not sure how to achieve this yet, adding a few people on cc for comments.