Correctly propagate service state change
Due to a surprising behavior of Handler.obtainMessage(), the argument that indicated whether the service is available was always read as 0 (enabled), and we never correctly handled the service being unavailable (due to concurrent capture). Bug: 157496890 Test: Enabled debug logging and verified that the message is now passed correctly and that indeed that models get inactivated when capture starts and reactivated when it stops. Change-Id: Ibf4ecdb4e4dd0f5a02d5a388afddb205c29eb2ea
Loading
Please register or sign in to comment