Probably worth linking to issue 866739 (which fixed versionName).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cee16261e5882721569635eae11831ef425c7574

commit cee16261e5882721569635eae11831ef425c7574
Author: Nate Fischer <ntfschr@chromium.org>
Date: Wed Dec 19 21:44:02 2018

Android: allow apk downgrades

This changes Generated Wrapper Scripts and other dev tools to support
APK downgrades by default. Anywhere we support reinstall by default, we
should probably also default to allowing downgrades.

This does not re-expose the no-downgrades-allowed behavior as an
optional flag, although that could be a reasonable follow-up.

Note: this does not allow downgrades on user builds, but
"allow_downgrade" is otherwise harmless to pass (the install acts as if
allow_downgrade was not specified).

R=agrieve@chromium.org

Bug:  915431 
Test: out/Default/bin/monochrome_apk install # with versionCode=2 && \
Test: out/Default/bin/chrome_modern_apk install # with versionCode=1
Change-Id: I0071af6fccc6839f3e78e525fe169f99f9f16065
Reviewed-on: https://chromium-review.googlesource.com/c/1383575
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: agrieve <agrieve@chromium.org>
Commit-Queue: Nate Fischer <ntfschr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#617960}
[modify] https://crrev.com/cee16261e5882721569635eae11831ef425c7574/build/android/apk_operations.py
[modify] https://crrev.com/cee16261e5882721569635eae11831ef425c7574/build/android/incremental_install/installer.py
[modify] https://crrev.com/cee16261e5882721569635eae11831ef425c7574/build/android/pylib/local/device/local_device_gtest_run.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/998d35d58407c82bf96ca1bd11bb49ccc8c5fa29

commit 998d35d58407c82bf96ca1bd11bb49ccc8c5fa29
Author: Andrew Luo <aluo@chromium.org>
Date: Sat Dec 22 01:51:04 2018

Calculate more sensible default chrome and webview apk version codes.

Bug:  915431 
Change-Id: Ie4d1e173bddf3fd8a166ff31886331a165c5a625
Test: aapt dump badging out/Debug/apks/SystemWebView.apk | egrep "version"
Reviewed-on: https://chromium-review.googlesource.com/c/1379311
Commit-Queue: Andrew Luo <aluo@chromium.org>
Reviewed-by: agrieve <agrieve@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Nate Fischer <ntfschr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#618709}
[modify] https://crrev.com/998d35d58407c82bf96ca1bd11bb49ccc8c5fa29/android_webview/system_webview_apk_tmpl.gni
[modify] https://crrev.com/998d35d58407c82bf96ca1bd11bb49ccc8c5fa29/build/config/android/chrome_version.gni
[modify] https://crrev.com/998d35d58407c82bf96ca1bd11bb49ccc8c5fa29/build/config/android/config.gni
[modify] https://crrev.com/998d35d58407c82bf96ca1bd11bb49ccc8c5fa29/build/config/android/rules.gni
[modify] https://crrev.com/998d35d58407c82bf96ca1bd11bb49ccc8c5fa29/build/util/version.gni
[modify] https://crrev.com/998d35d58407c82bf96ca1bd11bb49ccc8c5fa29/chrome/android/BUILD.gn
[modify] https://crrev.com/998d35d58407c82bf96ca1bd11bb49ccc8c5fa29/chrome/android/chrome_public_apk_tmpl.gni
[modify] https://crrev.com/998d35d58407c82bf96ca1bd11bb49ccc8c5fa29/chrome/android/modules/ar/ar_module_tmpl.gni
[modify] https://crrev.com/998d35d58407c82bf96ca1bd11bb49ccc8c5fa29/chrome/android/modules/vr/vr_module_tmpl.gni
[modify] https://crrev.com/998d35d58407c82bf96ca1bd11bb49ccc8c5fa29/chrome/android/trichrome.gni

Is this actually fixed? I didn't see a change land for the downstream chrome targets (or to clean up the official-build-specific logic).

it's fixed for the upstream part, just opened the bug to track the downstream part in crbug/919636, thanks for following up.

To verify:

aapt dump xmltree <apk file> AndroidManifest.xml | grep "android:version"

The versionName should be same as the version number
The versionCode should be <4 digit build><3 digit patch><A><B>

A: 0 - arm
   1 - x86
   2 - mips
   5 - arm 64
   6 - x86 64

B: 0 - webview and chrome
   1 - chrome modern
   2 - monochrome

for example,  71.0.3578.99 arm64 monochrome apk's versionCode would be: 
357809952

^ I don't think QA should manually verify yet, since they typically use official builds (which won't benefit from your CL until issue 919636).

For what it's worth, I manually verified a couple of the upstream targets.

Correct, the official build is not relying on the version code generated by this fix. 

Right now the above should only be used in public upstream builds, thanks for verifying.

There still a little bit of value to verify that the official build version codes still conform to c10, otherwise it would mean the changes to the upstream gn files have somehow broken the current downstream build target logic.

Please use this command to verify version code instead of the one in c10:

aapt dump badging <apk path> | grep version

No manual verification as per #11. Please add the steps if QA can  manually verify it.