Android support?

[Rudxain]

Problem description

3 OSes is nice, but including Android would be better. Especially considering each OEM has its own "distro", and some of them can be very privacy-invasive (looking at Xiaomi and Samsung)

Proposed solution

A checklist of settings to change manually

Alternatives considered

Automated scripts would usually require root access (which is out-of-the-question for users who have fully-locked bootloaders). This is why I propose a manual checklist, as GUI Settings and ADB config cmds are more accessible.

Additional information

Some scripts (such as shell history clear) can be executed on Termux without elevated privileges, and those are already included in the "Linux" section

[femdiya]

While this... can be a great idea but this service is never ment to run on mobile devices. Although yes, using root we can do much more but ADB is very limited in the terms of customization.

[account183892]

Maybe a version that uses ADB and a root version also?

[undergroundwires]

Hi, so we have two ways to go:

1. Provide scripts for Termux.
2. Provide scripts to run through ADB.

• Correct me if I'm wrong here but Termux is very limited on non-rooted devices right? It cannot even delete apps.
• With ADB, we can easily build a "remove bloatware" section for different brands. But is there more we can do there for non-rooted devices?

So I wonder which option should be more suitable, and what we can do on non-rooted devices with each option. Seems like we can do more with ADB.

[femdiya]

Hi, so we have two ways to go:

1. Provide scripts for Termux.

2. Provide scripts to run through ADB.

* Correct me if I'm wrong here but Termux is very limited on non-rooted devices right? It cannot even delete apps.

* With ADB, we can easily build a "remove bloatware" section for different brands. But is there more we can do there for non-rooted devices?

So I wonder which option should be more suitable, and what we can do on non-rooted devices with each option. Seems like we can do more with ADB.

Android user here, Yes, Termux supports root but it's very limited on unrooted devices. ADB is the best option here, but I suppose that user needs to execute the commands manually (?)

[undergroundwires]

On desktop version, we can provide a GUI/Wizard to go through ADB process. It may install ADB automatically or guide on how to install, select device, instruct what to do on mobile phone step by step through a GUI. We can run it when the user clicks on "Run" button. How does it sound?

On some scripts we can do root check using adb, if the device is rooted then execute otherwise show a warning, on scripts supporting non-root they can run directly.

Is there anything more that we can do through adb rather than "Remove bloatware" (remove packages) and "Privacy cleanup" (cleanup some folders)?

[account183892]

femdiya commented

Termux can execute shell scripts as root with su.

[Rudxain]

Provide scripts to run through ADB.

ADB can run on Termux. The setup process is clunkier because a ADB/TCP/IP/WiFi connection must be established. This must be done via USB (on older versions), but newer Android versions don't require USB for setup.

Termux is very limited on non-rooted devices right?

Yes, but there's a plugin to access the Android API, although it's much more limited than other apps such as Tasker, Macrodroid, or Llamalab's Automate.

"remove bloatware" section for different brands.

UAD aims to solve this. It doesn't have scripts, but users can select all packages from some category, then disable them all via ADB-over-USB.

is there more we can do there for non-rooted devices?

Settings. I bet Xiaomi has tons of privacy-invasive settings. Samsung and Google both request usage stats, and have similar tracking settings. Since those settings are tied to the OS instead of an app, debloating alone can't help here.

Google Play Services has settings such as "Advertising ID", and that pack can't be disabled safely on some devices. Even when G.P.S. can be uninstalled/disabled, it provides APIs that most Play Store apps depend on. Discord doesn't even work at all when G.P.S. is disabled (which is funny, because WhatsApp works ok, except for background messages), but I would argue that's the devs' fault for purposefully depending on it (the web app works fine without G.P.S.), and Discord+uBO is recommended anyways, so users shouldn't be using the native app

[account183892]

Provide scripts to run through ADB.

ADB can run on Termux. The setup process is clunkier because a ADB/TCP/IP/WiFi connection must be established. This must be done via USB (on older versions), but newer Android versions don't require USB for setup.

Termux is very limited on non-rooted devices right?

Yes, but there's a plugin to access the Android API, although it's much more limited than other apps such as Tasker, Macrodroid, or Llamalab's Automate.

"remove bloatware" section for different brands.

UAD aims to solve this. It doesn't have scripts, but users can select all packages from some category, then disable them all via ADB-over-USB.

is there more we can do there for non-rooted devices?

Settings. I bet Xiaomi has tons of privacy-invasive settings. Samsung and Google both request usage stats, and have similar tracking settings. Since those settings are tied to the OS instead of an app, debloating alone can't help here.

Google Play Services has settings such as "Advertising ID", and that pack can't be disabled safely on some devices. Even when G.P.S. can be uninstalled/disabled, it provides APIs that most Play Store apps depend on. Discord doesn't even work at all when GPS is disabled (which is funny, because WhatsApp works ok, except for background messages), but I would argue that's the devs' fault for purposefully depending on it (the web app works fine without G.P.S.), and Discord+uBO is recommended anyways, so users shouldn't be using the native app

Shizuku can be ran in termux, but it does the same as executing commands from ADB, just with a computer connected once

[Rudxain]

Shizuku can be ran in termux

True. There's a button to "use in terminal apps" that provides a script that can be executed by Termux.

just with a computer connected once

Shizuku setup is almost the same as ADB on Termux. There's no need for USB on newer Androids.

However, Shizuku makes pairing+connection less annoying:

• It shows an input notification that asks for the pairing PIN, which is better than multi-window.
• It auto-detects pairing and connection ports. I have no idea how it does it so fast, it cannot be port-scanning.

IIRC, Shizuku has a "keep-alive" feature that keeps Wireless-Debug enabled until the user disconnects (or wifi is turned off). Termux, OTOH, lets the OS disable WD after a period of inactivity.

[!note] WD is the "developer setting", not adb, nor shell user

[account183892]

Shizuku can be ran in termux

True. There's a button to "use in terminal apps" that provides a script that can be executed by Termux.

just with a computer connected once

Shizuku setup is almost the same as ADB on Termux. There's no need for USB on newer Androids.

However, Shizuku makes pairing+connection less annoying:

• It shows an input notification that asks for the pairing PIN, which is better than multi-window.
• It auto-detects pairing and connection ports. I have no idea how it does it so fast, it cannot be port-scanning.

IIRC, Shizuku has a "keep-alive" feature that keeps Wireless-Debug enabled until the user disconnects (or wifi is turned off). Termux, OTOH, lets the OS disable WD after a period of inactivity.

Note

WD is the "developer setting", not adb, nor shell user

You can add a button to quick settings to toggle Wireless Debugging.

[undergroundwires]

I'm noob to Android and modding it. So I appreciate all discussions about it.

To be able to run su in Termux you need to root the phone right? Without rooting, it cannot configure the system,or delete files/apps, basically a sandboxed emulation of a unix shell, which is useless.

Looking at AndroidManifest.xml we can see that a lot more permissions are granted to ADB.

Using ADB we can actually:

• Remove apps: adb uninstall com.spotify.lite.
• Disable background running: adb shell cmd appops set <package_name> RUN_IN_BACKGROUND ignore

ADB on Termux (which I did not know about as @Rudxain mentions) seems to remove the need for USB cable and PC connection and allow us to run adb CLI directly on Termux if I understand this correctly.

In that case we can have some explanation on UI about how to get ADB running and then provide scripts utilizing ADB commands like (examples):

• Uninstall Xiaomi tracking: adb uninstall com.huaqin.diaglogger
• Uninstall Samsung tracking: adb uninstall com.qualcomm.qti.qms.service.telemetry

I'm not sure how to utilize Shizuku and if allows adb CLI usage as above.

I'm very interested in what other settings we can configure as you mentioned @Rudxain.

Does it make sense to create "Android" collection and adding these commands. To start with, we can add a dialog explaining how to get going with ADB using Termux or PC on the UI.

[Rudxain]

you need to root the phone right?

Yes, but there's tools like Magisk, which allow rooting without sacrificing too much of its benefits.

Without rooting, it cannot configure the system

Well, the settings cmd (typically used via ADB) can be run on Termux, with some caveats.

delete files/apps

If Termux (or any app) has "Access to all files" permission, its commands have it too. Of course, "All files" refers to user files. It cannot delete the data within other apps (such as cache).

Apps can request a "Request delete package" permission. But, as the name suggests, it requires manual user confirmation. Termux doesn't request this permission, but LL-AM does. Termux can communicate with LL-AM in many ways (Tasker plugin, user file-system, etc...), and we just need a "flow" for that.

basically a sandboxed emulation of a unix shell

Sandboxed: yes. Emulated: no.

Apps can execute arbitrary programs (execve I guess?), as if they were Linux users (they are). They just need the proper permissions. Some programs may be executable, but have partial functionality.

Apps targeting A10 cannot execute writable storage. Basically W^X applies to file-system as well as memory.

Android's shell is MKSH, but Termux uses Bash by default.

I'm not sure how to utilize Shizuku and if allows adb CLI usage as above.

The script I mentioned should support that. I don't remember how to use it. The Shizuku app documents it. IDK why the docs aren't available online.

Here's the developer docs, just-in-case I missed something.

I'm very interested in what other settings we can configure

AppOps unlocks many possibilities! Such as disabling clipboard access, background location, etc...

Shizuku dev made an app to manage them.

Does it make sense to create "Android" collection

Anything Android-specific should be there. Cross-distro stuff is already handled by the Linux collection

[Rudxain]

other settings

There are OEM-specific settings. Samsung has had a lot (~200) in the history of Galaxy devices.

Apps like LL-AM expose hidden features such as secure (there's also global and system) settings, unreachable app activities, services and broadcasts, etc... I recommend that sort of apps (such as Tasker and Macrodroid) to get a glimpse of the hidden stuff.

WRITE_SECURE_SETTINGS can be requested in the AndroidManifest.xml (IIRC, Termux does it), but needs a one-time adb shell pm grant, and (for some reason) apps cannot configure arbitrary secure settings (such as display resolution, unless calling the WindowManager API or executing adb shell wm size)

[undergroundwires]

ADB commands

🔍🧐 Please provide any docs/projects about what we can configure regarding privacy using adb on Android.

I think we decided that we'll provide a script collection based on adb commands and we have the consensus on this as way forward.

@Rudxain, I checked @ionuttbara's melody_android and it looks nice and provides some nice tweaks.

Mobile app - Packaging

@plantindesk suggests in https://github.com/undergroundwires/privacy.sexy/issues/353#issuecomment-2088813411 that:

We can use Native Script (Free) and Expo (Free-Limited in deployment) for android support As all is dependent upon vue Nativescript is best

This is more about providing the Android package rather than the scripts. I checked Nativescript after your suggestion and it will require re-building the app, which would be too much.

I think publishing privacy.sexy as PWA (progressive web app) would be the easiest option. vite-plugin-pwa seems to simplify this. It can then be pushed to Play Store etc. Google provides a CLI (bubblewarp) to turn PWA to Android APK that can be published.

A PWA cannot run the scripts as I understand, but it can give more offline experience to copy paste the scripts into Termux. This is sad as desktop version adds desktop-native functionality but mobile version will not be able to do that, but rebuilding a complete new app using Nativescript is too much time consuming and is not on my radar.

---

I read your posts @Rudxain and try to follow. Almost all of this stuff is new to me, so I may be missing some points or misunderstanding stuff. Feel free to guide us through this implementation.

[Rudxain]

PWA cannot run the scripts

I'm confident in that being true. AFAIK, PWAs (bubblewraped or not) cannot access the Android API (unless indirect, such as Web File API), let alone the Linux ABI (execve).

BTW, converting the existing website into a PWA should be pretty straight-forward. So the offline experience can be achieved easily

[Rudxain]

I just remembered that ADB can work via WebUSB, so I would expect wireless-debug to also work via WebRTC. Since ADB is just an application-layer-protocol, it works over:

• USB
• Ethernet
• TCP/IP
• Bluetooth (maybe?)

And indeed, it does seem like it should work via WebRTC!

BTW, last time I checked, Firefox refuses to support WebUSB because Mozilla deems it unsafe/insecure. Chromium browsers support it, though

[mziehm]

Changing captive portal check to privacy friendly alternative or deactivating does not require root based on this info in German only: https://www.kuketz-blog.de/empfehlungsecke/#captive-portal:

setting an alternative privacy friendly captive portal check url:

adb shell 'settings put global captive_portal_http_url "http://captiveportal.kuketz.de"'
adb shell 'settings put global captive_portal_https_url "https://captiveportal.kuketz.de"'
adb shell 'settings put global captive_portal_fallback_url "http://captiveportal.kuketz.de"'
adb shell 'settings put global captive_portal_other_fallback_urls "http://captiveportal.kuketz.de"'

deactivating captive portal checks completely (probably not recommended for most users):

adb shell 'settings put global captive_portal_detection_enabled 0'
adb shell 'settings put global captive_portal_server localhost'
adb shell 'settings put global captive_portal_mode 0'

[Rudxain]

Changing captive portal to privacy friendly alternative

Aren't captive-portals supposed to be router-specific? How does that work?

[mziehm]

Changing captive portal to privacy friendly alternative Aren't captive-portals supposed to be router-specific? How does that work?

Sorry might not have formulated it precisely enough (made a small update above). I think, you are correct the captive portal is from the router. This is about the captive portal detection or check which is done by many clients incl. Windows, Android with the aim to detect if there is a captive portal instead of internet access. See also here: https://en.wikipedia.org/wiki/Captive_portal#Detection

"Every time an Android device connects to a Wi-Fi or mobile network, the system performs a captive portal check. This is Android's way of ensuring that a device has not only received an IP address from the access point or Internet service provider, but can also actually reach destinations on the Internet. This is necessary, for example, to recognize portal pages of wifi hotspots (e.g. in hotels). To check whether a connection exists, Android sends a request to the address connectivitycheck.gstatic.com. If the request is successful, there is a connection to the Internet. With this request, the system transmits information about the IP address of the connection, the time of Internet access and the browser currently being used to Google each time. However, privacy-sensitive users in particular do not want to send a "ping" to Google every time they visit the Internet." Translated with DeepL.com (free version) from https://www.kuketz-blog.de/empfehlungsecke/#captive-portal

[mziehm]

Privacy policy of the captiveportal.kuketz.de "A connectivity check for Android smartphones is offered at captiveportal.kuketz.de. Anyone accessing the page receives the following response:

HTTP/1.1 204 No Content

Use of the service is voluntary. No data is collected in any form. After the request has been answered by the nginx web server, all information such as the IP address is immediately discarded and not stored in any log file."

Translated with DeepL.com (free version) from https://www.kuketz-blog.de/datenschutzhinweise/ paragraph "2.6 Android Captive Portal Check: captiveportal.kuketz.de"

There might/likely are other privacy friendly operators of such services. Never searched for it.

[femdiya]

Speaking of "privacy friendly captive portal", I think this website gets the job done and it's a great choice: http://httpforever.com/ @mziehm @Rudxain