Re: API levels and functions on Android

[Bruno Haible]

Paul Eggert wrote:
> > +  gl_CHECK_FUNCS_ANDROID([utimensat], [[#include <sys/stat.h>]])
> >     if test $ac_cv_func_utimensat = no; then
> >       HAVE_UTIMENSAT=0
> > +    REPLACE_UTIMENSAT=1
> 
> REPLACE_UTIMENSAT=1 means utimensat is present but broken and needs to 
> be replaced. However, $ac_cv_func_utimensat = no means utimensat is 
> absent. So I'm puzzled as to why REPLACE_UTIMENSAT=1 would be 
> appropriate here.

Deployment on Android is a bit special: When a developer compiles an app,
they specify an "API level". This API level designates the minimum Android
version on which the app will work. For example [1][2]:

  18 = Android 4.3
  19 = Android 4.4
  20 = Android 4.4W
  21 = Android 5.0
  22 = Android 5.1
  23 = Android 6.0
  24 = Android 7.0
  25 = Android 7.1
  26 = Android 8.0
  27 = Android 8.1
  28 = Android 9
  29 = Android 10
  30 = Android 11
  31 = Android 12
  32 = Android 12L
  33 = Android 13

Now, some functions get added to libc over time. For example, the glob and
globfree functions are being added in API level 28. So, when a developer
*compiles* for an API level < 28 but tests the app on a device with API level
≥ 28, the two functions will not be declared in the header files but will be
present in libc.

By the way the gl_CHECK_FUNCS_ANDROID macro works so far, when a function is
not declared, it reports it as "missing" (ac_cv_func_...=no). This is a good
approximation, and will usually work fine.

But there is a conflict: Gnulib, when ac_cv_func_glob=no, will define the
function 'glob' (not 'rpl_glob'), since Gnulib so far assumes that a build
is for one OS version. So, we can arrive at a situation where
  - the OS defines 'glob' in libc.so, and
  - the app defines 'glob' in its shared library.
By ELF rules, the 'glob' symbol from the app's shared library will override
the one from libc. Which is OK for the app. But some calls from within libc
might behave unexpectedly if they suddenly call the 'glob' function from the
app.

Defining REPLACE_GLOB=1 despite HAVE_GLOB=0 will be the way to make Gnulib
define 'rpl_glob' instead of 'glob', so that there is no conflict with libc.so.

I still need to work out the details how this would/will work. So as to
do things correctly on Android, while OTOH not adding lots of configure tests
for the other platforms...

Bruno

[1] https://developer.android.com/studio/releases/platforms
[2] https://apilevels.com/