Drop KitKat support

[DanAlbert]

Description

This will be added to changelogs as appropriate, but filing as an announcement that this is on our near term schedule. The current plan is for NDK r25 (2022 LTS) to be the last release that supports KitKat (APIs 19 and 20). NDK r26 (2023 LTS, so not until next summer) will not support minSdkVersions below 21 (Lollipop). Exact releases are subject to change if we discover unexpected costs.

Dropping KitKat will have greater benefits than the other API levels we've dropped support for over the years (and while not the only reason, one motivation for the prior support removals was getting us closer to being able to drop 19/20):

1. libandroid_support will no longer be needed.
   1. libandroid_support adds to the APK size for all apps. Even if your minSdkVersion is 21+, libc++ is built for the lowest API level supported by the NDK, so it includes some pieces of libandroid_support.
   2. libandroid_support subtly alters the behavior of some libc functions.
   3. libandroid_support prevents APIs from being exposed as weak symbols for APIs in libc. libandroid_support requires preprocessing those headers to add explicit #if __ANDROID_API__ >= ... guards around APIs that makes even the weak symbols mode unable to see those APIs.
   4. libandroid_support would need to be upstreamed to LLVM to improve libc++ maintainability. I doubt LLVM wants that mess.
   5. libandroid_support prevents good diagnostics from being emitted for some APIs. libandroid_support's only goal is to make libc++ usable for API levels older than 21. Sometimes this means it provides a decl but no implementation. When libc++ is not used (rare for C++ apps), the libandroid_support headers are still used even if the library will not be linked. In either of these cases, the build will have a linker error rather than a compile error, which is misleading.
   6. libandroid_support complicates build system implementations.
2. libc received insufficient investment before API 21. Dropping KitKat support should enable removal of old workarounds in NDK and user code. Rust in particular has many workarounds for KitKat that they're keen to drop.
3. Testing will benefit. Devices old enough to run KitKat are dying out, and emulation of those is not reliable IME.
4. Behavioral differences between ABIs will be reduced. 64-bit code has always had a minSdkVersion of 21, regardless of the app's actual minSdkVersion, as that was the first API level that supported 64-bit. Compiling all the ABIs in the app with the same minSdkVersion (especially since none will need libandroid_support as a result) will reduce behavioral fragmentation.

Changes implementing this support removal will land in our development branches very soon so we can continue working on testing weak symbol APIs, and verify that there are no unexpected consequences to dropping libandroid_support.

The cost of this change is that apps compiled using NDK r26+ will have a maximum reach <1% smaller. APIs 19 and 20 comprise less than 1% of the device population today, and that is expected to drop more by the time r26 is a stable release (about a year from now). This will likely mean a lower proportional impact than even the other API level drops we've done in the past, with stronger benefits than those earlier support removals. If KitKat users are critical to your app, you will need to continue using NDK r25 to reach those users, but note that r25 reached EOL some time next summer (not before 13 July 2023).

[enh-google]

1 iii isn't that many though, right, and mostly uninteresting stuff?

$ nm libandroid_support.a | grep -w T
00000000 T c32rtomb
00000000 T duplocale
00000000 T freelocale
00000000 T localeconv
00000000 T newlocale
00000000 T setlocale
00000000 T uselocale
00000000 T _Z22__ctype_get_mb_cur_maxv
00000000 T mbrtoc32
00000000 T mbrtowc
00000000 T mbsinit
00000000 T mbsnrtowcs
00000000 T mbsrtowcs
00000000 T wcrtomb
00000000 T wcsnrtombs
00000000 T wcsrtombs
00000000 T mbtowc
00000000 T wcstombs
00000000 T mbstowcs
00000000 T strtold_l
00000000 T strtoll_l
00000000 T strtoull_l
00000000 T swprintf
00000000 T vswprintf
00000000 T wcstod
00000000 T wcstof
00000000 T wcstoimax
00000000 T wcstol
00000000 T wcstoll
00000000 T wcstoul
00000000 T wcstoull
00000000 T wcstoumax

if you drop the wcs* stuff and the locale stuff, you're left with just the utf-8 <-> wchar_t stuff:

00000000 T c32rtomb
00000000 T mbrtoc32
00000000 T mbrtowc
00000000 T mbsinit
00000000 T mbsnrtowcs
00000000 T mbsrtowcs
00000000 T wcrtomb
00000000 T wcsnrtombs
00000000 T wcsrtombs
00000000 T mbtowc
00000000 T wcstombs
00000000 T mbstowcs

that's probably the least motivating item on the list?

[DanAlbert]

I actually explained that poorly. Because of the APIs in libandroid_support, we can't support weak APIs for anything in libc (because it all goes through versioner, which adds guards for everything).

[DanAlbert]

Reworded that bullet point so it's more accurate.

[truboxl]

I guess #1651 is no longer being worked on?

[DanAlbert]

Had missed that one. Closed. Thanks!