원문 :  http://www.cyworld.com/csm47/3486608

안드로이드는 블루투스 프로토콜 스택을 포함하고 있기있기 때문에 블루투스 디바이스들과 무선으로 데이터를 교환할 수 있다. 어플리케이션 프레임웍은 안드로이드안드로이드 블루투스 API를 사용해 블루투스에 억세스 할 수 있다. 블루투스 API를 사용하면사용하면 다음과 같은 작업을 할 수 있다.

• 다른 블루투스블루투스 디바이스 검색
• 페어링 된 블루투스 디바이스를 위한 로컬 블루투스 아답터아답터 퀘리
• RFCOMM 채널 설정
• SDP(Service Discovery Protocol)을 통한 다른다른 디바이스와의 커넥션
• 양방향 데이터 전송
• 복수 커넥션 관리

- 기초

이 문서는 블루투스를 사용해 통신하는데통신하는데 필요한 4가지 주요 태스크(블루투스 셋업, 페어링 되어 있거나 주변에 있는 기기기기 검색, 디바이스와 연결, 디바이스간 데이터 전송)를 수행하기 위해 안드로이드 블루투스 API를API를 어떻게 사용하는가를 설명한다.
모든 블루투스 API는 android.bluetooth 패키지에 들어있다. 다음은다음은 블루투스 연결을 만드는데 필요한 클래스들의 요약이다.

• BluetoothAdapter -- 로컬 블루투스 아답터 하드웨어를 나타낸다. BluetoothAdapter는 모든 블루투스를 통한 상호작용의 엔트리포인트이다.엔트리포인트이다. 이 객체를 사용해서 다른 블루투스 디바이스 찾기, 페어링 된 디바이스 퀘리,퀘리, 알려진 MAC address를 사용해 BluetoothDevice 인스턴스 얻기, 다른 디바이스에서 부터의 통신통신 요구를 기다리기 위한 BluetoothServerSocket 만들기를 할 수 있다.
• BluetoothDevice -- 상대방의 블루투스 디바이스를 나타낸다. 이 객체를 사용하면 BluetoothSocket을 통해 상대방 디바이스와디바이스와 커넥션을 요구하거나 이름, 주소, 클래스, 페어링 상태등의 정보를 퀘리할 수 있다.있다.
• BluetoothSocket - 블루투스 소켓을 위한 인터페이스를 나타낸다. 어플리케이션이 InputStream과 OutputStream을OutputStream을 사용해서 다른 블루투스 디바이스와 데이터 교환을 할 수 있는 연결 포인트이다.포인트이다.
• BluetoothServerSocket – Incoming 리퀘스트를 위해 listen하고 있는 오픈된 서버소켓(TCP ServerSocket과ServerSocket과 유사)을 나타낸다. 두대의 안드로이드 디바이스를 연결하기 위해 한쪽의 디바이스는 이 클래스를클래스를 사용해서 서버소켓을 오픈해야만 한다. 원격 블루투스 디바이스가 디바이스에 커넥션 리퀘스트를 할할 때 BluetoothServerSocket은 커넥션이 연결되면 연결된 BluetoothSocket을 리턴해준다.
• BluetoothClass - 블루투스블루투스 디바이스의 일반적 특성과 기능을 나타낸다. 이 클래스는 디바이스의 디바이스 클래스와 서비스를서비스를 정의하는 읽기 전용 속성의 집합이다.

- 블루투스블루투스 퍼미션

어플리케이션에서 블루투스 기능을 사용하려면 최소한 BLUETOOTH와 BLUETOOTH_ADMINBLUETOOTH_ADMIN 둘중에 하나의 블루투스 퍼미션을 선언해줘야 한다. 커넥션 요구, 커넥션 accept, 데이터데이터 전송등의 블루투스 통신을 하기 위해서는 BLUETOOTH 퍼미션이 필요하다.
디바이스 discovery를 시작하거나시작하거나 블루투스 설정을 조작하려면 BLUETOOTH_ADMIN 퍼미션이 필요하다.
BLUETOOTH_ADMIN 퍼미션을 사용하려면 BLUETOOTHBLUETOOTH 퍼미션도 꼭 있어야만 한다. 매니페스트 파일에 블루투스 퍼미션을 선언해준다.

<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />

- 블루투스 셋업

어플리케이션이 블루투스로 통신을통신을 하기 전에 디바이스가 블루투스를 지원하는지 확인할 필요가 있다. 그리고 블루투스를 지원한다면지원한다면 활성화 되었는지도 확인해줘야 한다. 만일 블루투스를 지원하지 않으면 블루투스 기능을 비활성화비활성화 시켜야 한다. 블루투스를 지원하지만 활성화 되어 있지 않으면 사용자가 어플리케이션을 떠나지떠나지 않고 블루투스를 활성화하도록 요구할 수 있다. 이 작업은 BluetoothAdapter를 사용해서 두두 단계로 수행할 수 있다.

1.BluetoothAdapter 를 얻는다.
모든 블루투스 액티비티를 위해 BluetoothAdapter가 요구된다. BluetoothAdapter를 얻기 위해서는 스태틱 메소드인메소드인 getDefaultAdapter()를 호출하면 된다. 그러면 디바이스의 블루투스 아답터를 나타내는 BluetoothAdapter 인스턴스를 리턴한다.리턴한다.

BluetoothAdapter mBTAdapter = BluetoothAdapter.getDefaultAdapter();
if (mBTAdapter == null) {
// devicedevice does not support Bluetooth
}

2.블루투스 활성화
블루투스가 활성화 되어있는지 확인해야 한다. isEnabled()를 호출해서 블루투스가블루투스가 현재 활성화되어 있는지 확인한다. 메소드가 false를 리턴하면 블루투스가 비활성화되어 있는 것이다.것이다. 블루투스를 활성화 시키려면 ACTION_REQUEST_ENABLE 인텐트로 startActivityForResult()를 호출하면 된다.

If (!mBTAdapter.isEnabled()) {
Intent enableBtIntentenableBtIntent = new Intent(BluetoothAdapter.ACTION_REQUEST_ENABLE);
startActivityForResult(enableBtIntent, REQUEST_ENABLE_BT)REQUEST_ENABLE_BT) ;
}

그림 1과 같이 블루투스를블루투스를 활성화하기 위한 퍼미션을 요구하는 대화창이 나타난다. 사용자가 “Yes”를 선택하면 시스템은 블루투스를블루투스를 활성화시키고 그 과정이 끝나면 어플리케이션으로 포커스가 돌아오게 된다.
블루투스 활성화가 성공하면성공하면 액티비티는 onActivityResult() 콜백에서 RESULT_OK를 리턴받게 된다. 블루투스가 에러로 인해 (또는 사용자가사용자가 “No”를 선택해서) 활성화되지 못하면 RESULT_CANCELED가 리턴된다. 옵션으로 블루투스 상태가 변경될 때때 마다 시스템이 브로드캐스하는 ACTION_STATE_CHANGED 인텐트를 listen하도록 할 수도 있다.

- 디바이스 검색

BluetoothAdapter를 사용하면 디바이스디바이스 discovery 또는 페어링 된 디바이스 목록을 퀘리해서 원격 블루투스 디바이스를 찾을찾을 수 있다.
디바이스 discovery는 주변의 활성화 된 블루투스 디바이스를 찾고 각각에각각에 대한 정보를 요구하는 검색 단계이다. 하지만 통신가능 범위에 들어있는 블루투스 디바이스라디바이스라 해도 현재 discoverable 하도록 활성화 되어 있어야만 discovery 요구에 응답한다. 디바이스가디바이스가 discoverable 상태인 경우 discovery 요구에 디바이스 이름, 클래스, MAC 주소같은 정보를정보를 공유함으로서 응답한다. 이 정보를 사용해서 discovery를 수행한 디바이스는 발견된 디바이스에 커넥션을커넥션을 시작하도록 선택할 수 있다.
일단 원격 디바이스와 처음으로 연결이 이루어지면 자동으로자동으로 사용자에게 페어링을 할 것인가 물어보게 된다. 디바이스 페어링이 이루어지면 상대 디바이스에디바이스에 대한 기본 정보(디아비스 이름, 클래스, MAC 주소 등)가 저장되고 그 내용은내용은 블루투스 API를 통해 읽을 수 있게 된다. 이미 알고 있는 원격디바이스의원격디바이스의 MAC 주소를 사용하면 아무때나 (물론 해당 디바이스가 통신 가능범위에 있다는 가정가정 하에) discovery를 수행할 필요 없이 바로 커넥션 과정을 시작할 수 있다.있다.
페어링과 연결된것의 차이점은 잘 알고 있어야 한다. 페어링은 두 디바이스가 각자각자 상대방의 존재를 알고 있고 인증과정에 사용할 link-key를 공유하고 있어 서로간에 암호화암호화 된 연결을 설정할 수 있다는걸 의미한다. 연결된것은 디바이스가 현재 RFCOMM 채널을채널을 공유하고 있어 서로 데이터를 전송할 수 있는 상태를 의미한다.
현재 안드로이드안드로이드 블루투스 API는 RFCOMM 커넥션을 설정하기 전에 디바이스가 페어링 되어야만 한다. (블루투스(블루투스 API에서 암호화된 커넥션을 시작하려고 할 때 페어링이 자동을 이루어진다.)
다음의 섹션은섹션은 페어링 된 디바이스를 찾거나, 디바이스 discovery를 사용해 새 디바이스를 찾는 방법을방법을 설명한다.
주: 안드로이드 디바이스는 기본적으로 not discoverable 상태이다. 시스템 설정을설정을 통해 짧은 시간동안 디바이스를 discoverable 상태로 만들거나 어플리케이션에서 직접 discoverable 상태로상태로 만들어 줄 수 있다.

- 페어링 된 디바이스디바이스 퀘리

디바이스 discovery를 수행하기 전에 원하는 디바이스가 이미이미 페어링 되어 있는가 확인해 볼 필요가 있다. 확인하기 위해서 getBondedDevices()를 호출하면호출하면 된다. 그러면 페어링 된 디바이스들의 집합인 BluetoothDevices 를 돌려준다. 예를 들어들어 페어링 된 모든 디바이스를 퀘리한 다음 ArrayAdapter를 사용해 페어링 된 각각 디바이스의 이름을 보여줄 수 있다.

Set<BluetoothDevice> pairedDevices == mBluetoothAdapter.getBondedDevices();
if (pairedDevices.size() <> 0) {
for (BluetoothDevice device : pairedDevices) {
mArrayAdapter.add(device.getName() + “\n” + device.getAddress());
} }
}

BluetoothDevice 객체에서 연결을 시작하기 위해위해 필요한 정보는 MAC address만 있으면 된다. 위의 예제에서 이 정보는 사용자에게사용자에게 보여지는 ArrayAdapter의 일부분에 저장되어 있다. MAC 주소는 나중에 연결을 시작하기 위해위해 추출할수도 있다.

- 디바이스 discovery

디바이스디바이스 discovery를 시작하려면 startDiscovery()를 호출하면 된다. 이 과정은 비동기식이라 메소드를 호출하면 discovery가discovery가 성공적으로 시작되었나 결과를 알려주는 boolean값을 곧바로 돌려준다. Discovery과정은 보통 12초간의 inquiryinquiry scan후 발견된 각 디바이스에 대해 이름을 가져오기 위한 page scan으로 이루어진다.이루어진다.
어플리케이션은 각 발견된 디바이스에 대한 정보를 받기 위해 ACTION_FOUND 인텐트를인텐트를 위한 BroadcastReceiver를 등록해야만 한다. 각 디바이스마다 시스템이 ACTION_FOUND 인텐트를 브로드캐스트 한다.한다. 이 인텐트는 각각 BluetoothDevice와 BluetoothClass가 들어있는 EXTRA_DEVICE와 EXTRA_CLASS 필드를 전달한다. 예제로예제로 디바이스가 발견되었을 때 브로드캐스트를 처리하는 핸들러를 등록하는 방법이다.

Final BroadcastReceiver mReceiver = new BroadcastReceiver() {
public public void onReceive(Context context, Intent intent) {
String action = intent.getAction();
if (BluetoothDevice.ACTION_FOUND.equals(action))(BluetoothDevice.ACTION_FOUND.equals(action)) {
BluetoothDevice device == intent.getParcelableExtra(BluetoothDevice.EXTRA_DEVICE);
mArrayAdapter.add(device.getName() + “\n”“\n” + device.getAddress());
}
}
};

BroadcastReceiverIntentFilter filter = newnew IntentFilter(BluetoothDevice.ACTION_FOUND;
registerReceiver(mReceiver, filter);

커넥션을 시작하기 위해위해 BluetoothDevice 객체에서 필요한 정보는 MAC 주소뿐이다. 이 예에서는 사용자에게 보여지는 ArrayAdapter의ArrayAdapter의 일부분에 저장되어 있다.

주의: 디바이스 discovery를 수행하는건 블루투스 아답터에게아답터에게 매우 부담이 큰 작업으로 매우 많은 리소스를 요구한다. 커넥션 할 디바이스를디바이스를 찾았다면 커넥션을 시작하려고 시도하기 전에 cancelDiscovery()를 호출해서 discovery를 멈춰야 한다. 또한또한 이미 다른 디바이스와 커넥션 되어 있으면 discovery과정동안 대역폭이 활 떨어질수도떨어질수도 있기 때문에 커넥션 된 상태에서는 discovery를 하지 않아야 한다.
- Discoverable 활성화

다른 디바이스가 자신의 디바이스를 검색할 수 있도록 해 주려면 startActivityForResult(Intent,startActivityForResult(Intent, int)에 ACTION_REQUEST_DISCOVERABLE 액션 인텐트를 넣어 호출해주면 된다. 이 메소드를 호출하면 어플리케이션을어플리케이션을 멈추지 않고 시스템 설정을 통해 discoverable 모드를 활성화 하도록 요청한다. 기본적으로기본적으로 디바이스는 120초동안 discoverable 모드로 있게 된다. EXTRA_DISCOVERABLE_DURATION 인텐트 extra를 추가해서 이이 시간을 바꿔줄 수 있다. (최대 300초)

Intent discoverableIntent = new Intent(BluetoothAdpater.ACTION_REQUEST_DISCOVERABLE);
discoverableIntent.putExtra(BluetoothAdapter.EXTRA_DISCOVERABLE_DURATION, 300);
startActivity(discoverableIntent);

그림 2와 같은 다이얼로그가다이얼로그가 떠서 사용자에게 디바이스를 discoverable 상태로 만들도록 허가할 것인지 묻는다. “Yes”를 선택하면선택하면 디바이스는 정해진 시간동안 discoverable상태가 된다. 액티비티는 result code에 디바이스가 discoverable되는 시간값이시간값이 들어가서 onActivityResult() 콜백을 호출받게 된다. 사용자가 “No”를 선택하거나 에러가 발생하면 resultresult code는 Activity.RESULT_CANCELLED가 된다.
디바이스는 discoverable 시간동안 아무 반응이 없이 조용히 있는다.있는다. 만일 discoverable모드가 변경될 때 통보를 받고 싶으면 ACTION_SCAN_MODE_CHANGED 인텐트에 대한 BroadcastReceiver를BroadcastReceiver를 등록할 수 있다. 이 인텐트에는 각각 이전 스캔모드와 변경된 새 스캔모드가스캔모드가 들어있는 EXTRA_PREVIOUS_SCAN_MODE와 EXTRA_SCAN_MODE라는 extra 필드를 가지고 있다. 각 필드에 들어갈 수수 있는 값은 SCAN_MODE_CONNECTABLE_DISCOVERABLE, SCAN_MODE_CONNECTABLE, SCAN_MODE_NONE으로 각각 discoverable 모드, discoverable은 아니지만 커넥션을커넥션을 받아들일 수는 있는 모드, discoverable도 아니고 커넥션도 받아들일 수 없는 모드를모드를 나타낸다.
원격 디바이스와 커넥션을 시작하고 싶은 경우는 자신의 디바이스를 discoverable모드로 만들만들 필요는 없다. 원격 디바이스가 커넥션을 시작하기 전에 디바이스를 발견해야만 하기 때문에때문에 내 디바이스의 discoverable 모드를 활성화 시키는건 어플리케이션이 서버소켓을 사용해서 incoming 연결을연결을 accept할 때만 필요하다.

- 디바이스 커넥션

두 디바이스에서 실행되는 어플리케이션간에 커넥션을 만들기 위해서는 서버쪽과 클라이언트쪽 메카니즘을메카니즘을 모두 구현해 줘야만 한다. 한 디바이스는 서버소켓을 열어줘야 하고 다른 디바이스가디바이스가 서버 디바이스의 MAC 주소를 사용해서 커넥션을 시작해야만 하기 때문이다. 서버와 클라이언트는클라이언트는 같은 RFCOMM 채널에 각각 커넥션 된 BluetoothSocket을 가지고 있을 때 서로서로 커넥트 된 것으로 간주된다. 이 지점에서 각 디바이스는 입, 출력 스트림을스트림을 얻어 데이터 전송을 시작할 수 있다. 이 섹션에서는 두 디바이스간에 커넥션을커넥션을 시작하는 방법에 대해서 설명한다.
서버 디바이스와 클라이언트 디바이스는 서로 다른 방법으로방법으로 필요한 BluetoothSocket을 얻는다. 서버는 incoming 연결이 accept될 때 소켓을 받게 된다.된다. 클라이언트는 서버로의 RFCOMM 채널을 열 때 소켓을 받게 된다.

한가지 구현 테크닉은 두 디바이스를 모두 서버로 동작하도록 하기하기 위해 서버소켓을 열고 커넥션을 기다리는 것이다. 그러면 어느 디바이스건 클라이언트로서 상대상대 디바이스로 커넥션을 시작할 수 있다. 다른 방법으로는 한 디바이스는 명시적으로 서버로서버로 지정해 서버소켓을 열고 커넥션을 기다리고 다른 디바이스는 단순히 클라이언트로 커넥션을 시작할시작할 수 있다.
주) 두 디바이스가 미리 페어링 되어 있지 않으면 안드로이드안드로이드 프레임웍은 그림 3과 같이 자동으로 페어링을 요구하는 다이얼로그를 띄워준다. 그러므로 디바이스를디바이스를 커넥트 하려고 할 때 어플리케이션은 디바이스가 미리 페어링 되어 있는지 여부를여부를 걱정할 필요가 없다. RFCOMM 커넥션 시도는 사용자가 성공적으로 페어링을 마치거나 페어링을페어링을 거부하거나 또는 어떤 이유로건 페어링이 실패할 때 까지 블럭된다.

서버로 동작
두 디바이스를 커넥트하려고 할 때 하나의 디바이스는 BluetoothServerSocket을BluetoothServerSocket을 열어 서버로 동작해야만 한다. 서버소켓의 목적은 incoming 커넥션 요구를 기다리다 accept되면accept되면 커넥션 된 BluetoothSocket을 제공해 주는 것이다. BluetoothServerSocket에서 BluetoothSocket이 얻어지고 더 이상의이상의 커넥션을 accept할 필요가 없으면 BluetoothServerSocket은 제거해도 된다.

UUID란...UUID란...
Universally Unique IDentifier(UUID)는 유일하게 정보를 식별하는데 사용하기 위한 128비트 포맷의포맷의 표준화 된 문자열 ID이다. UUID의 포인트는 이 숫자가 충분히 크기 때문에때문에 랜덤하게 아무 숫자나 골라도 다른 UUID들과 겹치지 않는다는 것이다. 여기서는 어플리케이션의어플리케이션의 블루투스 서비스를 식별하는데 사용된다. 어플리케이션에 사용할 UUID를 얻기 위해서 인터넷상의 여러가지여러가지 랜덤 UUID 생성기중에 하나를 사용할 수 있고 fromString(String)으로 UUID를 초기화 하면하면 된다.
서버소켓을 셋업하고 연결을 accept하는 기본적인 절차이다.

1.listenUsingRfcommWithServiceRecord(String, UUID)를UUID)를 호출해서 BluetoothServerSocket을 얻어온다.
스트링은 서비스에 대한 식별할 수 있는 이름으로이름으로 시스템이 디바이스의 새 SDP 데이터베이스 엔트리에 자동으로 그 이름을 기록한다. UUIDUUID 또한 SDP엔트리에 포함되어 클라이언트와 커넥션 agreement를 위한 기초가 된다. 즉 클라이언트가클라이언트가 디바이스와 커넥션하려고 시도할 때 커넥션하길 원하는 서비스를 유일하게 식별하는 UUID를 제공한다.제공한다. 커넥션이 이뤄지기 위해서는 이 UUID가 일치해야만 한다.

2.accept()를 호출해서호출해서 커넥션 요구를 listen하기 시작한다.
이 메소드는 블럭킹 호출이다.호출이다. 커넥션이 accept되거나 익셉션이 발생해야만 리턴된다. 리모트 디바이스가 listen하고 있는 서버소켓에 등록한등록한 UUID와 일치하는 커넥션 요구에만 연결이 만들어진다. 성공하면 accept()는 커넥션 된 BluetoothSocket을BluetoothSocket을 리턴한다.


3.더 이상의 추가 커넥션이 필요하지 않으면 close()를close()를 호출한다.
이 메소드를 호출하면 서버소켓과 관련된 리소스를 release한다. 하지만 accept()가accept()가 리턴한 커넥션 된 BluetoothSocket은 닫지 않는다. TCP/IP와 달리 RFCOMM은 클라이언트에서 한번에한번에 하나의 커넥션만 허용하기 때문에 대부분의 경우에 커넥션이 만들어지면 곧바로 BluetoothServerSocket을 close()하는게close()하는게 합리적이다.

accept()는 블럭킹 메소드라 어플리케이션의 다른 동작을 막기 때문에 메인메인 액티비티 UI 스레드에서 호출하면 안된다. 일반적으로 새로운 스레드에서 BluetoothSocket이나 BluetoothServerSocket에 관련된관련된 모든 작업을 처리하는게 합리적이다. 다른 스레드에서 BluetoothServerSocket의 accept() 같이 블럭킹 된된 것을 취소하고 바로 리턴하도록 하려면 close()를 호출하면 된다. 그리고 BluetoothServerSocket 또는또는 BluetoothSocket의 모든 메소드는 스레드-세이프하다.

예제) incoming 연결을 accept하는 서버 컴포넌트를컴포넌트를 위한 간단한 스레드
private class AcceptThread extends Thread {
private final BluetoothServerSocket mmServerSocket;

public AcceptThread() {
// UseUse a temporary object that is later assigned to mmServerSocket,
// because mmServerSocket is final
BluetoothServerSocket tmptmp = null;
try {
// MY_UUID is the app's UUID string, also used byby the client code
tmp = mAdapter.listenUsingRfcommWithServiceRecord(NAME,mAdapter.listenUsingRfcommWithServiceRecord(NAME, MY_UUID);
} catch (IOException e) { }
mmServerSocket = tmp;
}
public void run()run() {
BluetoothSocket socket = null;
// Keep listening until exception occurs or a socket is returnedreturned
while (true) {
try {
socket == mmServerSocket.accept();
} catch (IOException e) {{
break;
}
// If aa connection was accepted
if (socket !=!= null) {
// DoDo work to manage the connection (in a separate thread)
manageConnectedSocket(socket);
mmServerSocket.close();
break; break;
}
}
}
/** Will cancel the listening socket, and cause thethe thread to finish */
public void cancel() {
try {
mmServerSocket.close();
} catch (IOException e) { }
}
}

이 예제에서 한개의 incoming 커넥션만 필요하기 때문에 커넥션이 accept되고 BluetoothSocket이BluetoothSocket이 얻어지자 마자 어플리케이션은 얻은 BluetoothSocket을 별도의 스레드로 보낸 다음 BluetoothServerSocket을 닫고닫고 루프를 빠져나온다.
accept()가 BluetoothSocket을 리턴할 때 소켓은 이미 커넥션 되어되어 있기 때문에 따로 connect()를 호출할 필요는 없다. manageConnectedSocket()은 어플리케이션에서 데이터 전송을전송을 위한 스레드를 시작하는 fictional 메소드이다.
일반적으로 incoming 커넥션을 listen하는게 끝나면끝나면 곧바로 BluetoothServerSocket을 닫아준다. 이 예제에서도 BluetoothSocket이 얻어지자 마자 close()를 호출했다. 또한또한 listen하고 있는 서버소켓을 멈출 필요가 있을 때 private BluetoothSocket을 닫을 수수 있는 public 메소드를 스레드에서 제공하기도 한다.

클라이언트로 동작동작
원격 디바이스와 커넥션을 시작하려면 우선 원격 디바이스를 나타내는 BluetoothDevice 객체를객체를 얻어야만 한다. 그리고 나면 BluetoothDevice를 사용해서 BluetoothSocket을 얻어 커넥션을 시작한다.

기본적인 절차이다.

1.BluetoothDevice를 사용해서 createRfcommSocketToServiceRecord(UUID)를 호출해서 BluetoothSocket을 얻는다.
이 호출은 BluetoothDevice에 연결하는 BluetoothSocket을 초기화한다. 여기서 건네지는 UUID는 서버 디바이스가디바이스가 자신의 BluetoothServerSocket(listenUsingRfcommWithServiceRecord(String, UUID)를 사용해서)을 열었을 때 사용한 UUID와 일치해야만 한다. 동일한동일한 UUID를 사용하는건 UUID스트링을 어플리케이션 코드에 하드코딩하고 서버와 클라이언트 양쪽 코드에서 그걸그걸 참조하면 되는 간단한 문제이다.

2.connect()를 호출해서 연결을 시작한다.
시스템은 UUID를 매치하기 위해 원격 디바이스 SDP lookup을 수행한다. Lookup이 성공하고성공하고 원격 디바이스가 커넥션을 accept하면 연결동안 사용할 RFCOMM채널을 공유하고 connect()가 리턴한다. 이이 메소드는 블럭킹 호출이다. 어떤 이유로건 커넥션이 실패하거나 connect() 메소드가 time outout (약 12초)이 되면 exception을 발생한다.
connect()는 블럭킹 호출이기 때문에 이 커넥션커넥션 절차는 언제나 메인 액티비티 스레드와 독립된 별개의 스레드에서 수행되어야만 한다.
주:주: connect()를 호출할 때 디바이스는 언제나 디바이스 discovery를 수행하고 있지 않는지 확인해야만확인해야만 한다. Discovery가 진행중이면 커넥션 시도는 확연히 느려져서 실패할 가능성이 커진다.

예제) Bluetooth 커넥션을 시작하는 스레드

private class ConnectThread extendsextends Thread {
private final BluetoothSocket mmSocket;
private final BluetoothDeviceBluetoothDevice mmDevice;
public ConnectThread(BluetoothDevice device) {
// UseUse a temporary object that is later assigned to mmSocket,
// because mmSocket is final
BluetoothSocket tmptmp = null;
mmDevice = device;
// Get a BluetoothSocket to connect with the given BluetoothDevice
try {
// MY_UUIDMY_UUID is the app's UUID string, also used by the server codecode
tmp = device.createRfcommSocketToServiceRecord(MY_UUID);
} catch (IOException e) { }
mmSocket == tmp;
}

public void run() {
// Cancel discovery because it will slow down the connectionconnection
mAdapter.cancelDiscovery();
try {
// Connect the device through the socket. ThisThis will block
// until it succeedssucceeds or throws an exception
mmSocket.connect();
} catch (IOException connectException) {
// Unable to connect; close the socket and get outout
try {
mmSocket.close();
} catchcatch (IOException closeException) { }
return;
}
// Do work to managemanage the connection (in a separate thread)
manageConnectedSocket(mmSocket);
}
/** Will cancel an in-progress connection, and close thethe socket */
public void cancel() {
try try {
mmSocket.close();
} } catch (IOException e) { }
}
}

cancelDiscovery()는cancelDiscovery()는 커넥션이 만들어지기 전에 호출되는걸 볼 수 있다. 커넥션이 되기 전에라도 언제나언제나 호출할 수 있고 실제적으로 실행 여부를 확인하지 않고 호출해도 안전하다. (하지만(하지만 그래도 상태를 확인하고 싶으면 isDiscovering()을 사용하면 된다.) manageConnectedSocket()은 데이터 전송을 위한위한 스레드를 시작하는 어플리케이션에 있는 fictional 메소드이다.
BluetoothSocket이 끝나면 clean up을up을 위해 언제나 close()를 호출해줘야 한다. 이 메소드를 호출해 줌으로서 곧바로 커넥션커넥션 된 소켓을 닫고 내부 리소스를 clean up 하게 된다.

- 연결 관리

두 디바이스를 성공적으로 커넥션하게 되면되면 각 디바이스는 커넥션 된 BluetoothSocket을 가지게 된다. 이 소켓을 통해 디바이스간에디바이스간에 데이터를 교환할 수 있게 된다. BluetoothSocket을 사용해서 임의의 데이터를 전송하기 위한위한 일반적 절차는 매우 간단하다.

1.각각 getInputStream()과 getOutputStream()을 사용해사용해 소켓을 통한 전송을 처리할 InputStream과 OutputStream을 얻는다.
2.read(byte[])와 write(byte[])를write(byte[])를 사용해서 데이터를 읽고 쓴다.

물론 implementation을 위해 고려해야 할할 세부사항들이 있다. 먼저 무엇보다 모든 읽고 쓰기를 위한 별도의 스레드를 사용해야사용해야 한다. 이건 read(byte[])와 write(byte[])는 모두 블럭킹 호출이기 때문에 매우 중요하다. read(byte[])는read(byte[])는 스트림에서 무언가 읽을게 있을때까지 블럭되어 있는다. write(byte[])는 일반적으로는 블럭되지 않지만 원격원격 디바이스가 충분히 빠르게 read(byte[])를 호출하지 않아 버퍼가 꽉 차는 경우 플로우플로우 컨트롤을 위해 블럭될수도 있다. 그러므로 스레드의 메인 루프는 InputStream으로부터 읽기 전용으로전용으로 사용되어야 한다. 스레드의 분리된 public 메소드가 OutputStream으로 쓰기를 시작하도록 사용될 수수 있다.

예제)
private class ConnectedThread extends ThreadThread {
private final BluetoothSocket mmSocket;
private final InputStream mmInStream;mmInStream;
private final OutputStream mmOutStream;

public ConnectedThread(BluetoothSocket socket) {{
mmSocket = socket;
InputStream tmpIntmpIn = null;
OutputStream tmpOut = null;
// Get the input and output streams, using temp objectsobjects because
// member streams are final
try {
tmpIn = socket.getInputStream();socket.getInputStream();
tmpOut = socket.getOutputStream();
} catch (IOException e) { }
mmInStream == tmpIn;
mmOutStream = tmpOut;
}

public void run() {
byte[] buffer = newnew byte[1024]; // buffer store for the stream
int bytes; // bytes returned from read()
// // Keep listening to the InputStream until an exception occurs
while (true) {
try {{
// Read from thethe InputStream
bytes = mmInStream.read(buffer);mmInStream.read(buffer);
// Send the obtainedobtained bytes to the UI Activity
mHandler.obtainMessage(MESSAGE_READ, bytes, -1, buffer)
.sendToTarget();
} catch (IOException e) {
break;
}
}
}
/* Call this from the main ActivityActivity to send data to the remote device */
public voidvoid write(byte[] bytes) {
try {
mmOutStream.write(bytes);
} catch (IOException e) {{ }
}

/* Call this from the mainmain Activity to shutdown the connection */
public void cancel() {{
try {
mmSocket.close(); mmSocket.close();
} catch (IOException e) { }
} }
}

컨스트럭터가 필요한 스트림을 얻고 한번 실행되면 스레드는 InputStream을InputStream을 통해 들어오는 데이터를 기다린다. read(byte[])가 스트림에서의 데이터를 리턴하면 그 데이터는 부모부모 클래스의 Handler 멤버를 사용해 메인 액티비티로 보내진다. 그리고 다시 스트림에서 데이터를데이터를 읽기 위해 기다리기 위해 돌아간다. Outgoing 데이터를 보내는건 단순히 메인 액티비티에서액티비티에서 스레드의 write() 메소드를 호출해 전송할 데이터를 전달해주면 된다.

스레드의 cancel()cancel() 메소드는 아무때나 BluetoothSocket을 닫아 connection을 멈출 수 있기 때문에 중요하다. 이이 메소드는 블루투스 connection 사용이 끝나면 언제나 호출되어야 한다.

암시적 인텐트(Implicit Intent)를 처리하려면 인텐트 객체에 들어 있는 여러 정보를 이용해야 한다는 것을 앞에서 알아보았습니다. 인텐트 객체 내의 정보들을 통해 호출해야 할 컴포넌트의 정보를 알았으니, 그 다음엔 이 정보를 바탕으로 각 컴포넌트별로 비교를 해보며 적절한 컴포넌트를 찾아야 합니다.

이렇게 인텐트 객체 내의 여러 정보들을 바탕으로 가장 적절한 컴포넌트를 찾는 과정을 인텐트 해석(Intent Resolving)이라 합니다.  이 과정에서 인텐트 객체의 정보와 각 컴포넌트의 정보를 비교하게 되며, 이을 위해 각 컴포넌트는 자신이 받을 수 있는 인텐트의 종류를 메니페스트 파일에 정의합니다. 이를 인텐트 필터(Intent Filter)라 합니다,
 
안드로이드 시스템 내부에서는 수많은 어플리케이션들에 의해 수많은 인텐트들이 발생합니다. 이 중에서 자신에게 필요햔 인텐트만을 받기 위해 인텐트 필터가 있는 것이죠.



하지만, 인텐트 필터가 없다고 해서 인텐트를 받을 수 없는 것은 아닙니다. 인텐트 필터는 인텐트 해석 과정이 필요한 암시적 인텐트(Implicit Intent)를 받을 때만 필요할 뿐, 호출 대상 컴포넌트가 명시되어있는 명시적 인텐트(Explicit Intent)는 이러한 인텐트 필터가 없어도 대상 컴포넌트를 호출할 수 있습니다.

명시적 인텐트를 사용하면 굳이 인텐트 필터를 정의할 필요도 없고, 간단히 컴포넌트를 호출할 수 있는데 왜 암시적 인텐트가 있는 것일까요? 그 이유는 바로 "명시적" 인텐트의 이름에서도 알 수 있듯이, 명시적 인텐트는 호출 대상 컴포넌트의 이름을 정확히 알아야 하기 때문입니다.

안드로이드가 다른 시스템과 가장 다른 점이 바로 "어플리케이션 간에 경계가 없다"는 것입니다. 이는, 서로 다른 어플리케이션 내의 컴포넌트라 할지라도 사용자가 사용하는 입장에서 볼 때에는 마치 하나의 어플리케이션처럼 동작하는 것이죠. 

 

")//]]>

자, 이제 본격적인 문제는 여기서부터입니다. 자신이 만든 컴포넌트라면 컴포넌트의 이름을 정확하게 알 수 있겠지요. 하지만, 다른 사람이 만든 컴포넌트의 이름을 알기란 어렵습니다. 즉, 명시적 인텐트를 사용하여 해당 컴포넌트를 호출할 수가 없죠. 따라서 암시적 인텐트를 통해 컴포넌트를 호출하게 됩니다.

암시적 인텐트를 사용하는 이유는 이 뿐만이 아닙니다. 안드로이드가 다른 시스템과 다른 것 중 또 하나는 바로 Native 어플리케이션 (Home, Dialer 등...)까지도 사용자가 별도로 제작한 것으로 대체할 수 있다는 것입니다.

Native 어플리케이션을 호출할 때 만약 명시적 인텐트를 사용한다면 사용자가 만든 어플리케이션으로 Native 어플리케이션을 대체하는 것은 불가능하겠지요? 하지만, 암시적 인텐트를 사용하여 호출 대상 컴포넌트가 처리해야 할 작업만을 명시한다면 특정 작업의 처리를 꼭 하나의 어플리케이션만 하는 것이 아니라, 여러 가지의 어플리케이션을 통해 할 수 있게 됩니다. 마치 우리가 그림 파일을 편집할 때 포토샵을 쓰는 사람도 있고, 페인트샵을 쓰는 사람도 있는 것과 마찬가지죠.

인텐트 필터는 인텐트 객체 내의 정보들을 바탕으로 인텐트를 필터링하기에 인텐트 객체 내의 정보들을 바탕으로 자신이 받을 수 있는 정보들을 정의하며. 이 정보들 중 인텐트 필터에서 주로 필터링하는 항목은 action, data (데이터 주소 유형 및 데이터 타입), category입니다.

이러한 인텐트 필터의 내용들을 어플리케이션이 실행되기 전에 안드로이드 시스템에서 알고 있어야 다른 어플리케이션에서 해당 어플리케이션의 컴포넌트를 필요로 하는 인텐트를 발생시켜도 해당 컴포넌트를 실행시킬 수 있습니다. 때문에, 이러한 인텐트 필터의 내용들은 메니페스트 파일인 AndroidManfest.xml 파일의 각 컴포넌트 태그 내에 정의됩니다.


지금부터는 인텐트 필터 내의 각 속성들에 대해 하나씩 알아보도록 하겠습니다.

1. action (액션) 필터

인텐트 객체 내의 action을 검사하여 인텐트 필터에 정의된 액션과 일치하는지 여부를 검사합니다. 이 검사를 통과하려면 인텐트 객체 내의 액션이 인텐트 필터에 정의된 액션과 일치해야 합니다. 단, 인텐트에 액션이 아예 정의되어있지 않은 경우에는 액션 필터를 통과할 수 있습니다.


위에서 보면 인텐트 객체에 정의된 액션의 이름과 인텐트 필터에 정의된 액션의 이름이 조금 다른데, 사실 표현 방식만 다르지 결국은 똑같은 값입니다. Intent 클래스의 API를 보면, Intent 객체 내의 상수로 정의된 ACTION_VIEW 의 실제 값은 android.intent.action.VIEW 인 것을 확인할 수 있습니다.


2. category (카테고리) 필터

인텐트 객체 내의 category 항목을 검사하여 인텐트 필터에 정의된 카테고리와 일치하는지 여부를 검사합니다. 액션 검사에서는 인텐트 객체 내에 아예 액션이 정의되어있지 않은 경우 액션 검사를 통과할 수 있었던 것에 반해 카테고리 검사는 인텐트 객체에 정의된 카테고리가 인텐트 필터에 정의된 카테고리들과 일치해야 합니다.

예를 들면, 인텐트 필터에서 CATEGORY_DEFAULT와 com.androidhuman.TEST_CATEGORY가 정의되어 있을 경우 카테고리로 CATEGORY_DEFAULT를 가지는 인텐트 객체, com.androidhuman.TEST_CATEGORY를 가지는 객체, 혹은 둘 다 가지고 있는 인텐트 객체가 카테고리 검사를 통과할 수 있습니다. 하지만, CATEGORY_DEFAULT는 가지고 있는데 com.androidhuman.NEW_CATEGORY를 가지는 인텐트 객체의 경우 인텐트 필터에서 NEW_CATEGORY가 정의되어있지 않으므로 카테고리 검사를 통과할 수 없습니다.

이 때문에, 암시적 인텐트를 만들 때 카테고리를 추가하지 않을 경우 안드로이드에서 자동으로 CATEGORY_DEFAULT(android.intent.category.DEFAULT)를 추가해주게 됩니다. 때문에 카테고리를 특별히 추가해주지 않은 인텐트를 받을 수 있게 하려면 카테고리 필터에 android.intent.category.DEFAULT 를 추가해줘야 합니다. 그렇지 않으면 어떠한 암시적 인텐트도 받을 수 없게 됩니다.



3. data (데이터) 필터

인텐트 객체 내의 data 항목 및 type을 검사하여 인텐트 필터에 정의된 값과 비교하여 일치 여부를 검사합니다.
데이터 검사는 크게 데이터의 주소(URI)를 검사하는 부분과 데이터의 유형(type, MIME type)을 검사하는 부분으로 나누어집니다.

데이터의 주소를 검사하는 부분은 데이터의 주소를 세분화하여 검사할 수 있도록 되어있습니다. URI(Uniform Resource Identifier)는 다음과 같은 구조로 구성되어있습니다.


만약, http://google.com 을 각 요소별로 나누어본다면 scheme는 http, host는 google.com 이 되겠죠? 이와 마찬가지로 안드로이드 시스템에서 사용하는 주소들도 각각의 요소들로 나눌 수 있습니다.
예를 들어 content://com.androidhuman.provider.SimpleMemo/memos/1 같은 주소의 경우 scheme는 content, host는 com.androidhuman.provider.SimpleMemo, path는 memos/1 이 되겠지요??

데이터의 유형을 필터링하는 것은 type(mimeType)을 이용합니다. 보통 아래와 같이 정의됩니다.

mimeType은 위와 같은 형식으로 정의되며, 큰 범주/큰 범주의 하위 범주 형식으로 정의됩니다. (video/mpeg의 경우 큰 범주가 video, video의 하위 범주가 mpeg) 하위 범주에는 와일드카드 문자(*) 를 사용하여 해당 범주 내의 모든 형식을 허용할 수도 있습니다.

이런 방식으로 첫번째 <data> 필터를 해석하면 "http 스키마를 가진 mpeg 형식의 비디오 데이터"를 가진 인텐트를 허용하는 것임을 알 수 있고, 두번째 필터는 "http 스키마를 가진 모든 오디오 데이터"를 가진 인텐트를 허용하는 것임을 알 수 있습니다.


지금까지 인텐트 객체 및 인텐트 필터의 각 필터들 및 인텐트 필터의 통과 조건들에 대해 알아보았습니다. 다음 강좌에서는 NotePad 예제에 정의되어있는 인텐트 필터들을 보고 해석하면서 오늘 배운 내용들을 다시 한번 정리해보도록 하겠습니다. :)