From Newsgroup: comp.mobile.android

PSA: How I disabled Google Analytics in an app by elevating Muntashirakon
on a Samsung Android 13 US unrootable device (which is 1/2 the problem).

1. Identifying the trackers
A. Muntashirakon App Manager > PulseSMS (last Klinker Bros. version)
a. App Manager detected 3 traclers which turned out to be
these embedded Google Measurement components
I. com.google.android.gms.measurement.AppMeasurementReceiver
i. Wakes the app when network conditions change
II. com.google.android.gms.measurement.AppMeasurementService
i. Collects analytics events and bundles them
III. com.google.android.gms.measurement.AppMeasurementJobService
i. Uploads analytics bundles to app-measurement.com
b. I compared this to what Aurora says are the trackers in the
current MapleMedia version of PulseSMS which is 28 trackers
according to:
<https://reports.exodus-privacy.eu.org/en/reports/714755/>
Even 3 trackers are too many, although at least it is not 28.
c. I tried App Manager > 1-click ops > Block trackers
I. It reported "No trackers found", which surprised me.
It turns out that's only because these trackers are embedded.
They're sneaky. They're not standalone libraries. Sigh.

2. Goal
A. I simply wanted to disable those three Google Measurement components
a. AppMeasurementReceiver
b. AppMeasurementService
c. AppMeasurementJobService

Had I known ahead of time how hard that would be, I wouldn't have done it.
But I succeeded, which is why I'm writing this up so that you can do better.

3. First attempt: ADB (USB debugging)
A. I tried disabling the components with ADB
a. adb shell pm disable-user --user 0 \
xyz.klinker.messenger/com.google.android.gms.measurement.\
AppMeasurementReceiver
b. adb shell pm disable-user --user 0 \
xyz.klinker.messenger/com.google.android.gms.measurement.\
AppMeasurementService
c. adb shell pm disable-user --user 0 \
xyz.klinker.messenger/com.google.android.gms.measurement.\
AppMeasurementJobService
B. Result
a. SecurityException: Shell cannot change component state
C. Reason
a. These are protected components
b. USB ADB shell does not have permission to disable them

"Protected components" are components that Android's Package Manager
Service will not allow normal apps or ADB shell to enable or disable.
Only system apps, root, or a privileged helper can change them.

Google marks analytics and measurement components as protected.
Samsung adds extra restrictions.

ADB shell runs as UID 2000, which is not privileged, so PMS throws a SecurityException when you try to disable these components.

4. Second attempt: Wireless debugging
A. I enabled wireless debugging and paired the device
a. I opened Developer options > Wireless debugging
b. I tapped "Pair device with pairing code"
c. Android displayed a 6-digit numeric pairing code
d. On the computer I ran:
I. adb pair <phone-ip>:<pairing-port>
i. Example: adb pair 192.168.1.44:37099
ii. I entered the 6-digit code when prompted
e. After pairing succeeded, I connected to the debug port:
I. adb connect <phone-ip>:<debug-port>
i. Example: adb connect 192.168.1.44:60001
ii. This established the actual debugging channel

B. App Manager launched its privileged server automatically
a. App Manager displayed the command it *would* run if the
automatic launch failed:
I. ./run_server.sh 60001 wind-keg-raid
i. 60001 was the debug port
ii. wind-keg-raid was the session token Android generated
b. These commands are *not* instructions for normal use. They are
fallback commands only. I did not run them.

C. What Muntashirakon actually suggests (fallback only)
a. If the automatic privileged server launch fails, App Manager
tells you to run one of these manually:
I. sh /storage/emulated/0/Android/data/\
io.github.muntashirakon.AppManager/cache/run_server.sh \
60001 wind-keg-raid
II. If that gives "permission denied", use:
sh /data/user_de/0/io.github.muntashirakon.AppManager/\
cache/run_server.sh 60001 wind-keg-raid
b. These commands manually start the privileged helper. They are
only needed if App Manager cannot start it on its own.

D. Limitation
a. This elevated App Manager only
b. It did not elevate ADB shell

5. Third attempt: App Manager (component tabs)
A. I opened App Manager > PulseSMS
B. I scrolled down to the component tabs:
a. Activities
b. Services
c. Receivers
d. Providers
C. I opened the Services and Receivers tabs
a. Under the Receivers tab, I could see this component:
I. com.google.android.gms.measurement.AppMeasurementReceiver
b. Under the Services tab I could see these components:
II. com.google.android.gms.measurement.AppMeasurementService
III. com.google.android.gms.measurement.AppMeasurementJobService
D. Problem
a. In App Manager v4.x these tabs are read-only
b. There are no enable or disable toggles anywhere
c. Long-pressing only selects text
d. No actions are exposed in the UI at all
E. This is where I realized:
a. App Manager 3.x did have full component toggles
I. You could disable Services, Receivers, Providers, Activities
II. It actually changed component states
b. App Manager 4.x removed the entire component-toggle system
I. The tabs remain, but only as viewers
II. No toggles, no actions, no controls
F. Result
a. I could see the Measurement components
b. But I could not disable them
c. This attempt failed because the feature was removed in v4.x
Sigh.

6. Fourth attempt: Shizuku
A. I already had Shizuku installed
a. Shizuku normally works by giving apps elevated access through
its own privileged API
b. On Samsung, Shizuku gets more authority when paired via
Wireless Debugging than via USB

B. I started the Shizuku server using USB ADB (Shizuku's own method)
a. The command Shizuku requires is:
adb shell sh /sdcard/Android/data/moe.shizuku.privileged.api/start.sh

b. Shizuku printed the following log:
info: start.sh begin
info: attempt to copy starter from
/storage/emulated/0/Android/data/moe.shizuku.privileged.api/starter
to /data/local/tmp/shizuku_starter
info: exec /data/local/tmp/shizuku_starter
info: starter begin
info: killing old process...
info: apk path is
/data/app/~~j2Bfj74f4DUXxNA5r8nvlQ==/moe.shizuku.privileged.api-\
EfgdS0yVAmbHZDgZAOOXtg==/base.apk
info: starting server...
info: shizuku_starter exit with 0

C. I then paired Shizuku with Wireless Debugging on the phone
a. In Shizuku I tapped the Pairing button
b. In Shizuku I tapped Developer Options (opens system settings)
c. In Settings I tapped the text "Wireless debugging"
d. I tapped "Pair device with pairing code" to get the 6-digit code
e. I swiped down the notification shade to enter the pairing code
f. Shizuku successfully paired and showed "Running" with elevated
authority via wireless debugging

D. Result
a. Shizuku was fully running
b. Shizuku had elevated authority (more than USB gives on Samsung)
c. None of this mattered because App Manager does not use Shizuku
Drat!

E. Conclusion
a. Shizuku provided no additional power with Muntashirakon
b. App Manager cannot talk to Shizuku's privileged API
c. Therefore Shizuku cannot elevate App Manager or enable any
component-level actions inside App Manager. Sigh.

7. Fifth attempt: Going back to ADB again (Firebase components)
A. I tried disabling Firebase-related components, thinking they might
be responsible for analytics:
adb shell pm disable-user --user 0 \
xyz.klinker.messenger/com.google.firebase.iid.\
FirebaseInstanceIdReceiver

adb shell pm disable-user --user 0 \
xyz.klinker.messenger/com.google.firebase.messaging.\
FirebaseMessagingService

adb shell pm disable-user --user 0 \
xyz.klinker.messenger/.api.implementation.firebase.\
MessengerFirebaseMessagingService

B. Why these were not the expected components
a. These components belong to Firebase Cloud Messaging (FCM)
I. They handle push notifications
II. They manage device registration tokens
III. They deliver background messages
b. They do not belong to Firebase Analytics or Google Measurement
I. Analytics uses the com.google.android.gms.measurement.*
components instead
II. Those are the ones that upload analytics bundles to
app-measurement.com
III. They are protected components that ADB cannot disable
c. Disabling FCM components does nothing to stop analytics because
FCM and Measurement are completely separate subsystems

C. Result
a. These turned out not to be the Measurement components I needed
b. Besides, ADB still could not disable protected components
c. Even if ADB had disabled them, it would not have affected
Google Measurement or analytics uploads. Sigh.

8. Final working solution: App Ops
A. I opened App Manager while elevated (wireless debugging active)
a. I verified elevation by checking:
I. 3 dots > Settings > Mode of operation
II. There was a blue status under "Mode of operation"
VERY IMPORTANT! It said:
ADB
Remote server is active
Remote services are active
Connected via remote service
This confirmed that App Manager was connected to the
privileged server and not running in "no root" mode.
III. In addition, there is the notable presence of extra tabs:
a. App Ops
b. UID Ops
c. Permission Flags
d. Runtime Flags
IV. These lines & tabs ONLY appear when the privileged server
is running and App Manager is bound to it
V. When tapping "Change mode" I saw the actual mode list:
(_)Auto
(_)Root
(_)ADB over TCP
(o)Wireless debugging
(_)No root
Wireless debugging was selected, confirming the correct mode

B. I opened PulseSMS inside App Manager
a. I scrolled to the "App Ops" tab
b. I located the operations that control background execution
and wake behavior
c. I identified the ops responsible for analytics behavior

C. Hence, I denied the following App Ops for PulseSMS
a. RUN_ANY_IN_BACKGROUND
I. Prevents the app from running arbitrary background tasks
II. Blocks analytics upload jobs
b. RUN_IN_BACKGROUND
I. Prevents the app from staying alive when not in the
foreground
II. Stops MeasurementService from waking the app
c. WAKE_LOCK
I. Prevents the app from acquiring wake locks
II. Stops analytics from waking the CPU for upload cycles

D. Why do these App Ops matter
a. Google Measurement components rely on:
I. background execution
II. wake locks
III. scheduled jobs
IV. network-available wakeups
b. Denying these ops prevents:
I. analytics bundle creation
II. analytics bundle upload
III. wakeups triggered by MeasurementReceiver
IV. periodic analytics jobs
c. Even though the Measurement components cannot be disabled,
denying these ops effectively neuters them (thank God).

E. Testing the effect of the denied ops
a. I force-stopped PulseSMS
b. And I reopened it normally
c. I verified:
I. messaging still worked
II. notifications still worked
III. sending and receiving SMS/MMS still worked
IV. no crashes
V. no "not responding" messages
d. If I could I would have monitored network traffic
I. Should be no connections to app-measurement.com
II. Should be no analytics upload attempts
III. Should be no wakeups from MeasurementReceiver

F. Persistence of the App Ops
a. I verified that the denied ops stayed denied after a
I. force-stop
II. reboot
III. closing App Manager
IV. reconnecting wireless debugging
b. This confirmed that Samsung did not override the denied ops

9. What was the root cause of the entire journey being so long?
A. Protected components cannot be disabled by ADB
B. App Manager v4.x removed component toggles
C. App Manager's elevation does not elevate ADB
D. Shizuku is irrelevant because App Manager does not use it
E. Therefore
App Ops was the only non-root method that actually worked
(at least on a Samsung, unrooted, Android 13 device)

10. Final outcome
A. PulseSMS telemetry is now effectively disabled
B. Messaging still works
C. No root required
D. No Shizuku required
E. No component toggles required
F. No ADB component disabling required

11. BTW, since it's so hard to elevate Muntashirakon App Manager,
here's how to tell when Muntashirakon App Manager is elevated
A. The main reliable UI indicator is in:
a. 3 dots > Settings > Mode of operation
B. When elevated, App Manager shows BLUE status lines under
"Mode of operation". These appear only when the remote privileged
server is active:
a. ADB
b. Remote server is active
c. Remote services are active
d. Connected via remote service
C. When not elevated, these blue lines are missing.
You may see:
a. The status in red
b. Some lines successful, some not
c. Mostly I saw the first was fine but the other two not fine
D. The "Change mode" screen shows which backend is selected:
a. auto
b. root
c. adb over tcp
d. wireless debugging
e. no root
f. When elevation is active through wireless debugging, the
selected mode will be "wireless debugging". This alone does
not confirm elevation, but it is consistent with it.
E. Why these indicators matter
a. App Manager does not show a banner, toast, icon, or overlay
when elevated.
b. The blue status lines are the main explicit confirmation that
the remote privileged server is connected.
c. Extra tabs (App Ops, UID Ops, Permission Flags, Runtime Flags)
appear when elevated, but these are side effects and not
guaranteed indicators because Samsung may kill the helper.
F. How long elevation lasts
a. Elevation lasts only while the remote privileged server is
connected through wireless debugging.
b. It ends when WiFi drops, the IP changes, the phone sleeps long
enough for debugging to time out, the server process dies, the
session token expires, the phone reboots, or Samsung kills App
Manager.
c. Note that elevation is ephemeral, but the changes made are lasting
G. Summary
a. If the blue lines appear under "Mode of operation", App
Manager is elevated.
b. If they do not appear, elevation is not active.
c. This is the main reliable, intentional UI signal.

12. Samsung-specific constraints (why this was so hard)
A. This device is a USA Samsung model on Android 13
a. Bootloader cannot be unlocked on USA Samsung phones
b. Therefore no root, no Magisk, no custom recovery
B. Samsung blocks pm disable on many protected components
a. Even with ADB, protected components cannot be disabled
b. Samsung's framework enforces extra restrictions on pm commands
C. Samsung's "Wireless debugging" is crippled compared to Pixel
a. Wireless debugging works, but only grants temporary privileges
b. It does not elevate ADB shell beyond normal shell permissions
D. Samsung's security model blocks Shizuku-style elevation
a. Shizuku cannot grant component-level control on Samsung 13
b. App Manager cannot use Shizuku anyway
E. Samsung's OneUI adds additional background execution limits
a. Apps cannot be prevented from waking for analytics via normal
UI
b. System aggressively protects Google components
F. Combined effect
a. No root
b. No bootloader unlock
c. No pm disable for protected components
d. No Shizuku elevation
e. No component toggles in App Manager v4.x
f. Only App Ops remained as a viable non-root method
--- Synchronet 3.21f-Linux NewsLink 1.2