Static Java libraries that implement subset of the functionality from the SDK that’s backwards compatible to older versions of Android, along with other functionality that doesn’t exist in the SDK. Generally you don’t build against bare Android classes thes days. You build against AndroidX.
As someone that had experience on both sides, AndroidX is roughly functions as a middleware that exposes roughly (but not always) the same set of API from the frameworks. Nobody sane would use the bare system framework as it’s a nightmare for backward compatibility and for handling device capability.
You’d still use the SDK the compile against, but AndroidX provides a nice wrapper that handles the aforementioned issue. It’s a separate library and not tied to the SDK.
As someone that has worked on the HAL layers and has used the NDK, but doesn’t know much about app development…
Where does AndroidX fit in? I thought app developers had the SDK and NDK
Static Java libraries that implement subset of the functionality from the SDK that’s backwards compatible to older versions of Android, along with other functionality that doesn’t exist in the SDK. Generally you don’t build against bare Android classes thes days. You build against AndroidX.
As someone that had experience on both sides, AndroidX is roughly functions as a middleware that exposes roughly (but not always) the same set of API from the frameworks. Nobody sane would use the bare system framework as it’s a nightmare for backward compatibility and for handling device capability.
You’d still use the SDK the compile against, but AndroidX provides a nice wrapper that handles the aforementioned issue. It’s a separate library and not tied to the SDK.