| commit | 2c8973c39478cd3c8cf11d9f27cc0556a106d006 | [log] [tgz] |
|---|---|---|
| author | Atneya Nair <atneya@google.com> | Wed May 10 17:26:30 2023 -0700 |
| committer | Android Build Coastguard Worker <android-build-coastguard-worker@google.com> | Tue May 23 17:23:31 2023 +0000 |
| tree | 63d403875e757bdc50dc63382303d1111ff61a80 | |
| parent | 80e4a9f6dcde1ef5b775816865299718c3373934 [diff] |
Force unsilence record clients on startInput We call startRecording unconditionally in startInput, so we must update the client state to be unsilenced (since we are treating as such). We subsequently re-update the silence state (with the client marked as active to dispatch ops) in updateUidStates_l. This fixes an issue where we call startRecording for a silenced client, then call it again when it moves to unsilenced when the client is active. Since startRecording is ref-counted, this leaves the client in the recording state leading to incorrect appop attributions. Bug: 279905816 Bug: 281485019 Test: Manual verification of repro cases + verbose log analysis (cherry picked from https://googleplex-android-review.googlesource.com/q/commit:e7720b379bfaba648ab6d85c4c2df6f03ec854d3) (cherry picked from https://googleplex-android-review.googlesource.com/q/commit:2951ad10a6641f9b3554d674877ad314e8cc011f) Merged-In: I31d50457ca8adae577407a28d4d4c0e8582bac5d Change-Id: I31d50457ca8adae577407a28d4d4c0e8582bac5d