I accidentally disabled the green recording dot forever (I think)

duckduckduck

Yo. A few weeks ago i was stumbling online and found this funny adb command:

adb shell cmd device_config put privacy camera_mic_icons_enabled false default

It's supposed to disable the green recording dot. That means you could turn on a voice recorder, record a conversation and use your phone without anyone knowing (since there is no green dot).

I thought "thats never gonna work", tried it, and it worked. Even after a restart. Then my phone updated to android 16, and now when I try to disable it again using this command:

adb shell cmd device_config put privacy camera_mic_icons_enabled true default

I get an error. For context, I tried re-enabling the dot just after I first disabled it, and that worked.
Here is my error:

(base) user@computer:~$ adb shell cmd device_config put privacy camera_mic_icons_enabled true default

Exception occurred while executing 'put':
java.lang.SecurityException: Permission denial for flag 'privacy/camera_mic_icons_enabled'; allowlist permission granted, but must add flag to the allowlist
	at com.android.providers.settings.SettingsProvider.enforceDeviceConfigWritePermission(SettingsProvider.java:2611)
	at com.android.providers.settings.SettingsProvider.mutateConfigSetting(SettingsProvider.java:1344)
	at com.android.providers.settings.SettingsProvider.insertConfigSetting(SettingsProvider.java:1206)
	at com.android.providers.settings.SettingsProvider.call(SettingsProvider.java:475)
	at android.content.ContentProvider.call(ContentProvider.java:2737)
	at android.content.ContentProvider$Transport.call(ContentProvider.java:639)
	at android.provider.Settings$NameValueCache.putStringForUser(Settings.java:3583)
	at android.provider.Settings$Config.putString(Settings.java:21380)
	at android.provider.SettingsConfigDataStore.setProperty(SettingsConfigDataStore.java:61)
	at android.provider.DeviceConfig.setProperty(DeviceConfig.java:1476)
	at com.android.providers.settings.DeviceConfigService$MyShellCommand.onCommand(DeviceConfigService.java:511)
	at com.android.modules.utils.BasicShellCommandHandler.exec(BasicShellCommandHandler.java:97)
	at android.os.ShellCommand.exec(ShellCommand.java:38)
	at com.android.providers.settings.DeviceConfigService.onShellCommand(DeviceConfigService.java:101)
	at android.os.Binder.shellCommand(Binder.java:1163)
	at android.os.Binder.onTransact(Binder.java:965)
	at android.os.Binder.execTransactInternal(Binder.java:1470)
	at android.os.Binder.execTransact(Binder.java:1404)
(base) user@computer:~$

More context: Both commands still work on my trash phone running LineageOS with android 15.

Did I fuck up? Or did I create a valuable android device?

duckduckduck

I created an android emulator with API 35 (Android 15), and my worries were confirmed - the command still works. Same emulator, API 36 - the command fails with the same error message as above.

Dot off:
https://files.catbox.moe/dzo11t.png
Dot on:
https://files.catbox.moe/nipu4m.png

🥲

Ammako

If possible, I would try to file a bug report for this upstream. It sounds like they noticed the vulnerability and fixed it for the new Android version, but didn't think to automatically re-set (or even simply ignore) the flag for devices that might have potentially already been affected.

Things like this that require developer options and access to an adb debugging connection to exploit might not necessarily be the most critical of vulnerabilities, but the fact they patched it tells me they considered it important enough, and it would probably be good for the OS to detect the incorrect flag and revert it. If anything, just so affected users can correct the issue without having to do a factory reset.

de0u

Ammako It would probably be good for the OS to detect the incorrect flag and revert it. If anything, just so affected users can correct the issue without having to do a factory reset.

I think part of the issue is that Google expects all use of adb to be by developers on non-production devices, for whom wiping a development device is routine, potentially even part of the testing cycle for each new build.

Ammako

de0u fair, but the way I see it, it could also affect regular users who were told to enable developer options by articles online for "this one cool Android tweak everyone should use" that requires enabling and using/granting wireless debugging permissions, and these kinds of apps could make all kinds of changes behind your back as soon as the permission is granted for wireless debugging. Such as disabling the indicator to hide when the camera is in use.

People shouldn't be enabling developer options, and even less granting debugging permissions to apps, but the reality is that average users will do it without really being aware of the potential problems. I don't think Google really has a reason to care if developers choose to disable the indicator on their own test devices, so to have restricted that flag from being modified, I can only assume they wanted to guard against this kind of attack on regular users, or they simply didn't want regular users from being allowed to even intentionally disable it, for their own sake.

Normally I'd agree that developer options are developer options, and that they shouldn't be restricted or blocked just for the sake of protecting regular users, but in this case Google clearly doesn't want developer options to have the power to disable the privacy indicators, and this change could actually lead to the privacy indicator being forced Off, which kind of goes against what they were trying to do with this change. The hypothetical scenario I brought up is not a very high level attack considering that it requires the user to intentionally run an app and intentionally grant it wireless debugging permissions even when the OS warns against it, but if you're going to patch an apparent vulnerability, it might as well be done right.

de0u

Ammako If you're going to patch an apparent vulnerability, it might as well be done right.

Agree!

Ammako it could also affect regular users who were told to enable developer options by articles online for "this one cool Android tweak everyone should use" [...]

RIght now it seems as if the situation is that some people publish those articles to get eyeballs, i.e., revenue from ads, and there is no penalty for publishing dangerous advice, so: free money! If so, then people will continue writing articles containing bad advice.

By no means am I a litigious person, but, aside from public shaming, in theory one of the ways that people can be penalized for publishing bad advice for profit is for some of them to get sued. The outcome might be only that those articles would all include some boilerplate about how developer mode is not "expert mode", developer options are expected to be used only on testing devices before they're wiped, and that any flip of any of those toggles might require a factory reset months down the road. I still think that might be better than the current state of affairs.

duckduckduck

@Ammako
@de0u

To clarify, I was specifically looking for a way to do this, and wish it was just a normal android setting to disable the indicator on a per app basis. Already created an issue in the issue tracker.