[Feature]: Support Dual Call Scenario

[kitsumed]

Is your feature request related to a problem? Please describe.

We currently face challenges with supporting dual call scenarios. To understand, read this comment in the project code. (This is a perm link, it may be outdated with the latest commits.)

General Ideas

One approach I considered is using the READ_CALL_LOG permission to read call logs. From my understanding, call logs are only written after the call ends, with some unknown delay. This would require rewriting a significant part of the existing call handling logic and would mean that the automatic recording feature would need to always record by default and then delete recordings when they should not exist. I am not a fan of this approach, as it has multiple negative implications like always having to immedialy start Shizuku. Therefore I decided to not do this.

Another workaround idea is that when we receive a dual OFFHOOK event, we could attempt to look for ignored call log entries that match the phone number. Since an ignored incoming call counts as ended, this could allow us to detect dual calls with a slight delay. However, I am unsure if there is a better or more reliable method. Honestly, I am also not a fan of this workaround, this would introduce more delay in our call detection logic and is prone to failure/race-conditions.

But even then, both of theses idea would not fully solve the issue:

Major Issue

The main issue arises when someone accepts a second incoming call, which puts the first call on hold. When the user ends the second call and the hold state is removed from the first call, we do not receive a broadcast (or at least not on every phone OEM). Some OEM also sends conflicting broadcast data in theses scenario with wrong data in them. This prevents us from resuming recording for the first call, which is why I am asking for ideas or contributions from other users.

At some point, I also explored fully replacing the deprecated PhoneStateListener with the now-recommended TelephonyManager. Unfortunately, it never provides the phone number for privacy reasons, which limits this approach (see issue tracker comment).

As a personal opinion, I do not consider dual call support an important feature. However, I think that someone will eventually request it, so I still have already considered it and explained the current challenges we face. I do not plan to experiment with dual call support myself right now, but I am open to user ideas, feedback, or proof-of-concept PRs.

Current Behavior

This may be outdated in the future, but at the time of writing this issue, the current behavior of the app is to ignore any dual-call scenario and to carry on as if we were still in the first call. This means that if recording is enabled, it continues recording, and other call-related behavior proceeds normally. The expect behavior may change depending on how the OEM handle dual-call, for example, if it sends an IDLE broadcast quickly followed by an OFFHOOK, it may stop the recording, but from my tests, the google emulator and my test Samsung only sended OFFHOOK broadcast until all of the call ended.

Describe the solution you'd like

The solution is not fully defined yet. Some possible directions could include:

1. Detecting dual call scenarios via call log inspection after OFFHOOK events
2. Alternative TelephonyManager strategies if any workaround allows detection without call logs
3. HiddenAPI?

I am open to contributions, ideas, or suggestions for approaches that might simplify dual call support and make it maintainable.

This is low priority