Reland of Move language pak files to assets.

Reland of Move language pak files to assets.

Reverted by:
https://codereview.chromium.org/2369683002/

Reason for reland:
I've reworked it so that:
1. The list of pak files to extract are not set on start-up, but rather lazy initialized
2. This is done by putting the list of locale assets right in base's BuildConfig.java
3. Downstream parts have been upstreams so that this won't require a 2-sided patch

Language pak files were moved to res/raw when split apks was being implemented.
Moving them to assets with a java constant keeping track of pak file locations
will improve lookup time and save some space (no more xml files and
resources.arsc).

Other notables:
- .pak filenames no longer mangled. No more .lpak. no more hyphens to _s
- Ensures that monochrome doesn't extract files by extracting only when
files are compressed.

BUG=529604
Committed: https://crrev.com/67101cd0338a409d80689b9c9c875c95ccde7957
Cr-Commit-Position: refs/heads/master@{#422836}

[agrieve, 2016-09-26 18:19:31]

Created Reland of Move language pak files to assets.

[michaelbai, 2016-09-26 18:32:13]

agrieve@

I always upload the reverted patch as ps#1, and the fix as ps#2, so the
difference could be figure out easily, could you help to point where the
difference is?

[agrieve, 2016-09-26 20:30:33]

On 2016/09/26 18:32:13, michaelbai wrote:
> agrieve@
> 
> I always upload the reverted patch as ps#1, and the fix as ps#2, so the
> difference could be figure out easily, could you help to point where the
> difference is?

This is still PS1. I'll update the commit description to not say "Will update
once changed." once I figure out what PS2 should be :)

[nyquist, 2016-09-26 20:45:01]

Yeah, an update to this CL to point to where the changes are would be great.

[agrieve, 2016-09-26 21:01:13]

On 2016/09/26 20:45:01, nyquist wrote:
> Yeah, an update to this CL to point to where the changes are would be great.

PS1 here is the reland with no changes (the "original"). Still need to write
PS2.

[agrieve, 2016-09-28 20:07:37]

Description was changed from

==========
Reland of Move language pak files to assets. (patchset #1 id:1 of
https://codereview.chromium.org/2369683002/ )

Reason for revert:
Will update once changed.

Original issue's description:
> Revert of Move language pak files to assets. (patchset #13 id:240001 of
https://codereview.chromium.org/2345143002/ )
> 
> Reason for revert:
> Broke the internal build,
https://uberchromegw.corp.google.com/i/internal.client.clank_tot/builders/ins...
> 
> Original issue's description:
> > Move language pak files to assets.
> >
> > Language pak files were moved to res/raw when split apks was being
implemented.
> > Moving them to assets with a java constant keeping track of pak file
locations
> > will improve lookup time and save some space (no more xml files and
> > resources.arsc).
> >
> > BUG=529604
> >
> > Committed: https://crrev.com/34ae27889dd8c8ffd5f5ca8c7bc10c17e57c12e2
> > Cr-Commit-Position: refs/heads/master@{#420641}
> 
>
TBR=agrieve@chromium.org,michaelbai@chromium.org,nyquist@chromium.org,tedchoc...
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=529604
> 
> Committed: https://crrev.com/32fceb36f0e9129cf6022e3aac344fd601144df7
> Cr-Commit-Position: refs/heads/master@{#420791}

TBR=michaelbai@chromium.org,nyquist@chromium.org,tedchoc@chromium.org,esteven...
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=529604
==========

to

==========
Reland of Move language pak files to assets.

Reverted by:
https://codereview.chromium.org/2369683002/

Reason for reland:
I've reworked it so that:
1. The list of pak files to extract are not set on start-up, but rather lazy
initialized
2. Downstream parts have been upstreams so that this won't require a 2-sided
patch

Language pak files were moved to res/raw when split apks was being implemented.
Moving them to assets with a java constant keeping track of pak file locations
will improve lookup time and save some space (no more xml files and
resources.arsc).

BUG=529604
==========

[agrieve, 2016-09-28 20:10:30]

Description was changed from

==========
Reland of Move language pak files to assets.

Reverted by:
https://codereview.chromium.org/2369683002/

Reason for reland:
I've reworked it so that:
1. The list of pak files to extract are not set on start-up, but rather lazy
initialized
2. Downstream parts have been upstreams so that this won't require a 2-sided
patch

Language pak files were moved to res/raw when split apks was being implemented.
Moving them to assets with a java constant keeping track of pak file locations
will improve lookup time and save some space (no more xml files and
resources.arsc).

BUG=529604
==========

to

==========
Reland of Move language pak files to assets.

Reverted by:
https://codereview.chromium.org/2369683002/

Reason for reland:
I've reworked it so that:
1. The list of pak files to extract are not set on start-up, but rather lazy
initialized
2. Downstream parts have been upstreams so that this won't require a 2-sided
patch

Language pak files were moved to res/raw when split apks was being implemented.
Moving them to assets with a java constant keeping track of pak file locations
will improve lookup time and save some space (no more xml files and
resources.arsc).

Other notables:
- .pak filenames no longer mangled. No more .lpak. no more hyphens to _s
- Ensures that monochrome doesn't extract files by extracting only when
files are compressed.

BUG=529604
==========

[agrieve, 2016-09-28 20:13:26]

Description was changed from

==========
Reland of Move language pak files to assets.

Reverted by:
https://codereview.chromium.org/2369683002/

Reason for reland:
I've reworked it so that:
1. The list of pak files to extract are not set on start-up, but rather lazy
initialized
2. Downstream parts have been upstreams so that this won't require a 2-sided
patch

Language pak files were moved to res/raw when split apks was being implemented.
Moving them to assets with a java constant keeping track of pak file locations
will improve lookup time and save some space (no more xml files and
resources.arsc).

Other notables:
- .pak filenames no longer mangled. No more .lpak. no more hyphens to _s
- Ensures that monochrome doesn't extract files by extracting only when
files are compressed.

BUG=529604
==========

to

==========
Reland of Move language pak files to assets.

Reverted by:
https://codereview.chromium.org/2369683002/

Reason for reland:
I've reworked it so that:
1. The list of pak files to extract are not set on start-up, but rather lazy
initialized
2. This is done by putting the list of locale assets right in base's
BuildConfig.java
3. Downstream parts have been upstreams so that this won't require a 2-sided
patch

Language pak files were moved to res/raw when split apks was being implemented.
Moving them to assets with a java constant keeping track of pak file locations
will improve lookup time and save some space (no more xml files and
resources.arsc).

Other notables:
- .pak filenames no longer mangled. No more .lpak. no more hyphens to _s
- Ensures that monochrome doesn't extract files by extracting only when
files are compressed.

BUG=529604
==========

[agrieve, 2016-09-29 17:59:01]

On 2016/09/26 21:01:13, agrieve wrote:
> On 2016/09/26 20:45:01, nyquist wrote:
> > Yeah, an update to this CL to point to where the changes are would be great.
> 
> PS1 here is the reland with no changes (the "original"). Still need to write
> PS2.

👔👔 This is now good to go! PTAL.

[estevenson, 2016-09-29 18:02:27]

lgtm, much cleaner than my attempt :)

https://codereview.chromium.org/2371843002/diff/330001/build/android/resource...
File build/android/resource_sizes.py (right):

https://codereview.chromium.org/2371843002/diff/330001/build/android/resource...
build/android/resource_sizes.py:193: lambda f: 'en_' in f),
Should this be 'en-' now that we've removed locale_pak_resources.py?

[agrieve, 2016-09-29 19:09:34]

https://codereview.chromium.org/2371843002/diff/330001/build/android/resource...
File build/android/resource_sizes.py (right):

https://codereview.chromium.org/2371843002/diff/330001/build/android/resource...
build/android/resource_sizes.py:193: lambda f: 'en_' in f),
On 2016/09/29 18:02:27, estevenson wrote:
> Should this be 'en-' now that we've removed locale_pak_resources.py?

Nice catch! Done.

[michaelbai, 2016-09-29 20:47:05]

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
File base/android/java/src/org/chromium/base/ResourceExtractor.java (right):

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
base/android/java/src/org/chromium/base/ResourceExtractor.java:184: for (String
pakFileName : BuildConfig.COMPRESSED_ASSETS) {
Do we still have pak file compressed?

[agrieve, 2016-09-30 00:04:37]

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
File base/android/java/src/org/chromium/base/ResourceExtractor.java (right):

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
base/android/java/src/org/chromium/base/ResourceExtractor.java:184: for (String
pakFileName : BuildConfig.COMPRESSED_ASSETS) {
On 2016/09/29 20:47:05, michaelbai wrote:
> Do we still have pak file compressed?

For Chrome.apk, yes. Not for Monochrome nor webview. (see
//chrome/android:chrome_public_locale_pak_assets in this patch)

[michaelbai, 2016-09-30 00:10:39]

lgtm

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
File base/android/java/src/org/chromium/base/ResourceExtractor.java (right):

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
base/android/java/src/org/chromium/base/ResourceExtractor.java:184: for (String
pakFileName : BuildConfig.COMPRESSED_ASSETS) {
On 2016/09/30 00:04:37, agrieve wrote:
> On 2016/09/29 20:47:05, michaelbai wrote:
> > Do we still have pak file compressed?
> 
> For Chrome.apk, yes. Not for Monochrome nor webview. (see
> //chrome/android:chrome_public_locale_pak_assets in this patch)

Oh, right, Chrome still uses compressed pak.

[Ted C, 2016-09-30 17:03:16]

lgtm

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
File base/android/java/src/org/chromium/base/LocaleUtils.java (right):

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
base/android/java/src/org/chromium/base/LocaleUtils.java:35: * Android
deprecated languages codes into modern ones used by Chromium.
we wrap javadocs at a 100 chars normally, and we should align following lines
with the beginning of the part after the annotation ("the language for ...")

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
File base/android/java/src/org/chromium/base/ResourceExtractor.java (right):

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
base/android/java/src/org/chromium/base/ResourceExtractor.java:178: &&
".-".indexOf(pakFileName.charAt(language.length())) != -1;
puts on the ol' paranoid hat, should we do pakFileName.length() >
language.length()?

And while this is more concise, I think something like this is clearer to read:

if (!pakFileName.startsWith(language) || pakFileName.length() <=
language.length()) {
    return false;
}
char c = pakFileName.charAt(language.length());
return c == '.' || c == '-';

Seems clearer to me, but I'll defer to you.

https://codereview.chromium.org/2371843002/diff/350001/chrome/android/java/sr...
File chrome/android/java/src/org/chromium/chrome/browser/ChromeApplication.java
(left):

https://codereview.chromium.org/2371843002/diff/350001/chrome/android/java/sr...
chrome/android/java/src/org/chromium/chrome/browser/ChromeApplication.java:181:
protected void initializeLibraryDependencies() {
Oooohh...can we remove this method from ContentApplication now?  Can we please
:-)

The only usage now is ContentShellApplication and the
PathUtils.setPrivateDataDirectorySuffix should be able to move to onCreate w/o
impact.

[nyquist, 2016-10-03 04:53:59]

lgtm

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
File base/android/java/src/org/chromium/base/ResourceExtractor.java (right):

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
base/android/java/src/org/chromium/base/ResourceExtractor.java:171:
sInstance.mAssetsToExtract = detectFilesToExtract();
Nit: Could you add a comment as to why is this initialized here instead of in
the constructor (because it could then be final)?

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
base/android/java/src/org/chromium/base/ResourceExtractor.java:178: &&
".-".indexOf(pakFileName.charAt(language.length())) != -1;
On 2016/09/30 17:03:15, Ted C wrote:
> puts on the ol' paranoid hat, should we do pakFileName.length() >
> language.length()?
> 
> And while this is more concise, I think something like this is clearer to
read:
> 
> if (!pakFileName.startsWith(language) || pakFileName.length() <=
> language.length()) {
>     return false;
> }
> char c = pakFileName.charAt(language.length());
> return c == '.' || c == '-';
> 
> Seems clearer to me, but I'll defer to you.

I agree with Ted here. It's not as readable as it is right now.

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
base/android/java/src/org/chromium/base/ResourceExtractor.java:183:
ArrayList<String> activeLocalePakFiles = new ArrayList<String>(5);
Nit: Care to add a tiny comment in case future readers also want to know why you
used 5 as the initial size?

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
base/android/java/src/org/chromium/base/ResourceExtractor.java:190: return
activeLocalePakFiles.toArray(new String[0]);
Tiny nit: Since this happens early, and we already know it, could we just do new
String[activeLocalePakFiles.size()] here? Otherwise we create a throw-away
object, and some other unnecessary stuff. With a correctly sized array, I think
we can use System.arraycopy.

https://codereview.chromium.org/2371843002/diff/350001/chrome/android/BUILD.gn
File chrome/android/BUILD.gn (right):

https://codereview.chromium.org/2371843002/diff/350001/chrome/android/BUILD.g...
chrome/android/BUILD.gn:573: disable_compression = true
Tiny nit: for the other target, we put this right after sources, but before
deps. Should we aim to be consistent?

[agrieve, 2016-10-03 20:10:17]

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
File base/android/java/src/org/chromium/base/LocaleUtils.java (right):

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
base/android/java/src/org/chromium/base/LocaleUtils.java:35: * Android
deprecated languages codes into modern ones used by Chromium.
On 2016/09/30 17:03:15, Ted C wrote:
> we wrap javadocs at a 100 chars normally, and we should align following lines
> with the beginning of the part after the annotation ("the language for ...")

Done.

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
File base/android/java/src/org/chromium/base/ResourceExtractor.java (right):

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
base/android/java/src/org/chromium/base/ResourceExtractor.java:171:
sInstance.mAssetsToExtract = detectFilesToExtract();
On 2016/10/03 04:53:59, nyquist wrote:
> Nit: Could you add a comment as to why is this initialized here instead of in
> the constructor (because it could then be final)?

Made it final.

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
base/android/java/src/org/chromium/base/ResourceExtractor.java:178: &&
".-".indexOf(pakFileName.charAt(language.length())) != -1;
On 2016/09/30 17:03:15, Ted C wrote:
> puts on the ol' paranoid hat, should we do pakFileName.length() >
> language.length()?
> 
> And while this is more concise, I think something like this is clearer to
read:
> 
> if (!pakFileName.startsWith(language) || pakFileName.length() <=
> language.length()) {
>     return false;
> }
> char c = pakFileName.charAt(language.length());
> return c == '.' || c == '-';
> 
> Seems clearer to me, but I'll defer to you.

Done.

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
base/android/java/src/org/chromium/base/ResourceExtractor.java:183:
ArrayList<String> activeLocalePakFiles = new ArrayList<String>(5);
On 2016/10/03 04:53:59, nyquist wrote:
> Nit: Care to add a tiny comment in case future readers also want to know why
you
> used 5 as the initial size?

Done.

https://codereview.chromium.org/2371843002/diff/350001/base/android/java/src/...
base/android/java/src/org/chromium/base/ResourceExtractor.java:190: return
activeLocalePakFiles.toArray(new String[0]);
On 2016/10/03 04:53:59, nyquist wrote:
> Tiny nit: Since this happens early, and we already know it, could we just do
new
> String[activeLocalePakFiles.size()] here? Otherwise we create a throw-away
> object, and some other unnecessary stuff. With a correctly sized array, I
think
> we can use System.arraycopy.

Done.

https://codereview.chromium.org/2371843002/diff/350001/chrome/android/BUILD.gn
File chrome/android/BUILD.gn (right):

https://codereview.chromium.org/2371843002/diff/350001/chrome/android/BUILD.g...
chrome/android/BUILD.gn:573: disable_compression = true
On 2016/10/03 04:53:59, nyquist wrote:
> Tiny nit: for the other target, we put this right after sources, but before
> deps. Should we aim to be consistent?

Done.

https://codereview.chromium.org/2371843002/diff/350001/chrome/android/java/sr...
File chrome/android/java/src/org/chromium/chrome/browser/ChromeApplication.java
(left):

https://codereview.chromium.org/2371843002/diff/350001/chrome/android/java/sr...
chrome/android/java/src/org/chromium/chrome/browser/ChromeApplication.java:181:
protected void initializeLibraryDependencies() {
On 2016/09/30 17:03:15, Ted C wrote:
> Oooohh...can we remove this method from ContentApplication now?  Can we please
> :-)
> 
> The only usage now is ContentShellApplication and the
> PathUtils.setPrivateDataDirectorySuffix should be able to move to onCreate w/o
> impact.

Done \o/

[agrieve, 2016-10-03 20:10:24]

The CQ bit was checked by agrieve@chromium.org

[agrieve, 2016-10-03 20:10:25]

The patchset sent to the CQ was uploaded after l-g-t-m from
estevenson@chromium.org, michaelbai@chromium.org, nyquist@chromium.org,
tedchoc@chromium.org
Link to the patchset: https://codereview.chromium.org/2371843002/#ps370001
(title: "nyquist & tedchoc comments")

[commit-bot: I haz the power, 2016-10-03 20:10:57]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-03 20:14:06]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-03 20:14:08]

Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[agrieve, 2016-10-04 14:06:28]

The CQ bit was checked by agrieve@chromium.org

[agrieve, 2016-10-04 14:06:29]

The patchset sent to the CQ was uploaded after l-g-t-m from
michaelbai@chromium.org, nyquist@chromium.org, estevenson@chromium.org,
tedchoc@chromium.org
Link to the patchset: https://codereview.chromium.org/2371843002/#ps390001
(title: "rebase")

[commit-bot: I haz the power, 2016-10-04 14:06:49]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-04 15:30:36]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-04 15:30:37]

Exceeded global retry quota

[agrieve, 2016-10-04 15:43:46]

The CQ bit was checked by agrieve@chromium.org

[commit-bot: I haz the power, 2016-10-04 15:44:11]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[agrieve, 2016-10-04 16:19:15]

The CQ bit was checked by agrieve@chromium.org

[agrieve, 2016-10-04 16:19:16]

The patchset sent to the CQ was uploaded after l-g-t-m from
michaelbai@chromium.org, nyquist@chromium.org, estevenson@chromium.org,
tedchoc@chromium.org
Link to the patchset: https://codereview.chromium.org/2371843002/#ps410001
(title: "Fix ContentShell context setPrivateDataPrefix that was breaking tests")

[commit-bot: I haz the power, 2016-10-04 16:19:45]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-04 17:14:51]

Description was changed from

==========
Reland of Move language pak files to assets.

Reverted by:
https://codereview.chromium.org/2369683002/

Reason for reland:
I've reworked it so that:
1. The list of pak files to extract are not set on start-up, but rather lazy
initialized
2. This is done by putting the list of locale assets right in base's
BuildConfig.java
3. Downstream parts have been upstreams so that this won't require a 2-sided
patch

Language pak files were moved to res/raw when split apks was being implemented.
Moving them to assets with a java constant keeping track of pak file locations
will improve lookup time and save some space (no more xml files and
resources.arsc).

Other notables:
- .pak filenames no longer mangled. No more .lpak. no more hyphens to _s
- Ensures that monochrome doesn't extract files by extracting only when
files are compressed.

BUG=529604
==========

to

==========
Reland of Move language pak files to assets.

Reverted by:
https://codereview.chromium.org/2369683002/

Reason for reland:
I've reworked it so that:
1. The list of pak files to extract are not set on start-up, but rather lazy
initialized
2. This is done by putting the list of locale assets right in base's
BuildConfig.java
3. Downstream parts have been upstreams so that this won't require a 2-sided
patch

Language pak files were moved to res/raw when split apks was being implemented.
Moving them to assets with a java constant keeping track of pak file locations
will improve lookup time and save some space (no more xml files and
resources.arsc).

Other notables:
- .pak filenames no longer mangled. No more .lpak. no more hyphens to _s
- Ensures that monochrome doesn't extract files by extracting only when
files are compressed.

BUG=529604
==========

[commit-bot: I haz the power, 2016-10-04 17:14:52]

Committed patchset #9 (id:410001)

[commit-bot: I haz the power, 2016-10-04 17:21:55]

Description was changed from

==========
Reland of Move language pak files to assets.

Reverted by:
https://codereview.chromium.org/2369683002/

Reason for reland:
I've reworked it so that:
1. The list of pak files to extract are not set on start-up, but rather lazy
initialized
2. This is done by putting the list of locale assets right in base's
BuildConfig.java
3. Downstream parts have been upstreams so that this won't require a 2-sided
patch

Language pak files were moved to res/raw when split apks was being implemented.
Moving them to assets with a java constant keeping track of pak file locations
will improve lookup time and save some space (no more xml files and
resources.arsc).

Other notables:
- .pak filenames no longer mangled. No more .lpak. no more hyphens to _s
- Ensures that monochrome doesn't extract files by extracting only when
files are compressed.

BUG=529604
==========

to

==========
Reland of Move language pak files to assets.

Reverted by:
https://codereview.chromium.org/2369683002/

Reason for reland:
I've reworked it so that:
1. The list of pak files to extract are not set on start-up, but rather lazy
initialized
2. This is done by putting the list of locale assets right in base's
BuildConfig.java
3. Downstream parts have been upstreams so that this won't require a 2-sided
patch

Language pak files were moved to res/raw when split apks was being implemented.
Moving them to assets with a java constant keeping track of pak file locations
will improve lookup time and save some space (no more xml files and
resources.arsc).

Other notables:
- .pak filenames no longer mangled. No more .lpak. no more hyphens to _s
- Ensures that monochrome doesn't extract files by extracting only when
files are compressed.

BUG=529604

Committed: https://crrev.com/67101cd0338a409d80689b9c9c875c95ccde7957
Cr-Commit-Position: refs/heads/master@{#422836}
==========

[commit-bot: I haz the power, 2016-10-04 17:21:57]

Patchset 9 (id:??) landed as
https://crrev.com/67101cd0338a409d80689b9c9c875c95ccde7957
Cr-Commit-Position: refs/heads/master@{#422836}