There are several problematic patterns that have been used to check aspects of which Android version we're running on, especially when checking for still-unreleased platform versions, which have caused bugs when moving to final SDKs.

We should audit master to find and fix problematic usages, and introduce presubmit checks which try to make it harder for people to accidentally do the wrong thing.

Some examples of things which are (or may be in some cases) incorrect:

1) Testing the value of Build.VERSION.CODENAME. This is a fragile check typically used for in-development versions of the platform, which can easily break due to changes in Android.. This should not be used in general Chromium code at all - we should centralise all of these checks in the class BuildInfo (by having other code call BuildInfo.isAtLeastO() or similarly-named methods), so that when the 
exact check required changes it can be updated in a single place.

2) Some usages of Build.VERSION.SDK_INT; especially uses that compare to the latest platform version. This is trickier to explain, so here are some borderline examples given in the context of the present time, when the final O SDK is not yet available:

   2a) Build.VERSION.SDK_INT <  Build.VERSION_CODES.N_MR1
       This is fine, "older than N-MR1" is well-defined"

   2b) Build.VERSION.SDK_INT >= Build.VERSION_CODES.N_MR1
       Also fine, it's the inverse of 2a

   2c) Build.VERSION.SDK_INT >  Build.VERSION_CODES.N_MR1
       This is probably not OK. "newer than N-MR1" isn't well-defined until it's known which SDK_INT is O.

   2d) Build.VERSION.SDK_INT <= Build.VERSION_CODES.N_MR1
       Also not OK, it's the inverse of 2c

   2e) Build.VERSION.SDK_INT == Build.VERSION_CODES.N_MR1
       Also not OK, it's asserting "only N-MR1 has some property" which might not be true if an MR2 happens

When the comparison is to an "older" SDK version (not the latest public SDK) then it's probably fine, but for consistency it might be easiest to just ban some of these usages entirely and rewrite the ones that are okay to be in the "safer" forms.

It's also important never to compare to CUR_DEVELOPMENT (or any other constant which evaluates to the same value, 10000, for example the Build.VERSION_CODES.O constant in the developer preview SDK which is 10000).

3) Same as 2) but for native code using sdk_int() from the native BuildInfo class.

4) Checks for ApplicationInfo.targetSdkVersion similarly. These are in basically all cases only used in WebView since Chrome's targetSdkVersion isn't variable, but they need all the same caution/care. Checks for unreleased versions in targetSdkVersion should also be indirected via BuildInfo, not done by implementing complex checks in multiple places in the code.


I think it's okay to err on the side of being conservative, and have a presubmit which looks for any usage of the relevant Build.VERSION properties and whitelists only things we know are okay, maybe?