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