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
1 file changed