There are 3 different UI controls that look or act like a main disable switch

[yump]

I deleted my home land line from the address book and ran some tests. Truth table with controls as bit positions [1,2,3], where "1" represents the state in the screenshot.

control 1	control 2	control 3	calls are
1	1	1	blocked
1	1	0	allowed
1	0	1	blocked
1	0	0	allowed
0	1	1	allowed
0	1	0	allowed
0	0	1	allowed
0	0	0	allowed

Firstly, control 1, which looks the most like the main disable switch, should please be more clearly labeled. I would suggest that the two button states be called "Screening Active", and "Screening Bypassed".

Secondly, what does control 2, the ⊝ sign in the top right corner, do? It doesn't seem to affect whether calls are blocked, but switching it from 1->0 results in a toast that says "block mode disabled", and 0->1 says "block mode enabled".

This is both a bug report and a reference for myself in the future and anyone else who is similarly confused.

[x13a]

The first one is the main toggle. It has to be Turn ON/OFF, but there was a regression. Will be fixed next release. The second one is block mode. It overrides filter settings to only block calls. It has higher priority than other filters like regex, repeated, etc. The third ones are response options. It is API values Google give us to control how Android will process call blocking. You can use Disallow, Disallow+Reject (default), or Silence.

…

On Tue, Dec 2, 2025, 22:31 yump ***@***.***> wrote: *yump* created an issue (x13a/Silence#282) <#282> Screenshot_2025-12-02-11-42-39-52_fd8520b476e1e16a276ec5b901e971b9.jpg (view on web) <https://github.com/user-attachments/assets/ef782442-bdf5-4f82-bf2a-7c1853260141> Screenshot_2025-12-02-11-42-53-78_fd8520b476e1e16a276ec5b901e971b9.jpg (view on web) <https://github.com/user-attachments/assets/6c730c40-43d3-4aae-ad73-60c702423341> I deleted my home land line from the address book and ran some tests. Truth table with controls as bit positions [1,2,3], where "1" represents the state in the screenshot. control 1 control 2 control 3 calls are 1 1 1 blocked 1 1 0 allowed 1 0 1 blocked 1 0 0 allowed 0 1 1 allowed 0 1 0 allowed 0 0 1 allowed 0 0 0 allowed Firstly, control 1, which *looks* the most like the main disable switch, should please be more clearly labeled. I would suggest that the two button states be called "Screening Active", and "Screening Bypassed". Secondly, what does control 2, the ⊝ sign in the top right corner, do? It doesn't seem to affect whether calls are blocked, but switching it from 1->0 results in a toast that says "block mode disabled", and 0->1 says "block mode enabled". This is both a bug report and a reference for myself in the future and anyone else who is similarly confused. — Reply to this email directly, view it on GitHub <#282>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMXH7T6LUG7SDMBG3O7NYCL37XLJ5AVCNFSM6AAAAACN2OYWUOVHI2DSMVQWIX3LMV43ASLTON2WKOZTGY4DOMBYGAZTMMQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[yump]

The second one is block mode. It overrides filter settings to only block
calls. It has higher priority than other filters like regex, repeated, etc.

I am very sorry, but I was still confused.

I tested again calling from a number in my contacts list, with Extra->Contacts enabled, in state [1,1,1] and [1,0,1] (block mode en/dis). The calls were allowed whether block mode is on or off.

I am not familiar with Java, but I looked at the code, and AIUI block mode should act as a second master switch that blocks all incoming calls?

...

I tried it again and now it does seem to do that. Is it possible that my earlier test was thrown off by Android caching the decision?

If block mode does indeed override filters and block all incoming calls, the toasts should perhaps say, "blocking all calls regardless of other settings" when block mode is turned on, and "blocking or allowing calls according to filters" when block mode is turned off.

I might also suggest a very prominent warning about settings not taking effect immediately because Android caches allow/deny decisions. I only figured this out because the help text from the Repeated Calls settings was fresh in my brain.

[x13a]

As I remember on Android 11+ if the app doesn't have access to Contacts, Call Screening API won't get these calls. There was a description when block mode was a switch "Block all incoming calls. To also block numbers from contacts you have to grant a permission."

[yump]

I have already given contact permissions, and after waiting some time for caches to expire, I think everything works as you've said: All calls are blocked with block mode enabled, numbers in contacts are allowed with block mode disabled, and all numbers are allowed with the master bypass (control 1) set to "off".

I have been using Silence for over a year without touching the controls -- this all came up today because I needed to allow all calls in order to Transact With Bureaucracy, and had trouble figuring out which option would actually do that. IIRC I had to try several different call-filter apps before I found one that worked at all with my device (Oneplus), so Silence is well above par.

Once I am out of the bureaucratic hellfire, would an untested PR be welcome to implement this?:

If block mode does indeed override filters and block all incoming calls, the toasts should perhaps say, "blocking all calls regardless of other settings" when block mode is turned on, and "blocking or allowing calls according to filters" when block mode is turned off.

IANA Android programmer and would have no idea where to even begin with a warning about caching, but rewriting the toast string to be more clear should be easy enough without figuring out the build tooling.

[x13a]

would an untested PR be welcome to implement this

you are welcome

[ged-ward]

@x13a I’ve been playing around with the options that @yump mentioned, and I’m experiencing exactly what described the issue.

Personally, I’ve always used options 1 and 2 together, which is why I needed a shortcut to enable/disable the global blocking and ended up sending the pull request. However, when using options 1 and 3 enabled, calls are still coming through to the phone, as if the rules were being bypassed.

I’ve tried clearing the cache every time I updated the options, without success. I also made sure all the required permissions are granted — specifically, I’m referring to the “allow calls from contacts” option.

Is there anything else I should check in the app? I’ll try to look into what can be done from the source code as well.

Cheers

[ged-ward]

@x13a @yump I've created a pull request to address the contact validation issue and other additional points I found.
#285