Contrary to popular belief, Java (well, Android) apps can be quite small if you have no external dependencies and minimal graphical resources. Once you depend on something like Jetpack Compose, you're pulling in about a hundred libraries and adding a few MB before minifying.
Is it even supported way to write Android apps without compat libs? I tried to do that, and struggled. I hate dependencies and prefer to avoid them, however with Android that seems almost unavoidable (or requires expert knowledge of quirks of different Android versions, I guess).
Though it's not without compromises — because of Google's stupid policy that "nothing goes into the system unless it needs direct access to privileged or private system components", RecyclerView, ViewPager, and some other basic UI components are still AndroidX libraries that depend on AppCompat for no good reason. I had to fork them to rid them of that dependency: https://github.com/grishka/LiteX
Is this a supported thing to do? No. Do I care about it being unsupported? Also no.
It's not difficult to write sub-10Mb release APK for a production app with lots of features while using all the compat libraries and other useful dependencies (that do make life a lot easier). Our app is ~7Mb, and we don't even heavily optimize for APK size.
IME biggest dependencies are not compat libraries or _typical_ dependencies that Android apps need (like image loaders), but anything that involves native code. Media capabilities is one thing, but also solutions for analytics/user monitoring/SDKs for integration with Important Companies are more often than not _massive_, and companies like to track the user from many angles ¯\_(ツ)_/¯
AppCompat/JetPack don't do anything magical - they are just regular open source libraries.
If your app wants to use features which behave differently depending on the OS version, you have to if/else over the OS version. Also, note that the platform's Fragment implementation is deprecated and you might miss ViewModel.
Yes, after all, the Compat libs themselves need to talk to OS. But there's a reason why you were struggling - those libs have code that handles changes of API between different OS versions and there's been many of those during 14 major Android releases.
Patching up those differences is after all the primary purpose of compat libs.
Yup! It's a major step in building any Java application. Things like stripping symbol names, removing unused APIs, and processing non-java assets like images. For Android applications Gradle handles this by invoking some Android specific utilities alongside the java ones, but there's tons of build tools out there for Java that handle doing these things for everything from Blu-Rays to web apps.
Unfortunately you can't treeshake a language that supports reflections. So it's not like a C++ program where unused parts get dropped.
You can manually remove dependencies or.. I think in the Android world you specify what classes can be reflected on and then strip unused code with Proguard (though I could never get it working with Clojure)
Would love to be corrected if I got any of it wrong
I'm afraid you did get it wrong - it's very standard to do that on all Android apps. The part that you missed is that reflection is rarely used in production apps (partially because for a long time, reflection was VERY expensive on Dalvik/ART runtimes) and can be easily handled by configuration for minifier/optimizer to explicitly keep code.
Even C++ you mention does that - you have explicit __attribute__ calls to avoid linker from dropping code you want to keep for reflection purposes.
Yes, it's enabled by default even in tutorial Android apps - Proguard was the tool used in olden days and has now been replaced by Google developed R8 optimizer/minifier.
