Moving certain Chrome features into a Dynamic Feature APK, as described in [1], requires splitting said code from the base libchrome.so native library, into its own libfeature.so, which will end up packaged into a separate APK, as in:

  base.apk/
     lib/arm/libchrome.so

  feature_split.apk/
     lib/arm/libfeature.so

It is also _very_ likely that the libfeature.so source code will depend and use Chrome components that require a single implementation per process (e.g. base task scheduling, thread-local storage, cc/ and more).

This requires, at a minimum that, for a regular build:

1) libchrome.so exports all the symbols required by libfeature.so.
   
   Currently, nearly all symbol exports are removed from libchrome.so
   to reduce its size, since C++ symbols add over 80 MiB to the size
   of the library!

2) libfeature.so must be linked against the unstripped version of
   libchrome.so, to ensure it correctly imports the symbols it needs.

3) Our build system must understand if a GN "component" belongs to
   libchrome.so or libfeature.so (or even libfeature2.so,
   libfeature3.so, etc).

   In particular, a component build should ignore the separation,
   while a regular one should be able to link each component's static
   library into only one of the final .so

IMPORTANT NOTE:

  THERE IS NO PLAN TO SUPPORT A STABLE libchrome.so ABI OR LIST
  OF SYMBOLS.

The idea is to generate, at build time, the minimal set of required exported symbols from libchrome.so, from all the separate libfeature<N>.so required by the build configuration.

Also, for now, there is no plan to have inter-feature dependencies, i.e. each libfeatureN.so should only depend on libchrome.so

This bug is to track the issue, and start by implementing a small proof of concept that will explore the feasibility, i.e.:

- What modifications to the build system are needed to ensure that
  this works (and under which conditions / build configurations).

- Ensure that no C++ ODR violation become possible with this scheme
  (in theory, this can be achieved by ensuring that template
  instantiations in libfeature.so are weak symbols, and those in
  libchrome.so are strong symbols).

- See whether it is possible to ensure that some GN components still
  be duplicated in both libfeature.so and libchrome.so, mainly for
  the sake of reducing the list of exported libchrome.so (if it 
  becomes too wild). However, this would require *manual* review of
  the affected code to ensure that it doesn't depend on global state
  that is already handled concurrently by libchrome.so.


[1] https://developer.android.com/guide/app-bundle/