2

The motivations of profit driven corporations like Google, Samsung, Microsoft alongside the motivations of the secret services like GCHQ and the NSA are at odds with my desire to use the expensive smartphone that I have paid for to run only the applications that I choose.

It's seemingly impossible to buy or build a phone with nothing but pure open source android installed. They all have shocking amounts of bloatware pre-installed.

So I have rooted my phone and I am using a the Debloat (terminal emulator) to remove system apps. I've removed nearly everything related to Google, Samsung, Microsoft etc.

My phone is now taking over an hour to restart and getting very hot.

My questions is, if I continue to remove all apps and system apps. Will the Android operating system continue to run in such a way that I will be able to install only the open source apps of my choice? Or are there some apps that are truly essential for the operating system to startup?

5
  • 1
    We don't know which Android model and Android version you are using And it would be hard to find out which apps are non-essential except Google apps without having the phone itself. The safest way is to use a custom recovery to make a backup of system partition (and then move it in PC) and then do all the experiments you want on system apps.
    – Firelord
    Nov 12, 2018 at 17:06
  • 1
    Well, as @Firelord stated that your question is device specific, I'll try to give you a general overview. First of all be clear that if you are too much concerned, removing only system apps may not be enough to completely "debloat" your phone. The reason is that Java apps come into play after the zygote virtual machine is loaded which handles Java bytecode. From bootloader to zygote in booting process, a huge chain of native code is executed. Many process/services/daemons are started by init process which are continuously running in background providing many necessary functionalities. Nov 12, 2018 at 23:58
  • 1
    To name a few, there are rild, netd, mediaserver, surfaceflinger, servicemanager, logd etc. Most of this code is open source; Google developed AOSP and possibly kernel source too (some vendors don't release kernel source). SoC and hardware related code including bootloaders and drivers or HAL blobs are closed source but it's hardly possible that they contain some anti-privacy code. So the main culprits are Java apps, in most cases. Similar to the background daemons, some essentially required apps can be AOSP related and some are vendor or hardware related. Nov 12, 2018 at 23:59
  • 1
    If no code is injected by vendor, most of these are AOSP provided open source apps. For example systemui app loads basic user interface including status bar, notifications and theme while settings app provides Settings. Launcher, keyboard and dialer apps are also essential but those can be replaced with custom ones. There are also three Qualcomm provided apps (from /system/vendor/app/) running persistently on my device: QtiTelephonyService, TimeService and QCRilMsgTunnel. Nov 13, 2018 at 0:00
  • 1
    Other apps deeply integrated with Android APIs include Bluetooth, ContactsProvider, DocumentsUI, DownloadProvider, ExternalStorageProvider, Shell and the list goes on. However once again, it may vary for different vendors, different phone models and different Android versions. You need to be more cautious about closed source apps usually included by OEMs. They certainly contain some kind of bloatware stuff. An easy way to avoid this hassle is to use a vanilla Android custom ROM on a rooted device with open source kernel and unlocked bootloader. Nov 13, 2018 at 0:01

1 Answer 1

2

1. All of the system apps cannot be deleted

System apps are not just apps to be used by end users, but many of them don't have any user interface and they provide some core functionality of Android OS. So you cannot remove them. E.g. SystemUI app loads basic user interface including status bar, notifications and theme, while Settings app does what the name suggests. Other examples of such apps deeply integrated with Android core framework include Bluetooth, ContactsProvider, DocumentsUI, DownloadProvider, ExternalStorageProvider, Shell etc.

Though mostly system apps are part of AOSP, some might be vendor or hardware related. E.g. on Qualcomm devices there are QtiTelephonyService, TimeService and QCRilMsgTunnel etc. in /vendor/app/. Vendors may also inject their own code to AOSP apps. SystemUI and Settings apps are almost always modified by device OEMs to provide custom user interface and settings. So are other essentially required apps like Launcher, Keyboard and Dialer, though you can replace them with your own apps.

So it's not always practically possible to remove bloatware apps completely, and the situation may vary for different vendors, different phone models and different Android versions. An easy way to avoid the hassle of failed debloating attempts is to use a vanilla Android custom ROM on a rooted device with open source kernel and unlocked bootloader.

2. Deleting apps may not debloat the device completely

If you are too much concerned about bloatware, removing apps (system and/or user) only may not be enough to completely debloat your phone. Though in most cases Java apps are the culprits and you need to be more cautious about closed source apps usually included by OEMs, it's not that the other software components on device may never contain some kind of bloatware stuff.

Android apps run in Java-like virtual machines, so they come into play only after the zygote is up. But from bootloader to zygote in booting process, a huge chain of native code is executed. Bootloader starts Linux/Android kernel which starts first userspace process: init. init in turn starts many native services and daemons in background which provide different functionalities. To name a few, there are rild, netd, mediaserver, surfaceflinger, servicemanager, logd etc. zygote is started in the last.

Most of this code is open source; Google develops AOSP and a common kernel source. Latter is further modified by device OEMs according to device hardware, but not all of them release kernel source. OEMs might also modify AOSP native stack, though it's not very likely that they contain some anti-privacy code. But SoC and hardware related code including bootloaders and binary blobs (HALs) in userspace are always closed source. And your device can be controlled remotely even if it's turned off or even if there is not operating system on it.

So it's hard to avoid falling prey to profit-driven corporations and secret services unless you stop using gadgets. To avoid human bodies being tracked or controlled remotely might be the next challenge.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .