> What does the user end up downloading: an apk, or an aab?
Your phone still downloads APKs from the Play Store, but it's no longer a single monolithic APK that covers all languages/screen sizes/CPU architectures [1] supported by that app. Instead you'll get a collection of APKs covering your specfic device configuration only.
> If it's an aab, can they archive it for later, like you can with apks?
You can archive the individual APKs, although installing them again is a bit more complicated, as you either need a third-party app like https://f-droid.org/packages/com.aefyr.sai.fdroid/, or else install them via the correct incantation on the command line.
As for APK archive sites, presumably coverage of languages/screen sizes/CPU architectures with few users might get worse, as one user uploading an individual APK version will no longer be enough to automatically cover all languages/screen dimensions/etc. and instead you need to grab separate APKs for each possible language/screen size etc.
Getting the APK with the correct CPU architecture (where applicable) will of course be critical, although in practice almost everybody is probably using ARM these days, so there's not much to go wrong here (although if you still have a 32-bit device then you can only run the 32-bit APK, whereas the other way round a 64-bit device can run both 32- and 64-bit native code).
As for language and screen density, my guess would be that Android can fall back to whatever language and screen density APK actually has been installed (since this should be the same situation as when a monolithic APK doesn't contain the correct resources for your preferred language/screen density), so you might get a degraded experience (wrong language, either blurry or unnecessarily-high-resolution graphics), but the app at least still runs.
[1] Although given the potentially large size of native libraries, separate APK versions for differing CPU architectures already aren't that uncommon.
Your phone still downloads APKs from the Play Store, but it's no longer a single monolithic APK that covers all languages/screen sizes/CPU architectures [1] supported by that app. Instead you'll get a collection of APKs covering your specfic device configuration only.
> If it's an aab, can they archive it for later, like you can with apks?
You can archive the individual APKs, although installing them again is a bit more complicated, as you either need a third-party app like https://f-droid.org/packages/com.aefyr.sai.fdroid/, or else install them via the correct incantation on the command line.
As for APK archive sites, presumably coverage of languages/screen sizes/CPU architectures with few users might get worse, as one user uploading an individual APK version will no longer be enough to automatically cover all languages/screen dimensions/etc. and instead you need to grab separate APKs for each possible language/screen size etc.
Getting the APK with the correct CPU architecture (where applicable) will of course be critical, although in practice almost everybody is probably using ARM these days, so there's not much to go wrong here (although if you still have a 32-bit device then you can only run the 32-bit APK, whereas the other way round a 64-bit device can run both 32- and 64-bit native code).
As for language and screen density, my guess would be that Android can fall back to whatever language and screen density APK actually has been installed (since this should be the same situation as when a monolithic APK doesn't contain the correct resources for your preferred language/screen density), so you might get a degraded experience (wrong language, either blurry or unnecessarily-high-resolution graphics), but the app at least still runs.
[1] Although given the potentially large size of native libraries, separate APK versions for differing CPU architectures already aren't that uncommon.