Big list update

[KarlRamstedt]

Added a bunch of packages from Oneplus 3/3T and Oneplus 9.
Added a bunch of descriptions for packages already in the list.
Corrected some erroneous descriptions.
Shortened some descriptions and corrected some grammar.
Changed "Removal" and "List" for some packages.

To save you some time and give a taste of my changes, here's some highlights from the list (all of these lacked descriptions or were very wrong):

com.android.carrierdefaultapp

This package is a generic solution that allows carriers to indicate when a device has run OOB(Out Of Balance). Android devices that are OOB need carrier mitigation protocols to allow select data through(like to notify users their data/balance is out, or allow them to buy more data through the carrier app).
Will probably break that functionality if disabled, but is otherwise safe to disable(should only affect users that are out of data/balance?).
https://source.android.com/devices/tech/connect/oob-users

com.android.ons - Opportunistic Network Service

From what I can glean in the source code it seems like this provides a list of available networks and assigns each network a priority.
I've never seen it run on its own, so this might be part of some automatic network switching setting that I have turned off.
https://cs.android.com/android/platform/superproject/+/master:packages/services/AlternativeNetworkAccess/src/com/android/ons/OpportunisticNetworkService.java
https://developer.android.com/reference/android/telephony/AvailableNetworkInfo
https://cs.android.com/android/platform/superproject/+/master:frameworks/base/telephony/java/android/telephony/AvailableNetworkInfo.java

com.oneplus.orm

Seems to be Oneplus' Memory Management System according to a press-kit/-release they made for Android 11 (multiple sites wrote "ORM Memory Management System" word-for-word).
Runs in the background as part of the system. Runs even if disabled? Doesn't use any RAM when disabled tho, vs ~50MB when enabled.
Seems safe to disable, haven't noticed any negative effects in weeks of use, but I assume it breaks the "RAM Boost" feature (which is pointless anyway IMO).
Apk file name: OPOmm, mm = Memory Management?

com.oneplus.screenrecord - Screen Recorder

The Android 11 screen recorder with some Oneplus modifications.
Runs the "SystemUITileService" when you have it as one of the quicksettings tiles, but doesn't seem to run in the background outside of that.
Doesn't have an app icon, but you can create a shortcut to it with the Activity Launcher app.
https://f-droid.org/en/packages/de.szalkowski.activitylauncher/

com.qualcomm.qti.smq - QTR (Qualcomm Technology Reporting)

Runs on boot.
Seems like a telemetry package, supposedly sending hardware & software type, configuration and performance data.
Contains a "QtiFeedbackActivity" called "Hardware Feedback". When that hidden activity is launched through Activity Launcher you get a screen showing just a checkbox and this text:
"Collecting hardware and software type, configuration, and performance data helps Qualcomm improve next generation device battery life, security, and performance. Untick to disable."
Unticking isn't remembered; it's ticked again next time you enter. There's also a "Learn More" link that leads to: http://reporting.qti.qualcomm.com/learnmore_en.html which doesn't load for me.

Image of activity (obviously can't be included in the list, but figured I'd show it here on Github):

net.oneplus.launcher - Oneplus Launcher

Runs in the background as part of the system.
Aside from obviously handling the default launcher itself, it also handles the Recents UI on Android 9, the home&recents gestures in Android 11, some submenus in the Settings app and possibly more that I'm unaware of.
Probably not a good idea to disable.

com.google.android.apps.work.oobconfig - Device Setup

Sets up device to be managed by EMM (Enterprise Mobility Management), which "allows organizations to securely enable employee use of mobile devices".
Might also be what does the actual management on your device, if you set it up as a work device.
Only seems to run on boot(not in the background after boot) if you haven't set up your device as a work device.
I tried to disable it through UAD, but nothing happens? Seems immune to disabling?
https://bayton.org/2020/11/google-announce-big-changes-to-zero-touch/
https://bayton.org/docs/enterprise-mobility/android/what-is-android-zero-touch-enrolment/

com.qualcomm.qti.smq nicely illustrates how useful Activity Launcher can be in combination with a Package Viewer that shows Activities.

As you saw in one of the new list entries; I've found a way to see running system processes. The Simple System Monitor app with the PACKAGE_USAGE_STATS permission (granted through ADB) is the only way I've found in Android 11.
Seeing running system processes also showed some interesting things, like some processes running even while disabled(I assume Uninstall would yield the same result). For example com.qualcomm.location and Dolby & Dirac Sound System services run even if disabled, with RAM usage. I guess some system packages(com.oneplus.orm) rely on access to user-space(which disable/uninstall removes) while others(qualcomm.location/audio systems) don't and run just like normal even when disabled/uninstalled?

My changes have been over the course of a couple of weeks, but I've taken care to include any changes in recent commits, so nothing should be lost and it should merge nicely with the main branch.

[0x192]

Wow! Thanks you very much for this insane contribution! ❤️

I really appreciate the highlight but I will still skim trough all the changes. I have the feeling that I will learn a lot.

EDIT: Thanks you again for taking the time to correct my many grammar mistakes (English is not my first language and I didn't spend a lot time to proofread) and fix the problems with converting the bash array lists to JSON. Scrapping the documentation has been a bit laborious. Some packages have disappeared and some descriptions have been associated with the wrong package. I've tried to fix the major problems but I see there are still some...

[0x192]

Phew! I finally read through all your changes. That's terrific! Amazing work!

Here is a overall summary on what I don't necessarily agree:

• Putting all overlay in the Expert list seems excessive to me. I think you're right to be a bit more cautious than me with overlays but if we put some packages in the Recommended list, there is no point letting the associated overlay in Expert list.
• I find you a bit too cautious for some packages :)

[0x192]

I changed back some removal recommendation that I clearly disagree with but I'm still open to discussion :)

The Outdated label you can see on some review comments means I've already flipped back the changes in my commit. I didn't comment all my changes so you may want to have a look at the commit itself (f6905dd)

[KarlRamstedt]

Putting all overlay in the Expert list seems excessive to me. I think you're right to be a bit more cautious than me with overlays but if we put some packages in the Recommended list, there is no point letting the associated overlay in Expert list.

Part of the issue is that I don't know how important most theme packages are. Some theming systems are deeply integrated with phone systems, so there could be issues. I didn't feel the need to attempt disabling theme packages because they never execute on their own, I assume the theme manager just uses them for look-up. I also didn't have access to the packages I'm guessing are themes from other OEMs. So I played it safe and put them all in Expert. (more below)

I find you a bit too cautious for some packages :)

Hehe, maybe 😅
For packages I didn't know quite what they did or how safe they were to disable I just threw most of them in Expert, and some in Advanced.
But beyond that, I followed a set of definitions. This is actually something I wanted to bring up with you; I noticed that you don't define exactly what each removal category means, and definitions would be useful, so I came up with my own:

Recommended - Pointless or outright negative packages, and/or apps available through Google Play.
Advanced - Breaks obscure or minor parts of functionality, or apps that aren't easily enabled/installed through Settings/Google Play.
Expert - Breaks widespread and/or important functionality, but nothing important to the basic operation of the operating system.
Unsafe - Can break vital parts of the operating system.

Packages that run in the background should be prioritized for Recommended over Advanced, even if they break minor functionality.

Themes are commonly used and widespread functionality, so they fit the definition of "Expert". But I guess the argument could be made that they also fit Advanced. Edit: Additionally.

It's per the "apps that aren't easily enabled/installed through Settings/Google Play" that I put a couple of calculator, recorder and similar apps in advanced. I did this as more of a blanket change to all I found (Ctrl+F), because that was the case with some Oneplus apps that don't have frivolous permissions and aren't functionally terrible. If you know of any with sneaky permissions just go ahead and move em' to Recommended. But I think it would be a disservice to use Recommended for apps that don't have sneaky permissions and never run in the background, especially if they are easily uninstalled/disabled from within the phone itself.

[KarlRamstedt]

Just a few things, aside from the larger less obvious discussion on how to categorize themes.

[KarlRamstedt]

Additionally, on the theming categorization discussion:
#114 (comment)
I think that issue perfectly illustrates why it'd be a good idea to be a bit more careful with theming systems.
As I've mentioned in other comments: I think the theme packages should be categorized differently from the packages they theme. Because there are, for example, themes for core AOSP systems clearly not made by the OEM that made the theme package.

[lawson85]

Android auto is being discontinued anyhow: https://www.androidcentral.com/google-assistant-driving-mode-replacing-android-auto-phones-are-cars-next

[0x192]

I noticed that you don't define exactly what each removal category means [...] so I came up with my own

I think we need to be consistent and the definition of each category is something I should have done. I appreciate the initiative!

Recommended - Pointless or outright negative packages, and/or apps that are available through Google Play.

In absolute terms, I agree. If someone want to keep an app in this category, it is better from a privacy and security point of view to uninstall the system app and install the user app version from the Play Store.

But in practice, the lambda UAD user will removed all the apps from the Recommended list without reading the descriptions. Then they complain that it removed an important app (like the stock gallery or stock camera app for instance).

UAD will remove all the user data associated to the app so there can be data loss. We need to be careful.

Advanced - Breaks obscure or minor parts of functionality, or apps that aren't easily enabled/installed through Settings/Google Play.

Initially, I've used this category for packages that I would like to put in Recommended but that stay here because I know many people want them. So I think we should also use this category for apps that are often useful but that can easily be replaced by a better alternative (default keyboard/gallery/launcher/music app...)

Expert - Breaks widespread functionality, but nothing important to the basic operation of the operating system.

I agree. I'll add that removing packages in this category should not bootloop the device but but we can't guarantee it.

Unsafe - Can break vital parts of the operating system.

This category exists for documentation purpose. Removing any of those packages presents a very high risk of bootlooping the device.

---

Themes are commonly used and widespread functionality, so they fit the definition of "Expert". But I guess the argument could be made that they also fit Advanced. [...] I think it would be a disservice to use Recommended for apps that don't have sneaky permissions and never run in the background, especially if they are easily uninstalled/disabled from within the phone itself.

I kind of agree. I like minimalism and I often put packages in the Recommended category if I find them useless (for most of people) even if they don't necessarily run in the background or have too much permissions. I do this to reduce the potential attack surface but I must admit it doesn't have much sense sometimes.

The thing with themes is that I find theme manager apps a bit too invasive (e.g Samsung Theme Manager) that why Expert seems a bit too extreme for me (too few people will look at the Expert list).

However, I agree, given the theming issues people reported that we need to be careful.

[KarlRamstedt]

I think we should also use [Advanced] for apps that are often useful but that can easily be replaced by a better alternative (default keyboard/gallery/launcher/music app...)

Yeah, that makes sense. As long as they don't run in the background (without user input) or have sneaky permissions there's no need to put them in Recommended.

I'll add that removing packages in this category should not bootloop the device but but we can't guarantee it.

I'd say "nothing important to the basic operation of the operating system" covers the "no bootloop"-part. You want a "No guarantees" in addition to that?

The thing with themes is that I find theme manager apps a bit too invasive (e.g Samsung Theme Manager) that why Expert seems a bit too extreme for me (too few people will look at the Expert list).

Yeah, but if you think about it, don't they need to be pretty "invasive" to apply themes to system packages?
And themes are used by pretty much almost every single user, in addition to affecting most packages on a device, easily earning the "widespread" descriptor.
But hey, if you've tested that a specific theme manager is safe to disable without affecting anything other than theming then go for Advanced, but by default Expert makes sense for theme managers.

As for the theme packages themselves: if an OEM uses package-specific overlays as theming system (like Oneplus, Nokia and probably more) I think these should all be in Expert, regardless of what the package they theme is categorized as, because they're a part of the theming system, not the base package. And while I haven't tested anything but Oneplus' theming system, the package-specific overlay packages never execute on their own and have zero permissions, making them pretty pointless to disable/uninstall.

[0x192]

I'd say "nothing important to the basic operation of the operating system" covers the "no bootloop"-part. You want a "No guarantees" in addition to that?

You know how end-users are like in general. It's always a good idea to be very explicit!

Yeah, but if you think about it, don't they need to be pretty "invasive" to apply themes to system packages?

Yeah. That's probably why I don't like them! 🤔

And themes are used by pretty much almost every single user, in addition to affecting the most packages on a device, [...] by default Expert makes sense for theme managers.

Fair enough

the package-specific overlay packages never execute on their own and have zero permissions, making them pretty pointless to disable/uninstall.

Yeah. You're right. It's pointless.

[KarlRamstedt]

Fair enough
Yeah. You're right. It's pointless.

Does this mean we're in agreement that theme packages and managers should be put in Expert by default?
I'll get on that change if you give the go-ahead.

You know how end-users are like in general. It's always a good idea to be very explicit!

Sure, we seem to be in agreement on the rough structure of the definitions, let's discuss specific wording further in the feedback "Issue" post I've been planning to drop after we finish this pull.

[0x192]

Does this mean we're in agreement that theme packages and managers should be put in Expert by default? I'll get on that change if you give the go-ahead.

Yes. Go ahead. Thanks again for spending your free time helping me on this project! :)

Sure, we seem to be in agreement on the rough structure of the definitions, let's discuss specific wording further in the feedback "Issue" post I've been planning to drop after we finish this pull.

Good idea.

I really want to merge this ASAP. This is a huge pull request and there will be a lot of conflicts to resolve if I commit changes in the main branch before merging it.

I don't have much time at the moment but I hope I could resolve the last discussions and merge this by the end of the week.

[KarlRamstedt]

There we go, think we're just about done here now.
I decided to resolve the sidecar package in favor of Advanced since it has no permissions and never runs on its own, in addition to us not knowing exactly what it does.
I think that just leaves the com.asus.soundrecorder package for you to decide on.

[KarlRamstedt]

I went through most issue requests and added the most obvious ones (that didn't need any/much additional info) to take them off your plate 🙂

[0x192]

Only one little thing I'll fix right now and we're good to merge!