Adds basic Bluetooth support to AppRTCMobile

Adds basic Bluetooth support to AppRTCMobile

BUG=webrtc:6649
- Supports Bluetooth Headset profile.
- Detects new BT headset:
  + enabled at start, and
  + powered on during active call.
- Enables/disables BT SCO channel when BT device is selected.
- Removes proximity sensor usage to avoid conflicts (will be added again later).
- Adds new (unused) APIs to explicitly select audio device.
- Starts routing audio to BT headset when enabled, i.e, BT is default.

Committed: https://crrev.com/c3c2f318521270ac42e3721d707259a29288e98c
Cr-Commit-Position: refs/heads/master@{#15610}

[henrika_webrtc, 2016-11-15 14:30:19]

Description was changed from

==========
Adds basic Bluetooth support to AppRTCMobile

BUG=
==========

to

==========
Adds basic Bluetooth support to AppRTCMobile

BUG=webrtc:6649
==========

[henrika_webrtc, 2016-11-23 10:02:53]

Description was changed from

==========
Adds basic Bluetooth support to AppRTCMobile

BUG=webrtc:6649
==========

to

==========
Adds basic Bluetooth support to AppRTCMobile

BUG=webrtc:6649

- Supports Bluetooth Headset profile.
- Detects new BT headset:
  + enabled at start, and
  + powered on during active call.
- Enables/disables BT SCO channel when BT device is selected.
- Removes proximity sensor usage to avoid conflicts (will be added again later).
- Adds new (unused) APIs to explicitly select audio device.
==========

[henrika_webrtc, 2016-11-23 10:02:54]

henrika@webrtc.org changed reviewers:
+ magjed@webrtc.org

[henrika_webrtc, 2016-11-23 10:03:04]

PTAL

[henrika_webrtc, 2016-11-23 10:12:50]

Description was changed from

==========
Adds basic Bluetooth support to AppRTCMobile

BUG=webrtc:6649

- Supports Bluetooth Headset profile.
- Detects new BT headset:
  + enabled at start, and
  + powered on during active call.
- Enables/disables BT SCO channel when BT device is selected.
- Removes proximity sensor usage to avoid conflicts (will be added again later).
- Adds new (unused) APIs to explicitly select audio device.
==========

to

==========
Adds basic Bluetooth support to AppRTCMobile

BUG=webrtc:6649

- Supports Bluetooth Headset profile.
- Detects new BT headset:
  + enabled at start, and
  + powered on during active call.
- Enables/disables BT SCO channel when BT device is selected.
- Removes proximity sensor usage to avoid conflicts (will be added again later).
- Adds new (unused) APIs to explicitly select audio device.
- Starts routing audio to BT headset when enabled, i.e, BT is default.
==========

[magjed_webrtc, 2016-11-28 12:59:46]

AppRTCAudioManager has too much stuff in it now. Add the Bluetooth logic to a
new class instead. Also, you need to unittest all this new logic.

https://codereview.webrtc.org/2501983002/diff/140001/webrtc/examples/androida...
File webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java
(right):

https://codereview.webrtc.org/2501983002/diff/140001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:37: //
AppRTCAudioManager manages all audio related parts of the AppRTC demo.
We are not following the style guide strictly when it comes to Java comments in
WebRTC, so I don't have strong opinions when new code is added, but I don't see
any reason to change existing correct Java doc code to the worse. The style
guide we should try to follow is here:
https://google.github.io/styleguide/javaguide.html#s7-javadoc.

https://codereview.webrtc.org/2501983002/diff/140001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:115:
private boolean hasBluetoothPermission = false;
I don't think it's a good idea to cache permission lookup results. Can't we just
call hasPermission when needed instead?

https://codereview.webrtc.org/2501983002/diff/140001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:290:
handlerThread.start();
It looks like you are only using this thread for a timeout. It's too expensive
to create a new thread just for that. Also, I don't see any synchronization so
it must be racy with the thread(s) that are making the callbacks. What thread(s)
are the other callbacks called from? Are they all from the main thread? Please
comment and add thread checkers.

[henrika_webrtc, 2016-11-28 14:06:08]

Thanks,

given the scope of proposed changes, would it be OK if I try to come back with
a second version where BT logic is broken out and then see if I can add unit
test
in a separate CL as a third step?

[henrika_webrtc, 2016-11-28 14:06:19]

https://codereview.webrtc.org/2501983002/diff/140001/webrtc/examples/androida...
File webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java
(right):

https://codereview.webrtc.org/2501983002/diff/140001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:37: //
AppRTCAudioManager manages all audio related parts of the AppRTC demo.
On 2016/11/28 12:59:45, magjed_webrtc wrote:
> We are not following the style guide strictly when it comes to Java comments
in
> WebRTC, so I don't have strong opinions when new code is added, but I don't
see
> any reason to change existing correct Java doc code to the worse. The style
> guide we should try to follow is here:
> https://google.github.io/styleguide/javaguide.html#s7-javadoc.

Acknowledged.

https://codereview.webrtc.org/2501983002/diff/140001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:115:
private boolean hasBluetoothPermission = false;
On 2016/11/28 12:59:45, magjed_webrtc wrote:
> I don't think it's a good idea to cache permission lookup results. Can't we
just
> call hasPermission when needed instead?

Acknowledged.

https://codereview.webrtc.org/2501983002/diff/140001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:290:
handlerThread.start();
Will see if I can resolve in ant alternative way. We discussed it and I figured
this was the approach you preferred. Will rewrite somehow.

[magjed_webrtc, 2016-11-29 19:59:52]

On 2016/11/28 14:06:08, henrika_webrtc wrote:
> Thanks,
> 
> given the scope of proposed changes, would it be OK if I try to come back with
> a second version where BT logic is broken out and then see if I can add unit
> test
> in a separate CL as a third step?

Yes, it's ok. It will be easier to see what kind of tests we can add once the
bluetooth logic is broken out. It should be possible to use Robolectric to mock
the android.bluetooth stuff.

Also, it feels like bluetooth support is functionality that we might want to
move from the examples folder to the real code base at some point.

https://codereview.webrtc.org/2501983002/diff/140001/webrtc/examples/androida...
File webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java
(right):

https://codereview.webrtc.org/2501983002/diff/140001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:290:
handlerThread.start();
On 2016/11/28 14:06:18, henrika_webrtc wrote:
> Will see if I can resolve in ant alternative way. We discussed it and I
figured
> this was the approach you preferred. Will rewrite somehow.

I thought you would do more than just a timeout. Just do 'handler = new
Handler()' (use current thread) or 'handler = new
Handler(Looper.getMainLooper())' instead.

[henrika_webrtc, 2016-11-30 08:30:10]

Thanks, working on the new class now. Let me upload it when done and see what
feels best then.
Probably best to ensure that it is OK before doing work on tests.

Just FYI, the BT parts are basically only an extension (complex, agree) to the
audio device module (ADM).
All it does is really to inform the AMD that "BT is now available" and "start
audio routing via BT".
That said, the BT class can't be totally standalone but must communicate with
the ADM as well.

Will take your "Handler comments" into account as well.

[henrika_webrtc, 2016-12-02 13:08:03]

Main BT functionality is now broken out in a separate class. Hope it is OK to
review these parts first
and then discuss if test is needed in the same CL or if it can be landed
separately.

Tested cases like:

1) Start call without any device enabled.
2) Start call with BT device enabled and verify that audio is routed to BT
device.
3) Start call with BT device off, enable BT device and verify audio over BT.
4) Start call with BT device off, enable BT device, disable and enable again and
verify audio
5) etc.

[henrika_webrtc, 2016-12-02 13:08:13]

PTAL

[magjed_webrtc, 2016-12-07 11:09:43]

https://codereview.webrtc.org/2501983002/diff/180001/webrtc/examples/androida...
File webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java
(left):

https://codereview.webrtc.org/2501983002/diff/180001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:62: //
Proximity sensor object. It measures the proximity of an object in cm
I'm sorry to have to give more annoying comments, but you can remove the
proximity code in a separate CL in order to reduce the diff? It's really hard
for me review the code when the diff is this large.

https://codereview.webrtc.org/2501983002/diff/180001/webrtc/examples/androida...
File webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java
(right):

https://codereview.webrtc.org/2501983002/diff/180001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:19:
import android.content.pm.PackageManager;
Revert this change, it's not sorted now.

https://codereview.webrtc.org/2501983002/diff/180001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:32: //
AppRTCAudioManager manages all audio related parts of the AppRTC demo.
Revert these comment changes.

https://codereview.webrtc.org/2501983002/diff/180001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:39: //
AudioDevice is the names of possible audio devices that we currently
Revert this comment change as well. Same for the rest of the CL.

https://codereview.webrtc.org/2501983002/diff/180001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:333:
public void updateAudioDeviceState() {
Please move this function back to make the diff smaller (I understand you want
to keep the private/public separated). You can move it in a final patch set
after you get it stamped.

[henrika_webrtc, 2016-12-07 12:55:42]

Thanks!

Did my best to simplify the diff.

Also added first version of unit test. Not done yet.

https://codereview.webrtc.org/2501983002/diff/180001/webrtc/examples/androida...
File webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java
(left):

https://codereview.webrtc.org/2501983002/diff/180001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:62: //
Proximity sensor object. It measures the proximity of an object in cm
Will fix of course ;-)

https://codereview.webrtc.org/2501983002/diff/180001/webrtc/examples/androida...
File webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java
(right):

https://codereview.webrtc.org/2501983002/diff/180001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:19:
import android.content.pm.PackageManager;
I might be slow but what's wrong? Can't see that actually.

https://codereview.webrtc.org/2501983002/diff/180001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:32: //
AppRTCAudioManager manages all audio related parts of the AppRTC demo.
On 2016/12/07 11:09:43, magjed_webrtc wrote:
> Revert these comment changes.

Done.

https://codereview.webrtc.org/2501983002/diff/180001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:39: //
AudioDevice is the names of possible audio devices that we currently
On 2016/12/07 11:09:43, magjed_webrtc wrote:
> Revert this comment change as well. Same for the rest of the CL.

Done.

https://codereview.webrtc.org/2501983002/diff/180001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:333:
public void updateAudioDeviceState() {
On 2016/12/07 11:09:43, magjed_webrtc wrote:
> Please move this function back to make the diff smaller (I understand you want
> to keep the private/public separated). You can move it in a final patch set
> after you get it stamped.

Done.

[henrika_webrtc, 2016-12-07 12:56:54]

PTAL (exclude unit test for now)

[henrika_webrtc, 2016-12-08 11:49:01]

The CQ bit was checked by henrika@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-08 11:49:13]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[henrika_webrtc, 2016-12-08 11:50:35]

Finalized the tests. Now contains seven tests in total. Hope you like them ;-)

PTAL

[commit-bot: I haz the power, 2016-12-08 12:32:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-08 12:32:52]

Dry run: This issue passed the CQ dry run.

[magjed_webrtc, 2016-12-10 19:34:45]

This looks good overall, especially the new AppRTCBluetoothManager.java and
BluetoothManagerTest.java.

My comments are mainly nits, except the comment about the threading model in
AppRTCAudioManager. When you address that, I will stamp the CL.

And yes, I like the tests ;-)

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
File webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java
(right):

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:81: //
TODO(henrika): always set to AudioDevice.NONE today. Add support for
Is this comment correct? |userSelectedAudioDevice| can be set by
selectAudioDevice().
Can you add a comment explaining why both selectedAudioDevice and
userSelectedAudioDevice is needed and how they differ?

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:379:
public synchronized Set<AudioDevice> getAudioDevices() {
These functions that you have marked synchronized, why is that needed and what
thread(s) are they called on? It looks strange because the variables here are
modified in other functions that are not synchronized, so it's not thread safe
anyway. Also, you use a ThreadChecker in updateAudioDeviceState() and you call
that function from the synchronized selectAudioDevice() function, which means
that selectAudioDevice() has a specific thread requirement anyway.

That suggests to me that all these functions are called from one thread only
(probaby the main thread). Is it possible to add
ThreadUtils.checkIsOnMainThread() in every function and remove the thread
checker and synchronized statements?

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:434:
public void updateAudioDeviceState() {
It would be nice with tests for this function as we discussed offline. You don't
have to do it in this CL though, but maybe it can be added in the future,
similar to what you have done for AppRTCBluetoothManager.java.

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:475:
boolean audioDeviceSetUpdated =
Is it possible to write it like this instead:
boolean audioDeviceSetUpdated = !audioDevices.equals(newAudioDevices);
audioDevices = newAudioDevices;

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
File
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCBluetoothManager.java
(right):

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCBluetoothManager.java:204:
ThreadUtils.checkIsOnMainThread();
Use threadChecker.checkIsOnValidThread() instead. Or remove |threadChecker| and
use ThreadUtils.checkIsOnMainThread() everywhere instead.

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCBluetoothManager.java:372:
if (devices.size() == 0) {
nit: Use devices.isEmpty() instead.

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCBluetoothManager.java:378:
if (bluetoothDevice == null) {
Join this if-statement with the one above since they are the same. I.e.
if (devices.isEmpty()) {
  bluetoothDevice = null;
  bluetoothState = State.HEADSET_UNAVAILABLE;
  Log.d(TAG, "No connected bluetooth headset");
} else {
  // Always use first device is list. Android only supports one device.
  bluetoothDevice = devices.get(0);
  bluetoothState = State.HEADSET_AVAILABLE;
  Log.d(TAG, "Connected bluetooth headset: "
      + "name=" + bluetoothDevice.getName() + ", "
      + "state=" +
stateToString(bluetoothHeadset.getConnectionState(bluetoothDevice))
      + ", SCO audio=" + bluetoothHeadset.isAudioConnected(bluetoothDevice));
}

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCBluetoothManager.java:425:
if (pairedDevices.size() > 0) {
nit: !pairedDevices.isEmpty()

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCBluetoothManager.java:485:
updateAudioDeviceState();
Move this after the if-statement since you do it last in both branches.

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCBluetoothManager.java:497:
return audioManager.isBluetoothScoOn();
I personally would just inline audioManager.isBluetoothScoOn() instead of adding
a function for it, but I don't have a strong opinion about this.

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCBluetoothManager.java:505:
// The profile is in disconnected state.
Remove |stateString| and just do
return "DISCONNECTED".
Similar for the other cases.

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCBluetoothManager.java:509:
// The profile is in connected state.
Many of these comments provide no extra information beyond the code, I would
just remove those. It looks like only BluetoothAdapter.STATE_TURNING_ON and
BluetoothAdapter.STATE_TURNING_OFF have interesting comments.

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androidj...
File
webrtc/examples/androidjunit/src/org/appspot/apprtc/BluetoothManagerTest.java
(right):

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androidj...
webrtc/examples/androidjunit/src/org/appspot/apprtc/BluetoothManagerTest.java:209:
public void testBluetoothScoAudioStartAndStop() {
This is exactly what I wanted. It looks very clean! I think tests like this will
help protect against regressions when adding new code or refactoring
BluetoothManager. And now you have added the necessary test infrastructure so
you can easily add more tests if you find strange state sequences out in the
wild.

[henrika_webrtc, 2016-12-12 14:13:25]

Many thanks Magnus.

Should be perfect now ;-)

PTAL

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
File webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java
(right):

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:81: //
TODO(henrika): always set to AudioDevice.NONE today. Add support for
Updated the comments. In short, selectedAudioDevice contains the active device.
It is normally set automatically. Plug in wired headset => selected is set to
wired.
But, user can override and select speaker mode even if wired is plugged in.
Then userSelectedAudioDevice contains SPEAKER in this example.

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:379:
public synchronized Set<AudioDevice> getAudioDevices() {
On 2016/12/10 19:34:44, magjed_webrtc wrote:
> These functions that you have marked synchronized, why is that needed and what
> thread(s) are they called on? It looks strange because the variables here are
> modified in other functions that are not synchronized, so it's not thread safe
> anyway. Also, you use a ThreadChecker in updateAudioDeviceState() and you call
> that function from the synchronized selectAudioDevice() function, which means
> that selectAudioDevice() has a specific thread requirement anyway.
> 
> That suggests to me that all these functions are called from one thread only
> (probaby the main thread). Is it possible to add
> ThreadUtils.checkIsOnMainThread() in every function and remove the thread
> checker and synchronized statements?

Done.

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:434:
public void updateAudioDeviceState() {
I got the same idea when writing the other test. Adding TODO.

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCAudioManager.java:475:
boolean audioDeviceSetUpdated =
Yep, it works ;-)

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
File
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCBluetoothManager.java
(right):

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCBluetoothManager.java:204:
ThreadUtils.checkIsOnMainThread();
On 2016/12/10 19:34:45, magjed_webrtc wrote:
> Use threadChecker.checkIsOnValidThread() instead. Or remove |threadChecker|
and
> use ThreadUtils.checkIsOnMainThread() everywhere instead.

Done.

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCBluetoothManager.java:372:
if (devices.size() == 0) {
On 2016/12/10 19:34:44, magjed_webrtc wrote:
> nit: Use devices.isEmpty() instead.

Done.

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCBluetoothManager.java:378:
if (bluetoothDevice == null) {
Thanks. Done!

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCBluetoothManager.java:425:
if (pairedDevices.size() > 0) {
On 2016/12/10 19:34:45, magjed_webrtc wrote:
> nit: !pairedDevices.isEmpty()

Done.

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCBluetoothManager.java:485:
updateAudioDeviceState();
On 2016/12/10 19:34:44, magjed_webrtc wrote:
> Move this after the if-statement since you do it last in both branches.

Done.

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCBluetoothManager.java:497:
return audioManager.isBluetoothScoOn();
ACK, used same style in AudioManager. Keeping as is to be consistent.

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCBluetoothManager.java:505:
// The profile is in disconnected state.
On 2016/12/10 19:34:45, magjed_webrtc wrote:
> Remove |stateString| and just do
> return "DISCONNECTED".
> Similar for the other cases.

Done.

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androida...
webrtc/examples/androidapp/src/org/appspot/apprtc/AppRTCBluetoothManager.java:509:
// The profile is in connected state.
Agree. Removed.

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androidj...
File
webrtc/examples/androidjunit/src/org/appspot/apprtc/BluetoothManagerTest.java
(right):

https://codereview.webrtc.org/2501983002/diff/240001/webrtc/examples/androidj...
webrtc/examples/androidjunit/src/org/appspot/apprtc/BluetoothManagerTest.java:209:
public void testBluetoothScoAudioStartAndStop() {
Thanks. Agree that it was very useful to add and learn ;-)

[henrika_webrtc, 2016-12-12 14:13:38]

The CQ bit was checked by henrika@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-12 14:13:46]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-12-12 14:36:54]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-12 14:36:55]

Dry run: This issue passed the CQ dry run.

[magjed_webrtc, 2016-12-14 10:35:45]

lgtm

[henrika_webrtc, 2016-12-14 15:00:24]

The CQ bit was checked by henrika@webrtc.org

[commit-bot: I haz the power, 2016-12-14 15:00:34]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-12-14 15:36:57]

CQ is committing da patch.

Bot data: {"patchset_id": 260001, "attempt_start_ts": 1481727624444670,
"parent_rev": "f3d8c78c15f5067cd12335e4b20d700eb85d3d3e", "commit_rev":
"62c9f0373bb17affa4ee73a0c1a0b3293f989eef"}

[commit-bot: I haz the power, 2016-12-14 15:36:59]

Description was changed from

==========
Adds basic Bluetooth support to AppRTCMobile

BUG=webrtc:6649

- Supports Bluetooth Headset profile.
- Detects new BT headset:
  + enabled at start, and
  + powered on during active call.
- Enables/disables BT SCO channel when BT device is selected.
- Removes proximity sensor usage to avoid conflicts (will be added again later).
- Adds new (unused) APIs to explicitly select audio device.
- Starts routing audio to BT headset when enabled, i.e, BT is default.
==========

to

==========
Adds basic Bluetooth support to AppRTCMobile

BUG=webrtc:6649

- Supports Bluetooth Headset profile.
- Detects new BT headset:
  + enabled at start, and
  + powered on during active call.
- Enables/disables BT SCO channel when BT device is selected.
- Removes proximity sensor usage to avoid conflicts (will be added again later).
- Adds new (unused) APIs to explicitly select audio device.
- Starts routing audio to BT headset when enabled, i.e, BT is default.

Review-Url: https://codereview.webrtc.org/2501983002
==========

[commit-bot: I haz the power, 2016-12-14 15:37:00]

Committed patchset #14 (id:260001)

[commit-bot: I haz the power, 2016-12-14 15:37:06]

Description was changed from

==========
Adds basic Bluetooth support to AppRTCMobile

BUG=webrtc:6649

- Supports Bluetooth Headset profile.
- Detects new BT headset:
  + enabled at start, and
  + powered on during active call.
- Enables/disables BT SCO channel when BT device is selected.
- Removes proximity sensor usage to avoid conflicts (will be added again later).
- Adds new (unused) APIs to explicitly select audio device.
- Starts routing audio to BT headset when enabled, i.e, BT is default.

Review-Url: https://codereview.webrtc.org/2501983002
==========

to

==========
Adds basic Bluetooth support to AppRTCMobile

BUG=webrtc:6649

- Supports Bluetooth Headset profile.
- Detects new BT headset:
  + enabled at start, and
  + powered on during active call.
- Enables/disables BT SCO channel when BT device is selected.
- Removes proximity sensor usage to avoid conflicts (will be added again later).
- Adds new (unused) APIs to explicitly select audio device.
- Starts routing audio to BT headset when enabled, i.e, BT is default.

Committed: https://crrev.com/c3c2f318521270ac42e3721d707259a29288e98c
Cr-Commit-Position: refs/heads/master@{#15610}
==========

[commit-bot: I haz the power, 2016-12-14 15:37:07]

Patchset 14 (id:??) landed as
https://crrev.com/c3c2f318521270ac42e3721d707259a29288e98c
Cr-Commit-Position: refs/heads/master@{#15610}