> Would be nice if you would be able to give examples of those anti-user features and examples of desired user-empowerment features.
Off the top of my head, here are some of the anti-user features in AOSP/Android that I would change:
* Remote attestation. If someone wants this, they can turn it one, but the OS and apps shouldn't be able to impose this requirement on the user.
* Making it hard for people to root their phones. I can understand having root access turned off by default, but it should be an easy and documented process to turn on root access on your phone, but it should also require setting a root password, which the user has to enter when doing an administrative action in the system. After rooting the phone, the GUI will ask for the root password when doing certain administrative tasks and the terminal will ask for it when using `su`. However, I would enable non-root users to access more than they currently can (see below).
* Apps should not be able to decide that they won't execute based on rooted status, Play Integrity checks, SELinux enforcing, bootloader unlocked status, etc. It should be up to the user, not the app creator, whether an app is allowed to execute. The OS should inform the user about potential security problems, but not encourage app creators to put these restrictions on their apps. I realize, however, that an AOSP fork wouldn't have the power to stop app creators from doing this stuff, so I would include a clean Android work profile and make it so those problematic apps can't detect what has been done to the rest of the system.
* The Activity Manager (`am` command) needs to be designed or eliminated to stop restricting the user. It is very annoying that users can't just execute graphical apps from the terminal like in Linux, and the way `am` does it is designed to make users not use a terminal. Instead of `am start -n org.videolan.vlc/org.videolan.vlc.gui.video.VideoPlayerActivity -a android.intent.action.VIEW -d file:////storage/emulated/0/VideoToPlay.mp4`, it should just be `vlc ~/VideoToPlay.mp4` like in normal Linux. Forcing apps to name the activity with the `-a` option, and to pass their parameters with the `-d` and `-es` options is designed to stop users from using options. Most Android apps have no command line options because Android makes it so painful to use them, and that is by design.
Why does Android force users to refer to apps by reverse domain name order like "org.videolan.vlc" which is impossible to remember and so hard to type? Using the full reverse domain name for an app should only be necessary if there are two apps with the same name, and it should be possible to create an alias for apps so they can have short names.
If a user (i.e. the person using the phone) initiates an app, then that person should be able to kill the app from the command line with a short command like `pkill app-name`. Currently, AOSP only allows `am force-stop com.example.myapp` if the phone has been rooted or if issuing through ADB (`adb shell am force-stop com.example.myapp`), which is an anti-user restriction that needs to be eliminated.
I wouldn't require the `am` command at all for starting and stopping apps, but if AOSP/Android is going to use the `am` command, make everything easy to type and very short. It should be possible to set variables when executing apps just like in normal Linux (e.g. `MY_VAR=value myapp`) Instead, AOSP forces people to either root their phone or use adb, just to set variables when executing an app: `adb shell setprop wrap.com.example.myapp "env MY_VAR=value"`
* AOSP requires a rooted device or adb in order to use many commands, including `setprop`, the package manager (`pm`), most networking commands (`ip`, `ss`, `netstat`, etc.), use of wrap.com.example.appname or debug.com.example.appname, etc. It is really annoying that you have to root the device just to see the list of the installed packages with `pm list packages`, see the current battery state with `dumpsys battery` or even see the IP address with `ip a`.
* AOSP requires a rooted device or adb in order to view most of the directory structure on the device. In standard Linux, an ordinary user gets read-only access to `/`, `/dev`, `/sys`, etc., which makes it much easier to figure out how the system works and diagnose problems, but the device is basically a black box for the ordinary android user. I can understand forcing normal apps to access the hardware through the Android HAL and not be able to read the / directory, but terminal apps should have permissions, so the normal user can have read-only access to `/`, `/dev`, `/sys`, etc. Forcing users to execute some custom command like `termux-setup-storage` just to get permission to access the microSD card is bizarre and another anti-user feature.
* Forcing users to create an app just to execute a custom script from the launcher is another anti-user feature. Let’s say that you want tapping on an icon on your screen in order to run a custom script. In a standard Linux system, you just create the script, and then you add a launcher in the graphical interface to execute it or you add a `.desktop file` to the `~/.local/share/applications` to add it to the graphical interface. In AOSP/Android, you need to create your own app in Android Studio that has a `AndroidManifest.xml` file with this code:
```
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.HOME" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
```
And you need to have application code that has Java or Kotlin code like this:
`Runtime.getRuntime().exec("/storage/emulated/0/your_script")`
Then you need to create the apk file and sign it and install it. There are workarounds, like installing Termux and Termux:Widget, but those workarounds shouldn't be necessary. AOSP should make it as easy as standard Linux.
* The way permissions work in AOSP/Android is simply a hassle and requires too much cognitive load for the average user. When you first install a new app, you have no idea how the app works or what permissions it really needs. There are 324 different permissions in Android 17, and it is overwhelming for most people to install a messaging app and be asked for a dozen different permissions, such as Notifications, Identity, Contacts, SMS, Phone, Photos/Media, Storage, Camera, Microphone, Wi-Fi, Calendar and Location, which is why so many users simply grant all the permissions that are requested, so the permission system doesn't really work as intended.
It would be much better for the distro package manager to configure the app to grant just the permissions that most users of the distro would want, and then let the user set the permissions that she always wants to be asked about, but not be bothered with the rest. For example, Calendar and Location shouldn't be necessary for most users of a messaging app, so they wouldn't be granted by default, and the OS would ask for those permissions if the user tries to use a feature that requires those permissions. In a distro focused on security, the defaults would be different from a normal distro. The list of permissions granted by default should be shown to the user when installing, and users who want to pick and choose can open a dialog box to select the permissions. They can also set the permissions across all apps that they want to be asked about.
In my opinion, the user should only be asked about each permission only if an app comes from outside the default repository. Of course, this assumes that the default repository is only contains open source code, and the package manager is separate from the app creator and is reviewing the code in the interest of the AOSP distro's users.
* Each app has a different user assigned to it by AOSP/Android, and you can't change the name of that user, which is very inconvenient, because AOSP/Android creates random usernames that are very hard to remember. For example, every time I want to ssh to my AOSP phone, I have to open Termux and use the `whoami` command, because I can never remember that my Termux user is named u0_a281.
Off the top of my head, here are some of the anti-user features in AOSP/Android that I would change:
* Remote attestation. If someone wants this, they can turn it one, but the OS and apps shouldn't be able to impose this requirement on the user.
* Making it hard for people to root their phones. I can understand having root access turned off by default, but it should be an easy and documented process to turn on root access on your phone, but it should also require setting a root password, which the user has to enter when doing an administrative action in the system. After rooting the phone, the GUI will ask for the root password when doing certain administrative tasks and the terminal will ask for it when using `su`. However, I would enable non-root users to access more than they currently can (see below).
* Apps should not be able to decide that they won't execute based on rooted status, Play Integrity checks, SELinux enforcing, bootloader unlocked status, etc. It should be up to the user, not the app creator, whether an app is allowed to execute. The OS should inform the user about potential security problems, but not encourage app creators to put these restrictions on their apps. I realize, however, that an AOSP fork wouldn't have the power to stop app creators from doing this stuff, so I would include a clean Android work profile and make it so those problematic apps can't detect what has been done to the rest of the system.
* The Activity Manager (`am` command) needs to be designed or eliminated to stop restricting the user. It is very annoying that users can't just execute graphical apps from the terminal like in Linux, and the way `am` does it is designed to make users not use a terminal. Instead of `am start -n org.videolan.vlc/org.videolan.vlc.gui.video.VideoPlayerActivity -a android.intent.action.VIEW -d file:////storage/emulated/0/VideoToPlay.mp4`, it should just be `vlc ~/VideoToPlay.mp4` like in normal Linux. Forcing apps to name the activity with the `-a` option, and to pass their parameters with the `-d` and `-es` options is designed to stop users from using options. Most Android apps have no command line options because Android makes it so painful to use them, and that is by design. Why does Android force users to refer to apps by reverse domain name order like "org.videolan.vlc" which is impossible to remember and so hard to type? Using the full reverse domain name for an app should only be necessary if there are two apps with the same name, and it should be possible to create an alias for apps so they can have short names. If a user (i.e. the person using the phone) initiates an app, then that person should be able to kill the app from the command line with a short command like `pkill app-name`. Currently, AOSP only allows `am force-stop com.example.myapp` if the phone has been rooted or if issuing through ADB (`adb shell am force-stop com.example.myapp`), which is an anti-user restriction that needs to be eliminated. I wouldn't require the `am` command at all for starting and stopping apps, but if AOSP/Android is going to use the `am` command, make everything easy to type and very short. It should be possible to set variables when executing apps just like in normal Linux (e.g. `MY_VAR=value myapp`) Instead, AOSP forces people to either root their phone or use adb, just to set variables when executing an app: `adb shell setprop wrap.com.example.myapp "env MY_VAR=value"`
* AOSP requires a rooted device or adb in order to use many commands, including `setprop`, the package manager (`pm`), most networking commands (`ip`, `ss`, `netstat`, etc.), use of wrap.com.example.appname or debug.com.example.appname, etc. It is really annoying that you have to root the device just to see the list of the installed packages with `pm list packages`, see the current battery state with `dumpsys battery` or even see the IP address with `ip a`.
* AOSP requires a rooted device or adb in order to view most of the directory structure on the device. In standard Linux, an ordinary user gets read-only access to `/`, `/dev`, `/sys`, etc., which makes it much easier to figure out how the system works and diagnose problems, but the device is basically a black box for the ordinary android user. I can understand forcing normal apps to access the hardware through the Android HAL and not be able to read the / directory, but terminal apps should have permissions, so the normal user can have read-only access to `/`, `/dev`, `/sys`, etc. Forcing users to execute some custom command like `termux-setup-storage` just to get permission to access the microSD card is bizarre and another anti-user feature.
* Forcing users to create an app just to execute a custom script from the launcher is another anti-user feature. Let’s say that you want tapping on an icon on your screen in order to run a custom script. In a standard Linux system, you just create the script, and then you add a launcher in the graphical interface to execute it or you add a `.desktop file` to the `~/.local/share/applications` to add it to the graphical interface. In AOSP/Android, you need to create your own app in Android Studio that has a `AndroidManifest.xml` file with this code: ``` <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.HOME" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter> ``` And you need to have application code that has Java or Kotlin code like this: `Runtime.getRuntime().exec("/storage/emulated/0/your_script")` Then you need to create the apk file and sign it and install it. There are workarounds, like installing Termux and Termux:Widget, but those workarounds shouldn't be necessary. AOSP should make it as easy as standard Linux.
* The way permissions work in AOSP/Android is simply a hassle and requires too much cognitive load for the average user. When you first install a new app, you have no idea how the app works or what permissions it really needs. There are 324 different permissions in Android 17, and it is overwhelming for most people to install a messaging app and be asked for a dozen different permissions, such as Notifications, Identity, Contacts, SMS, Phone, Photos/Media, Storage, Camera, Microphone, Wi-Fi, Calendar and Location, which is why so many users simply grant all the permissions that are requested, so the permission system doesn't really work as intended.
It would be much better for the distro package manager to configure the app to grant just the permissions that most users of the distro would want, and then let the user set the permissions that she always wants to be asked about, but not be bothered with the rest. For example, Calendar and Location shouldn't be necessary for most users of a messaging app, so they wouldn't be granted by default, and the OS would ask for those permissions if the user tries to use a feature that requires those permissions. In a distro focused on security, the defaults would be different from a normal distro. The list of permissions granted by default should be shown to the user when installing, and users who want to pick and choose can open a dialog box to select the permissions. They can also set the permissions across all apps that they want to be asked about.
In my opinion, the user should only be asked about each permission only if an app comes from outside the default repository. Of course, this assumes that the default repository is only contains open source code, and the package manager is separate from the app creator and is reviewing the code in the interest of the AOSP distro's users.
* Each app has a different user assigned to it by AOSP/Android, and you can't change the name of that user, which is very inconvenient, because AOSP/Android creates random usernames that are very hard to remember. For example, every time I want to ssh to my AOSP phone, I have to open Termux and use the `whoami` command, because I can never remember that my Termux user is named u0_a281.