>Android is designed for developers. Security controls were designed to reduce the burden on developers. Security-savvy developers can easily work with and rely on flexible security controls. Developers less familiar with security are protected by safe defaults.
In addition to providing a stable platform to build upon, Android gives additional support to developers in a number of ways. The Android security team looks for potential vulnerabilities in apps and suggests ways to fix those issues. For devices with Google Play, Play Services delivers security updates for critical software libraries, such as OpenSSL, which is used to secure app communications. Android security released a tool for testing SSL (nogotofail) that helps developers find potential security issues on whichever platform they are developing.
Vs.
>Android is designed for users. Users are provided visibility into the permissions requested by each app and control over those permissions. This design includes the expectation that attackers would attempt to perform common attacks, such as social engineering attacks to convince device users to install malware, and attacks on third-party apps on Android. Android was designed to both reduce the probability of these attacks and greatly limit the impact of the attack in the event that it was successful. (Read: Handcuff users to keep them from violating developer expectations and assumptions)
>Android security continues to progress after the device is in the user's hands. Android works with partners and the public to provide patches for any Android device that is continuing to receive security updates. (Read: we work with developers (them again)* to provide patches to devices that are convenient to deliver patches to)
>More information for end users can be found in the Nexus help center, Pixel help center, or your device manufacturer’s help center. (Read: we take no responsibility for explaining how any developer's use of this power is exercised, ask them!)*
>This page outlines the goals of the Android security program, describes the fundamentals of the Android security architecture, and answers the most pertinent questions for system architects and security analysts. It focuses on the security features of Android's core platform and doesn't discuss security issues that are unique to specific apps, such as those related to the browser or SMS app. (Again, even when talking about users, the language drifts back to people we'd lump under developers... who exactly is the User here?)
Then this gem:
>Verified Boot strives to ensure all executed code comes from a trusted source (usually device OEMs), rather than from an attacker or corruption (oh, is corruption where user programs are classed under?).
It establishes a full chain of trust (for whom, OEM's again?), starting from a hardware-protected root of trust to the bootloader (whose root of trust, OEM?), to the boot partition and other verified partitions.
Sorry, but the language used to describe all of this completely lets the cat out of the bag on who the Android community holds to be the true benefactors of your "ownership" of a handset.
https://source.android.com/security/
Straight from the source. Quiet parts emphasized and said out loud by me.
Android is the most transparently User/operator hostile piece of Open Source software I have ever had the misfortune of laying my eyes upon. The fact you basically have to be a developer to list and understand the things you need to do to get anything non-trivial done speaks volumes.