[1 of 5]
> The problem is that Android was designed as a vehicle to collect the personal information of users to feed that data to Google’s servers for its targeted advertising.
It is true that Google's services (their web services and apps) use data collection as a revenue stream. Despite that, their operating systems (AOSP, ChromiumOS) and their browser project (Chromium) offer a lot of user control over who they hand their personal information to. They offer a fine-grained run-time permission model. This is absent on the alternatives you propose. Flatpak doesn't use a proper run-time model, isn't as fine-grained and has numerous sandbox escape possibilities (notably via dbus or access to config files like .bashrc). You can use AOSP-based OSes without storing your personal data into Google apps and services if you don't want to hand it to those, you can instead use third-party alternatives with better privacy.
> AOSP is designed with these onerous security restrictions because so much of the software installed in Android comes from untrustworthy sources. Unlike the typical Linux distro, where the vast majority of the code is free/open source, the code of the vast majority of Android apps can’t be publicly reviewed for malicious intent.
Proper app stores like Google Play Store and Accrescent do verification of the applications you download to verify that it's an untampered app made by the actual developer. After first install, the signature gets pinned as well. This is much better than some ways people obtain software on traditional Linux distributions. These app stores can also offer FOSS applications. FOSS applications are for example available on Google Play Store and Accrescent. There is also a large ecosystem available on GitHub, for which you can also verify the signature using dedicated apps and which are also protected by signature pinning after first install.
Of course these measures don't protect you against a malicious developer, no technical measure can. If you don't trust the developers, you simply shouldn't use their software for actual personal use. Code being free and open source doesn't change that. A skilled developer can perfectly hide malicious code in the source. Code review of open source code is imperfect and often doesn't happen systematically enough to catch such things. Note the xz backdoor. If review would happen systematically, it isn't exclusive to OSS. You can also research the code of closed sourced software, such software isn't a black box. It can be analysed, decompiled, etc. Note how the xz backdoor was discovered.
These are also more security problems than simply malicious code. A developer can also make mistakes or not do due diligence. This can also pose security risks. Note that Android development practices much more incentivize good development and that Android apps heavily use memory safe code. This is contrary to traditional Linux apps.
> In a community-based Linux distro, it typically takes several years to become a maintainer of packages in the system under the guidance of a mentor who checks packages before they get uploaded to the system. The public reputations of Linux package maintainers (and their mentors who sponsored them) are staked on keeping malicious code out of the system.
Nothing stops Android apps from being open source and also properly vetting contributors. This isn't a technical limitation of AOSP-based OSes at all. The vetting system on Linux is imperfect as I said above, it still relies on trust. And as I said before, there are more security problems than simply code written with malicious intent.
> The problem is that Android was designed as a vehicle to collect the personal information of users to feed that data to Google’s servers for its targeted advertising.
It is true that Google's services (their web services and apps) use data collection as a revenue stream. Despite that, their operating systems (AOSP, ChromiumOS) and their browser project (Chromium) offer a lot of user control over who they hand their personal information to. They offer a fine-grained run-time permission model. This is absent on the alternatives you propose. Flatpak doesn't use a proper run-time model, isn't as fine-grained and has numerous sandbox escape possibilities (notably via dbus or access to config files like .bashrc). You can use AOSP-based OSes without storing your personal data into Google apps and services if you don't want to hand it to those, you can instead use third-party alternatives with better privacy.
> AOSP is designed with these onerous security restrictions because so much of the software installed in Android comes from untrustworthy sources. Unlike the typical Linux distro, where the vast majority of the code is free/open source, the code of the vast majority of Android apps can’t be publicly reviewed for malicious intent.
Proper app stores like Google Play Store and Accrescent do verification of the applications you download to verify that it's an untampered app made by the actual developer. After first install, the signature gets pinned as well. This is much better than some ways people obtain software on traditional Linux distributions. These app stores can also offer FOSS applications. FOSS applications are for example available on Google Play Store and Accrescent. There is also a large ecosystem available on GitHub, for which you can also verify the signature using dedicated apps and which are also protected by signature pinning after first install.
Of course these measures don't protect you against a malicious developer, no technical measure can. If you don't trust the developers, you simply shouldn't use their software for actual personal use. Code being free and open source doesn't change that. A skilled developer can perfectly hide malicious code in the source. Code review of open source code is imperfect and often doesn't happen systematically enough to catch such things. Note the xz backdoor. If review would happen systematically, it isn't exclusive to OSS. You can also research the code of closed sourced software, such software isn't a black box. It can be analysed, decompiled, etc. Note how the xz backdoor was discovered.
These are also more security problems than simply malicious code. A developer can also make mistakes or not do due diligence. This can also pose security risks. Note that Android development practices much more incentivize good development and that Android apps heavily use memory safe code. This is contrary to traditional Linux apps.
> In a community-based Linux distro, it typically takes several years to become a maintainer of packages in the system under the guidance of a mentor who checks packages before they get uploaded to the system. The public reputations of Linux package maintainers (and their mentors who sponsored them) are staked on keeping malicious code out of the system.
Nothing stops Android apps from being open source and also properly vetting contributors. This isn't a technical limitation of AOSP-based OSes at all. The vetting system on Linux is imperfect as I said above, it still relies on trust. And as I said before, there are more security problems than simply code written with malicious intent.