2015年11月12日木曜日


本記事は以下の記事の続きになります。
[第一回] 生活で使えるBLEデバイス
[第二回] 生活で使えるBLEデバイス~ペアリング編~

はじめに

前回は端末側でのBLE検知と接続までの方法をまとめました。
そして今回はセントラル(端末)とペリフェラル(BLEデバイス)での通信方法に関して触れていきたいと思います。

環境
前回記事と同様に以下の環境で行います。
  • Nexus 5(端末)
  • Nexus 9(BLEデバイス)
データの送受信に関して

独自サービス
今回のデータ送受信では、セントラル(GATT Client)側からペリフェラル(GATT Server)へ接続し、サービス内の必要なキャラクタリスティクスにアクセスして、データ(Value)の読み書きを行います。
なので、今回のデータ送受信に使用するサービスとキャラクタリスティクスを定義しておきます。
例として、以下のように定義しておきます。

・サービス(図1 のService部分)
SERVICE_UUID = "00000001-0000-1000-8000-2f97f3b2dcd5";

・キャラクタリスティクス(図2 のCharacterri部分)
CHAR_READ_UUID = "00000010-0000-1000-8000-2f97f3b2dcd5";
→データ読み込み用
CHAR_WRITE_UUID = "00000011-0000-1000-8000-2f97f3b2dcd5";
→データ書き込み用

図1 GATT Server & GATT Client

アドバタイジングについて
前回からNexus 9をペリフェラルとして機能させていますが、どのようになっていたのでしょうか。
GATT通信の方法と併せて、Android端末でのアドバタイジング方法を簡単に説明していきます。(Bluetooth機能の確認と位置情報の権限取得は前回記事を参照)


図2 アドバタイジング

まずはBluetoothLeAdvertiserの取得を行います。
BluetoothLeAdvertiserは端末のアドバタイジング開始/停止の操作等を行えるクラスです。

BluetoothManager mBluetoothManager = (BluetoothManager) getSystemService(Context.BLUETOOTH_SERVICE);
if (mBluetoothManager != null) {
    BluetoothAdapter mBluetoothAdapter = mBluetoothManager.getAdapter();
}
次にGATT Serverのインスタンスを取得します。(BluetoothManager#openGattServer
取得する際に引数として、BluetoothGattServerCallbackを渡します。
このコールバックにて読み書き等、セントラルから要求が行われた際の動作を実装していくようになります。
ペリフェラル機能を実装していく上で本体となる部分です。
mGattServer = mBluetoothManager.openGattServer(this, new BLEServer());

class BLEServer extends BluetoothGattServerCallback {
    //セントラルから読み込み要求が来ると呼ばれる
    public void onCharacteristicReadRequest(android.bluetooth.BluetoothDevice device, int requestId,
            int offset, BluetoothGattCharacteristic characteristic) {
    }

    //セントラルから書き込み要求が来ると呼ばれる
    public void onCharacteristicWriteRequest(android.bluetooth.BluetoothDevice device, int requestId,
            BluetoothGattCharacteristic characteristic, boolean preparedWrite, boolean responseNeeded,
                int offset, byte[] value) {
    }
}
次は宣言しておいたサービスとキャラクタリスティクスをGATT Serverに設定していきます。
ここでGATT Serverに設定することで、セントラルから独自宣言したサービスを検知することが可能になります。

この時、読み込み用のキャラクタリスティクスには読み込みの、書き込み用のキャラクタリスティクスには書き込みのプロパティと権限を付与しています。
キャラクタリスティクスの権限とプロパティを正しく設定出来ていないと、読み込み/書き込みに失敗してしまうので注意してください。
private void setServices() {
    //serviceUUIDを設定BluetoothGattService service = new BluetoothGattService(
            UUID.fromString(Constants.SERVICE_UUID),
            BluetoothGattService.SERVICE_TYPE_PRIMARY);

    //characteristicUUIDを設定
    BluetoothGattCharacteristic charRead = new BluetoothGattCharacteristic(
            UUID.fromString(Constants.CHAR_READ_UUID),
            BluetoothGattCharacteristic.PROPERTY_READ,
            BluetoothGattCharacteristic.PERMISSION_READ);

    BluetoothGattCharacteristic charWrite = new BluetoothGattCharacteristic(
            UUID.fromString(Constants.CHAR_WRITE_UUID),
            BluetoothGattCharacteristic.PROPERTY_WRITE,
            BluetoothGattCharacteristic.PERMISSION_WRITE);

    //characteristicUUIDをserviceUUIDにのせる
    service.addCharacteristic(charRead);
    service.addCharacteristic(charWrite);

    //serviceUUIDをサーバーにのせる
    mGattServer.addService(service);
}
次にアドバタイジング時の設定(AdvertiseSettings)とデータ(AdvertiseData)の設定を行います。
そして、アドバタイジングの設定の準備が出来たらBluetoothLeAdvertiser#startAdvertisingで、アドバタイジングを開始します。
//AdvertiseSettingsの設定
private AdvertiseSettings buildAdvertiseSettings() {
    AdvertiseSettings.Builder settingsBuilder = new AdvertiseSettings.Builder();
    settingsBuilder.setAdvertiseMode(AdvertiseSettings.ADVERTISE_MODE_LOW_POWER);
    settingsBuilder.setTimeout(0);
    return settingsBuilder.build();
}

//AdvertiseDataの設定
private AdvertiseData buildAdvertiseData() {
    AdvertiseData.Builder dataBuilder = new AdvertiseData.Builder();
    dataBuilder.addServiceUuid(ParcelUuid.fromString(Constants.SERVICE_UUID));
    dataBuilder.setIncludeDeviceName(true);
    return dataBuilder.build();
}

//Advertiseの開始
private void startAdvertising() {
    setServices();
    AdvertiseSettings settings = buildAdvertiseSettings();
    AdvertiseData data = buildAdvertiseData();
    mAdvertiseCallback = new SimpleAdvertiseCallback();
    mBluetoothLeAdvertiser.startAdvertising(settings, data,mAdvertiseCallback);
}

//Advertiseの成功可否
private class SimpleAdvertiseCallback extends AdvertiseCallback {
    @Override
    public void onStartFailure(int errorCode) {
        super.onStartFailure(errorCode);
        Log.d(TAG, "Advertising failed");
    }

    @Override
    public void onStartSuccess(AdvertiseSettings settingsInEffect) {
        super.onStartSuccess(settingsInEffect);
        Log.d(TAG, "Advertising successfully started");
    }
}
アドバタイジングを終了する時はBluetoothLeAdvertiser#stopAdvertisingを呼びます。
この時、GATT Serverのcloseも忘れずに。
private void stopAdvertising() {
    Log.d(TAG, "Service: Stopping Advertising");
    if (mGattServer != null) {
        mGattServer.clearServices();
        mGattServer.close();
        mGattServer = null;
    }
    if (mBluetoothLeAdvertiser != null) {
        mBluetoothLeAdvertiser.stopAdvertising(mAdvertiseCallback);
        mAdvertiseCallback = null;
    }
}
以上で、Nexus 9がペリフェラルとして機能するようになります。
アドバタイジングが開始された後、セントラル(Nexus 5)側から検知出来るようになっていることでしょう。

そして、定義したサービスとGATT Serverによって、データの読み書きを行う準備も出来ました。
では、実際にデータの読み書きを行ってみましょう。

データの読み込み
セントラル側からペリフェラルのキャラクタリスティクスデータを読み込む手順です。

図3 データの読み込み
<セントラル(Nexus 5)側>
接続済みのBluetoothGattから読み込み用キャラクタリスティクスを取得して、読み込み要求(BluetoothGattl#readCharacteristic)を行います。
public void readCharacteristic() {
    BluetoothGattCharacteristic read = mBluetoothLeService.getCharacteristic(
            GattAttributes.SERVICE_UUID,
            GattAttributes.CHAR_READ_UUID);
    mBluetoothGatt.readCharacteristic(read);
}

public BluetoothGattCharacteristic getCharacteristic(String sid, String cid) {
    BluetoothGattService s = mBluetoothGatt.getService(UUID.fromString(sid));
    if (s == null) {
        Log.w(TAG, "Service NoT found :" + sid);
        return null;
    }
    BluetoothGattCharacteristic c = s.getCharacteristic(UUID.fromString(cid));
    if (c == null) {
        Log.w(TAG, "Characteristic NOT found :" + cid);
        return null;
    }
    return c;
}
読み込み要求を行い、成功するとBluetoothGattCallback#onCharacteristicReadが呼び出されます。
その引数に渡されるBluetoothGattCharacteristicにペリフェラルからのレスポンスを受け取ることが出来ます。
@Override
public void onCharacteristicRead(BluetoothGatt gatt,
        BluetoothGattCharacteristic characteristic, int status) {
    final byte[] data = characteristic.getValue();
    Log.d(TAG, "onCharacteristicRead : " +  new String(data));
}

<ペリフェラル(Nexus 9)側>
セントラル側から読み込み要求が行われると、BluetoothGattServerCallback#onCharacteristicReadRequestに通知が来ます。
セントラルに対して送りたいデータをGattServer#sendResponseにセットすることで、セントラルに任意のデータを送信することが出来ます。
//セントラルからReadRequestが来ると呼ばれる
public void onCharacteristicReadRequest(android.bluetooth.BluetoothDevice device, int requestId,
        int offset, BluetoothGattCharacteristic characteristic) {
    //セントラルに任意の文字を返信する
    if (UUID.fromString(Constants. CHAR_READ_UUID).equals(characteristic.getUuid())) {
        String response  = "your message.";
        byte value[] = response.getBytes();
        mGattServer.sendResponse(device, requestId, BluetoothGatt.GATT_SUCCESS, offset, value);
    }
}

データの書き込み
セントラルからペリフェラルへキャラクタリスティクスデータを書き込む手順です。

図4 データの書き込み
<セントラル(Nexus 5)側>
接続が完了したBluetoothGattから書き込み用キャラクタリスティクスを取得し、書き込みたいデータをセットすることでペリフェラル側へデータを送ることが出来ます。
※書き込み権限のないキャラクタリスティクスに書き込み要求(BluetoothGatt#writeCharacteristic)を行うと戻り値に false が返り、書き込みに失敗します。
public void writeCharacteristic() {
    BluetoothGattCharacteristic write = getCharacteristic(
            UUID.fromString(GattAttributes.SERVICE_UUID),
            UUID.fromString(GattAttributes.CHAR_WRITE_UUID));
    String message = "your message";
    write.setValue(message);
    mBluetoothGatt.writeCharacteristic(characteristic);
}

public BluetoothGattCharacteristic getCharacteristic(String sid, String cid) {
    BluetoothGattService s = mBluetoothGatt.getService(UUID.fromString(sid));
    if (s == null) {
        Log.w(TAG, "Service NoT found :" + sid);
        return null;
    }
    BluetoothGattCharacteristic c = s.getCharacteristic(UUID.fromString(cid));
    if (c == null) {
        Log.w(TAG, "Characteristic NOT found :" + cid);
        return null;
    }
    return c;
}
<ペリフェラル(Nexus 9)側>
セントラル側から書き込み要求がされると、BluetoothGattServerCallback#onCharacteristicWriteRequestに通知が来ます。 セントラルから書きこまれた内容はcharacteristicから取得することが出来ます。
 また、処理が終わる時には必ずGattServer#sendResponseを呼んでください。

//セントラルから書き込み要求が来ると呼ばれる
public void onCharacteristicWriteRequest(android.bluetooth.BluetoothDevice device, int requestId,
        BluetoothGattCharacteristic characteristic, boolean preparedWrite, boolean responseNeeded,
        int offset, byte[] value) {
    Log.d(TAG, "onCharacteristicWriteRequest");
    if (UUID.fromString(Constants.CHAR_WRITE_UUID).equals(characteristic.getUuid())) {            
        final byte[] data = characteristic.getValue();
        Log.d(TAG, "onCharacteristicRead : " +  new String(data));
        mGattServer.sendResponse(device, requestId, BluetoothGatt.GATT_SUCCESS, offset, null);          
    }
}

さいごに

以上がAndroid間でのBLE通信(読み書き)の手順です。

今回までで、BLE接続、通信を行えるようになりました。
なので次回からはタイトル通り、生活の中でBLEデバイスを使ったアイデアを考えてみたいと思います。

[第三回] 生活で使えるBLE~アプリ間通信編~


本記事は以下の記事の続きになります。
[第一回] 生活で使えるBLEデバイス
[第二回] 生活で使えるBLEデバイス~ペアリング編~

はじめに

前回は端末側でのBLE検知と接続までの方法をまとめました。
そして今回はセントラル(端末)とペリフェラル(BLEデバイス)での通信方法に関して触れていきたいと思います。

環境
前回記事と同様に以下の環境で行います。
  • Nexus 5(端末)
  • Nexus 9(BLEデバイス)
データの送受信に関して

独自サービス
今回のデータ送受信では、セントラル(GATT Client)側からペリフェラル(GATT Server)へ接続し、サービス内の必要なキャラクタリスティクスにアクセスして、データ(Value)の読み書きを行います。
なので、今回のデータ送受信に使用するサービスとキャラクタリスティクスを定義しておきます。
例として、以下のように定義しておきます。

・サービス(図1 のService部分)
SERVICE_UUID = "00000001-0000-1000-8000-2f97f3b2dcd5";

・キャラクタリスティクス(図2 のCharacterri部分)
CHAR_READ_UUID = "00000010-0000-1000-8000-2f97f3b2dcd5";
→データ読み込み用
CHAR_WRITE_UUID = "00000011-0000-1000-8000-2f97f3b2dcd5";
→データ書き込み用

図1 GATT Server & GATT Client

アドバタイジングについて
前回からNexus 9をペリフェラルとして機能させていますが、どのようになっていたのでしょうか。
GATT通信の方法と併せて、Android端末でのアドバタイジング方法を簡単に説明していきます。(Bluetooth機能の確認と位置情報の権限取得は前回記事を参照)


図2 アドバタイジング

まずはBluetoothLeAdvertiserの取得を行います。
BluetoothLeAdvertiserは端末のアドバタイジング開始/停止の操作等を行えるクラスです。

BluetoothManager mBluetoothManager = (BluetoothManager) getSystemService(Context.BLUETOOTH_SERVICE);
if (mBluetoothManager != null) {
    BluetoothAdapter mBluetoothAdapter = mBluetoothManager.getAdapter();
}
次にGATT Serverのインスタンスを取得します。(BluetoothManager#openGattServer
取得する際に引数として、BluetoothGattServerCallbackを渡します。
このコールバックにて読み書き等、セントラルから要求が行われた際の動作を実装していくようになります。
ペリフェラル機能を実装していく上で本体となる部分です。
mGattServer = mBluetoothManager.openGattServer(this, new BLEServer());

class BLEServer extends BluetoothGattServerCallback {
    //セントラルから読み込み要求が来ると呼ばれる
    public void onCharacteristicReadRequest(android.bluetooth.BluetoothDevice device, int requestId,
            int offset, BluetoothGattCharacteristic characteristic) {
    }

    //セントラルから書き込み要求が来ると呼ばれる
    public void onCharacteristicWriteRequest(android.bluetooth.BluetoothDevice device, int requestId,
            BluetoothGattCharacteristic characteristic, boolean preparedWrite, boolean responseNeeded,
                int offset, byte[] value) {
    }
}
次は宣言しておいたサービスとキャラクタリスティクスをGATT Serverに設定していきます。
ここでGATT Serverに設定することで、セントラルから独自宣言したサービスを検知することが可能になります。

この時、読み込み用のキャラクタリスティクスには読み込みの、書き込み用のキャラクタリスティクスには書き込みのプロパティと権限を付与しています。
キャラクタリスティクスの権限とプロパティを正しく設定出来ていないと、読み込み/書き込みに失敗してしまうので注意してください。
private void setServices() {
    //serviceUUIDを設定BluetoothGattService service = new BluetoothGattService(
            UUID.fromString(Constants.SERVICE_UUID),
            BluetoothGattService.SERVICE_TYPE_PRIMARY);

    //characteristicUUIDを設定
    BluetoothGattCharacteristic charRead = new BluetoothGattCharacteristic(
            UUID.fromString(Constants.CHAR_READ_UUID),
            BluetoothGattCharacteristic.PROPERTY_READ,
            BluetoothGattCharacteristic.PERMISSION_READ);

    BluetoothGattCharacteristic charWrite = new BluetoothGattCharacteristic(
            UUID.fromString(Constants.CHAR_WRITE_UUID),
            BluetoothGattCharacteristic.PROPERTY_WRITE,
            BluetoothGattCharacteristic.PERMISSION_WRITE);

    //characteristicUUIDをserviceUUIDにのせる
    service.addCharacteristic(charRead);
    service.addCharacteristic(charWrite);

    //serviceUUIDをサーバーにのせる
    mGattServer.addService(service);
}
次にアドバタイジング時の設定(AdvertiseSettings)とデータ(AdvertiseData)の設定を行います。
そして、アドバタイジングの設定の準備が出来たらBluetoothLeAdvertiser#startAdvertisingで、アドバタイジングを開始します。
//AdvertiseSettingsの設定
private AdvertiseSettings buildAdvertiseSettings() {
    AdvertiseSettings.Builder settingsBuilder = new AdvertiseSettings.Builder();
    settingsBuilder.setAdvertiseMode(AdvertiseSettings.ADVERTISE_MODE_LOW_POWER);
    settingsBuilder.setTimeout(0);
    return settingsBuilder.build();
}

//AdvertiseDataの設定
private AdvertiseData buildAdvertiseData() {
    AdvertiseData.Builder dataBuilder = new AdvertiseData.Builder();
    dataBuilder.addServiceUuid(ParcelUuid.fromString(Constants.SERVICE_UUID));
    dataBuilder.setIncludeDeviceName(true);
    return dataBuilder.build();
}

//Advertiseの開始
private void startAdvertising() {
    setServices();
    AdvertiseSettings settings = buildAdvertiseSettings();
    AdvertiseData data = buildAdvertiseData();
    mAdvertiseCallback = new SimpleAdvertiseCallback();
    mBluetoothLeAdvertiser.startAdvertising(settings, data,mAdvertiseCallback);
}

//Advertiseの成功可否
private class SimpleAdvertiseCallback extends AdvertiseCallback {
    @Override
    public void onStartFailure(int errorCode) {
        super.onStartFailure(errorCode);
        Log.d(TAG, "Advertising failed");
    }

    @Override
    public void onStartSuccess(AdvertiseSettings settingsInEffect) {
        super.onStartSuccess(settingsInEffect);
        Log.d(TAG, "Advertising successfully started");
    }
}
アドバタイジングを終了する時はBluetoothLeAdvertiser#stopAdvertisingを呼びます。
この時、GATT Serverのcloseも忘れずに。
private void stopAdvertising() {
    Log.d(TAG, "Service: Stopping Advertising");
    if (mGattServer != null) {
        mGattServer.clearServices();
        mGattServer.close();
        mGattServer = null;
    }
    if (mBluetoothLeAdvertiser != null) {
        mBluetoothLeAdvertiser.stopAdvertising(mAdvertiseCallback);
        mAdvertiseCallback = null;
    }
}
以上で、Nexus 9がペリフェラルとして機能するようになります。
アドバタイジングが開始された後、セントラル(Nexus 5)側から検知出来るようになっていることでしょう。

そして、定義したサービスとGATT Serverによって、データの読み書きを行う準備も出来ました。
では、実際にデータの読み書きを行ってみましょう。

データの読み込み
セントラル側からペリフェラルのキャラクタリスティクスデータを読み込む手順です。

図3 データの読み込み
<セントラル(Nexus 5)側>
接続済みのBluetoothGattから読み込み用キャラクタリスティクスを取得して、読み込み要求(BluetoothGattl#readCharacteristic)を行います。
public void readCharacteristic() {
    BluetoothGattCharacteristic read = mBluetoothLeService.getCharacteristic(
            GattAttributes.SERVICE_UUID,
            GattAttributes.CHAR_READ_UUID);
    mBluetoothGatt.readCharacteristic(read);
}

public BluetoothGattCharacteristic getCharacteristic(String sid, String cid) {
    BluetoothGattService s = mBluetoothGatt.getService(UUID.fromString(sid));
    if (s == null) {
        Log.w(TAG, "Service NoT found :" + sid);
        return null;
    }
    BluetoothGattCharacteristic c = s.getCharacteristic(UUID.fromString(cid));
    if (c == null) {
        Log.w(TAG, "Characteristic NOT found :" + cid);
        return null;
    }
    return c;
}
読み込み要求を行い、成功するとBluetoothGattCallback#onCharacteristicReadが呼び出されます。
その引数に渡されるBluetoothGattCharacteristicにペリフェラルからのレスポンスを受け取ることが出来ます。
@Override
public void onCharacteristicRead(BluetoothGatt gatt,
        BluetoothGattCharacteristic characteristic, int status) {
    final byte[] data = characteristic.getValue();
    Log.d(TAG, "onCharacteristicRead : " +  new String(data));
}

<ペリフェラル(Nexus 9)側>
セントラル側から読み込み要求が行われると、BluetoothGattServerCallback#onCharacteristicReadRequestに通知が来ます。
セントラルに対して送りたいデータをGattServer#sendResponseにセットすることで、セントラルに任意のデータを送信することが出来ます。
//セントラルからReadRequestが来ると呼ばれる
public void onCharacteristicReadRequest(android.bluetooth.BluetoothDevice device, int requestId,
        int offset, BluetoothGattCharacteristic characteristic) {
    //セントラルに任意の文字を返信する
    if (UUID.fromString(Constants. CHAR_READ_UUID).equals(characteristic.getUuid())) {
        String response  = "your message.";
        byte value[] = response.getBytes();
        mGattServer.sendResponse(device, requestId, BluetoothGatt.GATT_SUCCESS, offset, value);
    }
}

データの書き込み
セントラルからペリフェラルへキャラクタリスティクスデータを書き込む手順です。

図4 データの書き込み
<セントラル(Nexus 5)側>
接続が完了したBluetoothGattから書き込み用キャラクタリスティクスを取得し、書き込みたいデータをセットすることでペリフェラル側へデータを送ることが出来ます。
※書き込み権限のないキャラクタリスティクスに書き込み要求(BluetoothGatt#writeCharacteristic)を行うと戻り値に false が返り、書き込みに失敗します。
public void writeCharacteristic() {
    BluetoothGattCharacteristic write = getCharacteristic(
            UUID.fromString(GattAttributes.SERVICE_UUID),
            UUID.fromString(GattAttributes.CHAR_WRITE_UUID));
    String message = "your message";
    write.setValue(message);
    mBluetoothGatt.writeCharacteristic(characteristic);
}

public BluetoothGattCharacteristic getCharacteristic(String sid, String cid) {
    BluetoothGattService s = mBluetoothGatt.getService(UUID.fromString(sid));
    if (s == null) {
        Log.w(TAG, "Service NoT found :" + sid);
        return null;
    }
    BluetoothGattCharacteristic c = s.getCharacteristic(UUID.fromString(cid));
    if (c == null) {
        Log.w(TAG, "Characteristic NOT found :" + cid);
        return null;
    }
    return c;
}
<ペリフェラル(Nexus 9)側>
セントラル側から書き込み要求がされると、BluetoothGattServerCallback#onCharacteristicWriteRequestに通知が来ます。 セントラルから書きこまれた内容はcharacteristicから取得することが出来ます。
 また、処理が終わる時には必ずGattServer#sendResponseを呼んでください。

//セントラルから書き込み要求が来ると呼ばれる
public void onCharacteristicWriteRequest(android.bluetooth.BluetoothDevice device, int requestId,
        BluetoothGattCharacteristic characteristic, boolean preparedWrite, boolean responseNeeded,
        int offset, byte[] value) {
    Log.d(TAG, "onCharacteristicWriteRequest");
    if (UUID.fromString(Constants.CHAR_WRITE_UUID).equals(characteristic.getUuid())) {            
        final byte[] data = characteristic.getValue();
        Log.d(TAG, "onCharacteristicRead : " +  new String(data));
        mGattServer.sendResponse(device, requestId, BluetoothGatt.GATT_SUCCESS, offset, null);          
    }
}

さいごに

以上がAndroid間でのBLE通信(読み書き)の手順です。

今回までで、BLE接続、通信を行えるようになりました。
なので次回からはタイトル通り、生活の中でBLEデバイスを使ったアイデアを考えてみたいと思います。

2015年11月4日水曜日


http://developer.android.com/intl/ja/about/versions/jelly-bean.html から引用

この記事は以下の記事の続きになります。
[第一回] 生活で使えるBLEデバイス

はじめに

前回の記事では、BluetoothとBLEおさらいをしました。
では今回はAndroid端末からのBLEデバイス検知とペアリングを行う方法を紹介します。

環境

今回はNexus 5から周辺のBLE端末(Nexus9)を検知して、接続を試みます。

  • Nexus 5(OS 6.0)
  • Nexus 9(OS 6.0)
Nexus 5(検知する側)
以下のサンプルアプリを元に、BLEデバイスの検知と接続方法を説明します。
BluetoothLeGatt

図1 BluetoothLeGatt

ただし、実装方法が一部古いままの為、以下の修正を加えています。(詳細は後述)
  1. RuntimePermission対応(「Bluetooth機能を利用する」の項目を参照)
  2. BLEスキャン時のAPIの修正(「BLEデバイスの検知」の項目を参照)
Nexus 9(BLE端末)
以下のサンプルアプリをインストールしておき、BLE端末としての役割をもたせています。
BluetoothAdvertisements


図2 BluetoothAdvertisements


では、実際にBLEデバイスの検知と接続を行う実装方法を紹介していきます。

BLEデバイスの検知と接続

Bluetooth機能を利用する
まずはじめに、Bluettoth機能を利用する宣言を行います。
AndroidManifest.xmlに宣言するパーミッションは以下の通りです。
<uses-permission android:name="android.permission.BLUETOOTH"></uses-permission>
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN"></uses-permission>
また、BLEの機能を利用する場合は以下の宣言も必要です。
<uses-feature android:name="android.hardware.bluetooth_le" android:required="true"/>
※端末がBLEに対応しているかの確認
if (!getPackageManager().hasSystemFeature(PackageManager.FEATURE_BLUETOOTH_LE)) {
    Toast.makeText(this, "BLE未対応端末です", Toast.LENGTH_SHORT).show();
    finish();
}

さらに、Android 6.0からBLEの利用には位置情報の権限が必要になりました。

よって、マニフェストにも「ACCESS_COARSE_LOCATION」または「ACCESS_FINE_LOCATION」の宣言が必要になります。
 <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
または
 <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/>
しかし、それだけではBLE機能を使用することは出来ません。。

位置情報の権限はプロテクションレベルが「Dangerous」になるので、ユーザーが権限を許可しない限りBLEの機能は使用することが出来ません。
※RuntimePermissionの詳細はこちら

よって、BLE機能を利用する前には、位置情報の権限の利用が許可されているかの確認を行い、ユーザーが許可をしていなければ許可を行うように促します。

許可されているかのチェックと権限取得の要求
private boolean checkPermission() {
    if (checkSelfPermission(Manifest.permission.ACCESS_FINE_LOCATION) != PackageManager.PERMISSION_GRANTED) { requestPermissions(new String[]{Manifest.permission.ACCESS_FINE_LOCATION}, PERMISSIONS_REQUEST_LOCATION_STATE);
        return false;
    }
    return true;
}

許可/不許可の結果は onRequestPermissionsResult で判別出来ます。
@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {
    if (PERMISSIONS_REQUEST_LOCATION_STATE == requestCode) {
        if (grantResults[0] == PackageManager.PERMISSION_GRANTED) {
            // 許可された場合
            Toast.makeText(this, "許可されました", Toast.LENGTH_SHORT).show();
        } else {
            // 不許可だった場合
            Toast.makeText(this, "権限を拒否されました", Toast.LENGTH_SHORT).show();
            finish();
        }
    }
}
事前準備としては以上です。
次はBluetooth関連クラスを使用していきます。

BluetoothAdapterの取得
まずはBluetoothAdapterを取得します。
(BluetoothAdapterは、すべてのBluetooth相互作用のためのエントリー・ポイントです。)
final BluetoothManager bluetoothManager = (BluetoothManager)getSystemService(Context.BLUETOOTH_SERVICE);
mBluetoothAdapter = bluetoothManager.getAdapter();
次に、端末のBluetoothが有効になっているかの確認を行います。
もし、Bluetoothが無効であればユーザーに有効にするように促します。
if (mBluetoothAdapter == null || !mBluetoothAdapter.isEnabled()) {
    Intent enableBtIntent = new Intent(BluetoothAdapter.ACTION_REQUEST_ENABLE);
    startActivityForResult(enableBtIntent, REQUEST_ENABLE_BT);
}

BLEデバイスの検知
次にBLEデバイスの検知方法を紹介します。
サンプルアプリでは、BLEを検知する為にBluetoothAdapter#startLeScanを使用していますが、APIレベル21から非推奨となり、現在はBluetoothLeScannerを利用するようになりました。
使用方法は以下の通りです。

先ほど取得したBluetoothAdapterからBluetoothLeScannerを取得します。
mBluetoothLeScanner = mBluetoothAdapter.getBluetoothLeScanner();
BluetoothLeScannerを取得したら、以下のAPIを利用してスキャンの開始/停止を制御します。
そして、BLE機器が検知された場合、ScanCallback#onScanResultが呼び出され、ScanResultからBluetoothDeviceが取得出来ます。

BLEデバイスのスキャン開始

BLEデバイスのスキャン停止
BLEスキャンのCallback
// Device scan callback.
private ScanCallback mScanCallback = new ScanCallback() {
    @Override
    public void onScanResult(int callbackType, final ScanResult result) {
        super.onScanResult(callbackType, result);
        if (result != null && result.getDevice() != null) {
            runOnUiThread(new Runnable() {
               @Override
               public void run() {
                   mLeDeviceListAdapter.addDevice(result.getDevice());
                   mLeDeviceListAdapter.notifyDataSetChanged();
               }
            });
        }
    }
};
これで周辺のBLE機器の検知がすることが出来ました。
では次に、検知したデバイスに接続を行います。

ペアリング(GATTサーバーに接続)方法
ペアリングと銘打ってますが、BLEデバイスと通信を行う際にはペアリングをする必要はありません。(対応していればペアリングを行うことも可能です)
BLEデバイスの情報を取得するには、GATTサーバーに接続を行うことで、BLEデバイスの情報を読みとることが可能です。

GATTサーバーに接続するには先ほど検知したBluetoothDeviceのBluetoothDevice#connectGattメソッドを使用します。
mBluetoothGatt = device.connectGatt(this, false, mGattCallback);
接続が確立されると、BluetoothGattCallback#onConnectionStateChangeが呼ばれます。
newState が BluetoothProfile.STATE_CONNECTEDであれば接続が完了している状態です。

接続が確認出来たら、BluetoothGatt#discoverServicesにより、Gattサーバーの情報を検索します。
結果は BluetoothGattCallback#onServicesDiscovered が呼び出されます。

@Override
public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState) {
    String intentAction;
    if (newState == BluetoothProfile.STATE_CONNECTED) {
        mBluetoothGatt.discoverServices();
    }
}

@Override
public void onServicesDiscovered(BluetoothGatt gatt, int status) {
    super.onServicesDiscovered(gatt, status);
    serviceList = gatt.getServices();
    // サービスの内容を取得等処理を行う
    // 取得したサービスからBLEデバイスの情報を取得する
}
以上が、BLEデバイス検知から接続までの方法になります。

では最後に、BLEデバイスの情報を取りまとめるGATTについての説明をします。

Generic Attribute Profile (GATT)について
GATTとは、前回の記事で言うところのBluetooth 4.0で使用出来るプロファイルです。

GATTプロファイルは、"attribute"として知られる、BLE link上での短いデータの送受信の一般的な仕様で、現在のBLEアプリケーションプロファイルは、全て、GATTをベースにしています。

※Bluetooth SIGは、BLE端末のための多くのプロファイルを定義します。
※プロファイルは、特定のアプリケーションにおける端末の動作仕様です。
※端末は1つ以上のプロファイルを実装可能です。


図3 Generic Attribute Profile (GATT)について
https://developer.bluetooth.org/TechnologyOverview/Pages/GATT.aspx より引用

・Attribute Protocol (ATT)
GATTは、Attribute Protocol (ATT)の上位に組み込まれています。
GATT/ATTとしても参照されます。
ATTは、BLEデバイス上で動作するよう最適化されています(数バイト使用します)
各attributeは、Universally Unique Identifier (UUID)によりユニークに識別され、ユニークに情報を識別するために使われるstring IDのため標準化された128-bitフォーマットとなります。
ATTにより転送されたattributeは、characteristicおよびserviceとしてフォーマットされています。

・Characteristic
characteristicは1つの値と0-nのcharacteristicに言及するdescriptorを含みます。
characteristicはtypeとみなされ、classに似たものとなります。

・Descriptor
Descriptorは、characteristic値を記述する定義されたattributeです。
例えば, characteristicの値が許容可能な範囲を人間が読めるdescriptionとして定義されるものであったり, characteristicの値の単位を表すものであったりします。

・Service
serviceは、characteristicを集めたものです。
例えば, "Heart rate Monitor"と呼ばれるサービスには"heart rate measurement"という名のcharacteristicが含まれます。
既存のGATTベースのprofile/serviceリストをbluetooth.orgで入手可能です。

※これらのサービスやキャラクタリスティックは、Bluetooth SIG が標準として定義していますが、デバイス開発者が独自に定義することも可能です。

GATTプロファイルのサービスとその中にあるCharacteristicを読み取ることで、BLEデバイスの情報を読み出すことが出来ます。

また、GATT通信はサーバークライアントモデルであるため、基本的にはサーバーが機能や情報を保持し、クライアントがそれを利用することになります。

GATTクライアント
 データを利用する機器

GATTサーバー
 データを保持する機器

GATTクライアントとGATTサーバーは接続確立後、2つの端末がどのように通信し合うかのか決定します。
※今回であれば、Nexus 5(client、つまり端末)とNexus 9(server、つまりBLEデバイス)があると考えて下さい。

接続が確立すると、GATTメタデータの他への転送を開始します。
転送するデータの種類により、どちらかがサーバーとして動作します。

例えば、
BLEデバイスがセンサーデータを端末へレポートしたい場合、BLEデバイスがサーバーとして動作するのが理にかなっていると考えられます。
BLEデバイス端末からアップデートを受信したい場合は、端末がサーバーとして動作するのが理にかなっていると考えられます。

本記事で使用したアプリにおいては、Nexus 5はGATTクライアントとして動作しています。
Nexus 5側のアプリ(GATTクライアント)は、Nexus 9(GATTサーバー)からデータを読み取り、アプリ内で解釈することで連携を行っている。という構成になっています。

さいごに

今回はBLEデバイスの検知から接続までをまとめました。

サンプルアプリでBLEの検知と接続を試すことは出来ますが、非推奨になっている点とBLE機能を使用する為の権限が増えている点に御留意いただければと思います。

次回はBLEデバイスからの情報の読み書きを行い、実際にBLE端末とデータのやり取りをしてみたいと思います。

[第二回] 生活で使えるBLE~ペアリング編~


http://developer.android.com/intl/ja/about/versions/jelly-bean.html から引用

この記事は以下の記事の続きになります。
[第一回] 生活で使えるBLEデバイス

はじめに

前回の記事では、BluetoothとBLEおさらいをしました。
では今回はAndroid端末からのBLEデバイス検知とペアリングを行う方法を紹介します。

環境

今回はNexus 5から周辺のBLE端末(Nexus9)を検知して、接続を試みます。

  • Nexus 5(OS 6.0)
  • Nexus 9(OS 6.0)
Nexus 5(検知する側)
以下のサンプルアプリを元に、BLEデバイスの検知と接続方法を説明します。
BluetoothLeGatt

図1 BluetoothLeGatt

ただし、実装方法が一部古いままの為、以下の修正を加えています。(詳細は後述)
  1. RuntimePermission対応(「Bluetooth機能を利用する」の項目を参照)
  2. BLEスキャン時のAPIの修正(「BLEデバイスの検知」の項目を参照)
Nexus 9(BLE端末)
以下のサンプルアプリをインストールしておき、BLE端末としての役割をもたせています。
BluetoothAdvertisements


図2 BluetoothAdvertisements


では、実際にBLEデバイスの検知と接続を行う実装方法を紹介していきます。

BLEデバイスの検知と接続

Bluetooth機能を利用する
まずはじめに、Bluettoth機能を利用する宣言を行います。
AndroidManifest.xmlに宣言するパーミッションは以下の通りです。
<uses-permission android:name="android.permission.BLUETOOTH"></uses-permission>
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN"></uses-permission>
また、BLEの機能を利用する場合は以下の宣言も必要です。
<uses-feature android:name="android.hardware.bluetooth_le" android:required="true"/>
※端末がBLEに対応しているかの確認
if (!getPackageManager().hasSystemFeature(PackageManager.FEATURE_BLUETOOTH_LE)) {
    Toast.makeText(this, "BLE未対応端末です", Toast.LENGTH_SHORT).show();
    finish();
}

さらに、Android 6.0からBLEの利用には位置情報の権限が必要になりました。

よって、マニフェストにも「ACCESS_COARSE_LOCATION」または「ACCESS_FINE_LOCATION」の宣言が必要になります。
 <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
または
 <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/>
しかし、それだけではBLE機能を使用することは出来ません。。

位置情報の権限はプロテクションレベルが「Dangerous」になるので、ユーザーが権限を許可しない限りBLEの機能は使用することが出来ません。
※RuntimePermissionの詳細はこちら

よって、BLE機能を利用する前には、位置情報の権限の利用が許可されているかの確認を行い、ユーザーが許可をしていなければ許可を行うように促します。

許可されているかのチェックと権限取得の要求
private boolean checkPermission() {
    if (checkSelfPermission(Manifest.permission.ACCESS_FINE_LOCATION) != PackageManager.PERMISSION_GRANTED) { requestPermissions(new String[]{Manifest.permission.ACCESS_FINE_LOCATION}, PERMISSIONS_REQUEST_LOCATION_STATE);
        return false;
    }
    return true;
}

許可/不許可の結果は onRequestPermissionsResult で判別出来ます。
@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {
    if (PERMISSIONS_REQUEST_LOCATION_STATE == requestCode) {
        if (grantResults[0] == PackageManager.PERMISSION_GRANTED) {
            // 許可された場合
            Toast.makeText(this, "許可されました", Toast.LENGTH_SHORT).show();
        } else {
            // 不許可だった場合
            Toast.makeText(this, "権限を拒否されました", Toast.LENGTH_SHORT).show();
            finish();
        }
    }
}
事前準備としては以上です。
次はBluetooth関連クラスを使用していきます。

BluetoothAdapterの取得
まずはBluetoothAdapterを取得します。
(BluetoothAdapterは、すべてのBluetooth相互作用のためのエントリー・ポイントです。)
final BluetoothManager bluetoothManager = (BluetoothManager)getSystemService(Context.BLUETOOTH_SERVICE);
mBluetoothAdapter = bluetoothManager.getAdapter();
次に、端末のBluetoothが有効になっているかの確認を行います。
もし、Bluetoothが無効であればユーザーに有効にするように促します。
if (mBluetoothAdapter == null || !mBluetoothAdapter.isEnabled()) {
    Intent enableBtIntent = new Intent(BluetoothAdapter.ACTION_REQUEST_ENABLE);
    startActivityForResult(enableBtIntent, REQUEST_ENABLE_BT);
}

BLEデバイスの検知
次にBLEデバイスの検知方法を紹介します。
サンプルアプリでは、BLEを検知する為にBluetoothAdapter#startLeScanを使用していますが、APIレベル21から非推奨となり、現在はBluetoothLeScannerを利用するようになりました。
使用方法は以下の通りです。

先ほど取得したBluetoothAdapterからBluetoothLeScannerを取得します。
mBluetoothLeScanner = mBluetoothAdapter.getBluetoothLeScanner();
BluetoothLeScannerを取得したら、以下のAPIを利用してスキャンの開始/停止を制御します。
そして、BLE機器が検知された場合、ScanCallback#onScanResultが呼び出され、ScanResultからBluetoothDeviceが取得出来ます。

BLEデバイスのスキャン開始

BLEデバイスのスキャン停止
BLEスキャンのCallback
// Device scan callback.
private ScanCallback mScanCallback = new ScanCallback() {
    @Override
    public void onScanResult(int callbackType, final ScanResult result) {
        super.onScanResult(callbackType, result);
        if (result != null && result.getDevice() != null) {
            runOnUiThread(new Runnable() {
               @Override
               public void run() {
                   mLeDeviceListAdapter.addDevice(result.getDevice());
                   mLeDeviceListAdapter.notifyDataSetChanged();
               }
            });
        }
    }
};
これで周辺のBLE機器の検知がすることが出来ました。
では次に、検知したデバイスに接続を行います。

ペアリング(GATTサーバーに接続)方法
ペアリングと銘打ってますが、BLEデバイスと通信を行う際にはペアリングをする必要はありません。(対応していればペアリングを行うことも可能です)
BLEデバイスの情報を取得するには、GATTサーバーに接続を行うことで、BLEデバイスの情報を読みとることが可能です。

GATTサーバーに接続するには先ほど検知したBluetoothDeviceのBluetoothDevice#connectGattメソッドを使用します。
mBluetoothGatt = device.connectGatt(this, false, mGattCallback);
接続が確立されると、BluetoothGattCallback#onConnectionStateChangeが呼ばれます。
newState が BluetoothProfile.STATE_CONNECTEDであれば接続が完了している状態です。

接続が確認出来たら、BluetoothGatt#discoverServicesにより、Gattサーバーの情報を検索します。
結果は BluetoothGattCallback#onServicesDiscovered が呼び出されます。

@Override
public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState) {
    String intentAction;
    if (newState == BluetoothProfile.STATE_CONNECTED) {
        mBluetoothGatt.discoverServices();
    }
}

@Override
public void onServicesDiscovered(BluetoothGatt gatt, int status) {
    super.onServicesDiscovered(gatt, status);
    serviceList = gatt.getServices();
    // サービスの内容を取得等処理を行う
    // 取得したサービスからBLEデバイスの情報を取得する
}
以上が、BLEデバイス検知から接続までの方法になります。

では最後に、BLEデバイスの情報を取りまとめるGATTについての説明をします。

Generic Attribute Profile (GATT)について
GATTとは、前回の記事で言うところのBluetooth 4.0で使用出来るプロファイルです。

GATTプロファイルは、"attribute"として知られる、BLE link上での短いデータの送受信の一般的な仕様で、現在のBLEアプリケーションプロファイルは、全て、GATTをベースにしています。

※Bluetooth SIGは、BLE端末のための多くのプロファイルを定義します。
※プロファイルは、特定のアプリケーションにおける端末の動作仕様です。
※端末は1つ以上のプロファイルを実装可能です。


図3 Generic Attribute Profile (GATT)について
https://developer.bluetooth.org/TechnologyOverview/Pages/GATT.aspx より引用

・Attribute Protocol (ATT)
GATTは、Attribute Protocol (ATT)の上位に組み込まれています。
GATT/ATTとしても参照されます。
ATTは、BLEデバイス上で動作するよう最適化されています(数バイト使用します)
各attributeは、Universally Unique Identifier (UUID)によりユニークに識別され、ユニークに情報を識別するために使われるstring IDのため標準化された128-bitフォーマットとなります。
ATTにより転送されたattributeは、characteristicおよびserviceとしてフォーマットされています。

・Characteristic
characteristicは1つの値と0-nのcharacteristicに言及するdescriptorを含みます。
characteristicはtypeとみなされ、classに似たものとなります。

・Descriptor
Descriptorは、characteristic値を記述する定義されたattributeです。
例えば, characteristicの値が許容可能な範囲を人間が読めるdescriptionとして定義されるものであったり, characteristicの値の単位を表すものであったりします。

・Service
serviceは、characteristicを集めたものです。
例えば, "Heart rate Monitor"と呼ばれるサービスには"heart rate measurement"という名のcharacteristicが含まれます。
既存のGATTベースのprofile/serviceリストをbluetooth.orgで入手可能です。

※これらのサービスやキャラクタリスティックは、Bluetooth SIG が標準として定義していますが、デバイス開発者が独自に定義することも可能です。

GATTプロファイルのサービスとその中にあるCharacteristicを読み取ることで、BLEデバイスの情報を読み出すことが出来ます。

また、GATT通信はサーバークライアントモデルであるため、基本的にはサーバーが機能や情報を保持し、クライアントがそれを利用することになります。

GATTクライアント
 データを利用する機器

GATTサーバー
 データを保持する機器

GATTクライアントとGATTサーバーは接続確立後、2つの端末がどのように通信し合うかのか決定します。
※今回であれば、Nexus 5(client、つまり端末)とNexus 9(server、つまりBLEデバイス)があると考えて下さい。

接続が確立すると、GATTメタデータの他への転送を開始します。
転送するデータの種類により、どちらかがサーバーとして動作します。

例えば、
BLEデバイスがセンサーデータを端末へレポートしたい場合、BLEデバイスがサーバーとして動作するのが理にかなっていると考えられます。
BLEデバイス端末からアップデートを受信したい場合は、端末がサーバーとして動作するのが理にかなっていると考えられます。

本記事で使用したアプリにおいては、Nexus 5はGATTクライアントとして動作しています。
Nexus 5側のアプリ(GATTクライアント)は、Nexus 9(GATTサーバー)からデータを読み取り、アプリ内で解釈することで連携を行っている。という構成になっています。

さいごに

今回はBLEデバイスの検知から接続までをまとめました。

サンプルアプリでBLEの検知と接続を試すことは出来ますが、非推奨になっている点とBLE機能を使用する為の権限が増えている点に御留意いただければと思います。

次回はBLEデバイスからの情報の読み書きを行い、実際にBLE端末とデータのやり取りをしてみたいと思います。

▲[外部] appium_logo_final.eps より引用

■はじめに

自動化テストツールAppium、テストコードの記述言語としてRubyを用いたAndroidアプリケーションの自動テスト実施についての説明を行います。
Appiumはテスト対象アプリのapkファイルがあればソースコードが無くともテストスクリプトを書いてテストを実施することができるため、アプリケーションの受け入れテストに向いているとい。
この記事ではWindowsに環境を構築してサンプルコードを実行するまでを紹介します。


環境構築前の事前準備

Appiumを起動しRubyで書いたテストコードを実行するためには、AppiumとRubyの他にインストールしなければいけないソフトウェアやその設定があります。Androidアプリケーションの開発を行っているのであれば必須と言えるものばかりのため、既に開発環境を構築出済みであれば不要です。


■Android SDK

▲[外部] Android Developers より引用

Appiumでは、テスト対象アプリケーションや補助アプリケーションのインストールやAppium Client LibrariesのAPIでADBコマンドを用いたり、補助アプリケーションをソースコードからビルドしたりします。このため、Android SDKを構成するいくつかのコンポーネントをインストールする必要があります。最低限必要なものは以下の2つです。
  • Android SDK Platform-tools
  • Android SDK Build-tools

Emulatorでの実行を考えているのであれば、ターゲットバージョンのSystem Imageも必要になります。

■Android SDKの環境変数

AppiumではAndroid SDKのインストール先を特定するためにAndroid SDK側の環境変数を参照しています。Android SDKのインストールする方法によっては自動的にセットされる場合もありますが、そうでない場合は別途セットするようにして下さい。
  • 変数名: ANDROID_HOME
  • 値: Android SDKのルートディレクトリのパス

■Java Development Kit 7/8

JavaはAppiumの実行の他、Android SDKに含まれるツールの実行にも必要です。WindowsであればJava Runtime Environment (JRE)のみでも動作するようですが、Android SDKのシステム要件であるJava Development Kit (JDK)をインストールしておくのが良いでしょう。


環境構築

まずはWindowsにAppiumとRubyをインストールする方法を記載します。スクリーンショットはWindows 10のものを用いていますが、Windows 7でも同様の手順で構築可能です。


■Appiumのインストール

Appiumのインストールは、公式サイトからインストーラーをダウンロードし実行することで行います。

▲[外部] Android Developers より引用

ダウンロードしたzipファイルを展開しappium-installer.exeを実行、セットアップウィザードを起動します。あとは画面の指示に従い必要であれば設定を変更しインストールを行って下さい。

インストール完了後Appiumが起動すれば完了です。

■Rubyのインストール

WindowsでRubyの実行環境を構築する場合、Rubyの公式サイトでも紹介されているRubyInstaller for Windowsというサードパーティ製のインストーラーを用いるのが簡単です。

▲[外部] RubyInstaller for Windows より引用

RubyInstallerのサイトのダウンロードページからダウンロードを行うのですが、選択するバージョンには注意が必要です。
最新のRuby 2.2.x(執筆時点ではRuby 2.2.3)ではなく、その下にあるRuby 2.1.x(執筆時点ではRuby 2.1.7)をダウンロードして下さい。これは、Ruby 2.2.xだとテストコード実行時にエラーが発生してしまうためです。

▲[外部] RubyInstaller for Windows より引用

ダウンロードされた実行形式ファイルを実行しセットアップウィザード起動、画面の指示に従ってインストールを行います。

基本的にデフォルトの設定で問題ありませんが、[インストール先とオプションの指定]では[Ruby の実行ファイルへ環境変数 PATH を設定する]にチェックを入れておくと環境変数をセットする手間が省けるため便利です。

コマンドプロンプトで"ruby -v"と実行し、バージョンが表示されればOKです。

>ruby -v
ruby 2.1.7p400 (2015-08-18 revision 51632) [x64-mingw32]

■Rubyのライブラリ(gem)のインストール

Rubyではサードパーティ製のライブラリが"gem"という形式で公開されており、gemコマンドを使用してインストールすることができます。gemコマンドはRubyInstallerでRubyをインストールした際に組み込まれていますので、特にすることはありません。ここではRubyからAppiumを使用するためのライブラリ"appium_lib"をインストールします。
gemのインストールは簡単で、以下のように"gem install <gem名>"と実行するだけです。これによってappium_libと依存するgemがインストールされます。

>gem install appium_lib

これで環境構築は完了です。


サンプルコードの実行

AppiumのサンプルコードはGitHubのappium/sample-codeリポジトリで公開されていますが、rubyのものはxUnitやRSpecといったテスティングフレームワークの利用が前提となっているようです。今回は最小限の環境構築に留めるためそれらは使用しません。apkファイルのみでもテストが可能な事を示すため、公開されているapkファイルを利用させてもらうようにします。

■準備

前述のリポジトリにある sample-code/apps/selendroid-test-app.apk をダウンロードし任意のパスにコピーします。
次にテキストエディタを用いて以下のコードを記述し、先ほどのapkファイルと同じ場所にsample.rbとして保存します。

# encoding: utf-8
require "appium_lib"

desired_caps = {
  caps: {
    platformName:  "Android",
    deviceName:    "Android Device",
    app:           "#{Dir.pwd}/selendroid-test-app.apk",
  }
}

driver = Appium::Driver.new(desired_caps).start_driver
Appium.promote_appium_methods Object

button_element = find_element(:id, "io.selendroid.testapp:id/visibleButtonTest")
button_element.click
sleep 3
text_element = find_element(:id, "io.selendroid.testapp:id/visibleTextView")
displayed_text = text_element.text
button_element.click
sleep 3
puts displayed_text

driver.quit

■実行

Appiumを起動し右上にある右向き三角ボタン(いわゆる再生ボタン)をクリックし、以下のような表示になるまで少し待ちます。

コマンドプロンプトから以下のようにしてサンプルコードを実行します。

>ruby sample.rb

テスト対象アプリケーションとAppiumがテストで使用するアプリケーションのインストール、テスト対象アプリケーションの起動が行われテストが実行されます。最終的にコマンドプロンプトに"Text is sometimes displayed"が表示されれば成功です。

■解説

Appium側の操作によってサーバープログラムが起動しています。PCに接続したデバイスに対して直接操作を行うのがこのサーバーで、テストスクリプトからはサーバーを介して画面の操作や情報の取得を行うことになります。
スクリプトの12行目でサーバーへの接続を行い、Appium::Driverクラスのインスタンスを取得しています。4〜9行目のdesired_capsはそのためのパラメーターです。
15〜22行目がテストの本体となっている部分で、詳細な説明は省きますが、テストアプリケーションの画面に表示されている[Display text view]ボタンをクリックし、表示されたテキスト"Text is sometimes displayed"を変数に保存、それをコマンドプロンプトへ出力する、といった事をしています。

Appium+RubyによるAndroidアプリの受け入れテスト(環境構築)


▲[外部] appium_logo_final.eps より引用

■はじめに

自動化テストツールAppium、テストコードの記述言語としてRubyを用いたAndroidアプリケーションの自動テスト実施についての説明を行います。
Appiumはテスト対象アプリのapkファイルがあればソースコードが無くともテストスクリプトを書いてテストを実施することができるため、アプリケーションの受け入れテストに向いているとい。
この記事ではWindowsに環境を構築してサンプルコードを実行するまでを紹介します。


環境構築前の事前準備

Appiumを起動しRubyで書いたテストコードを実行するためには、AppiumとRubyの他にインストールしなければいけないソフトウェアやその設定があります。Androidアプリケーションの開発を行っているのであれば必須と言えるものばかりのため、既に開発環境を構築出済みであれば不要です。


■Android SDK

▲[外部] Android Developers より引用

Appiumでは、テスト対象アプリケーションや補助アプリケーションのインストールやAppium Client LibrariesのAPIでADBコマンドを用いたり、補助アプリケーションをソースコードからビルドしたりします。このため、Android SDKを構成するいくつかのコンポーネントをインストールする必要があります。最低限必要なものは以下の2つです。
  • Android SDK Platform-tools
  • Android SDK Build-tools

Emulatorでの実行を考えているのであれば、ターゲットバージョンのSystem Imageも必要になります。

■Android SDKの環境変数

AppiumではAndroid SDKのインストール先を特定するためにAndroid SDK側の環境変数を参照しています。Android SDKのインストールする方法によっては自動的にセットされる場合もありますが、そうでない場合は別途セットするようにして下さい。
  • 変数名: ANDROID_HOME
  • 値: Android SDKのルートディレクトリのパス

■Java Development Kit 7/8

JavaはAppiumの実行の他、Android SDKに含まれるツールの実行にも必要です。WindowsであればJava Runtime Environment (JRE)のみでも動作するようですが、Android SDKのシステム要件であるJava Development Kit (JDK)をインストールしておくのが良いでしょう。


環境構築

まずはWindowsにAppiumとRubyをインストールする方法を記載します。スクリーンショットはWindows 10のものを用いていますが、Windows 7でも同様の手順で構築可能です。


■Appiumのインストール

Appiumのインストールは、公式サイトからインストーラーをダウンロードし実行することで行います。

▲[外部] Android Developers より引用

ダウンロードしたzipファイルを展開しappium-installer.exeを実行、セットアップウィザードを起動します。あとは画面の指示に従い必要であれば設定を変更しインストールを行って下さい。

インストール完了後Appiumが起動すれば完了です。

■Rubyのインストール

WindowsでRubyの実行環境を構築する場合、Rubyの公式サイトでも紹介されているRubyInstaller for Windowsというサードパーティ製のインストーラーを用いるのが簡単です。

▲[外部] RubyInstaller for Windows より引用

RubyInstallerのサイトのダウンロードページからダウンロードを行うのですが、選択するバージョンには注意が必要です。
最新のRuby 2.2.x(執筆時点ではRuby 2.2.3)ではなく、その下にあるRuby 2.1.x(執筆時点ではRuby 2.1.7)をダウンロードして下さい。これは、Ruby 2.2.xだとテストコード実行時にエラーが発生してしまうためです。

▲[外部] RubyInstaller for Windows より引用

ダウンロードされた実行形式ファイルを実行しセットアップウィザード起動、画面の指示に従ってインストールを行います。

基本的にデフォルトの設定で問題ありませんが、[インストール先とオプションの指定]では[Ruby の実行ファイルへ環境変数 PATH を設定する]にチェックを入れておくと環境変数をセットする手間が省けるため便利です。

コマンドプロンプトで"ruby -v"と実行し、バージョンが表示されればOKです。

>ruby -v
ruby 2.1.7p400 (2015-08-18 revision 51632) [x64-mingw32]

■Rubyのライブラリ(gem)のインストール

Rubyではサードパーティ製のライブラリが"gem"という形式で公開されており、gemコマンドを使用してインストールすることができます。gemコマンドはRubyInstallerでRubyをインストールした際に組み込まれていますので、特にすることはありません。ここではRubyからAppiumを使用するためのライブラリ"appium_lib"をインストールします。
gemのインストールは簡単で、以下のように"gem install <gem名>"と実行するだけです。これによってappium_libと依存するgemがインストールされます。

>gem install appium_lib

これで環境構築は完了です。


サンプルコードの実行

AppiumのサンプルコードはGitHubのappium/sample-codeリポジトリで公開されていますが、rubyのものはxUnitやRSpecといったテスティングフレームワークの利用が前提となっているようです。今回は最小限の環境構築に留めるためそれらは使用しません。apkファイルのみでもテストが可能な事を示すため、公開されているapkファイルを利用させてもらうようにします。

■準備

前述のリポジトリにある sample-code/apps/selendroid-test-app.apk をダウンロードし任意のパスにコピーします。
次にテキストエディタを用いて以下のコードを記述し、先ほどのapkファイルと同じ場所にsample.rbとして保存します。

# encoding: utf-8
require "appium_lib"

desired_caps = {
  caps: {
    platformName:  "Android",
    deviceName:    "Android Device",
    app:           "#{Dir.pwd}/selendroid-test-app.apk",
  }
}

driver = Appium::Driver.new(desired_caps).start_driver
Appium.promote_appium_methods Object

button_element = find_element(:id, "io.selendroid.testapp:id/visibleButtonTest")
button_element.click
sleep 3
text_element = find_element(:id, "io.selendroid.testapp:id/visibleTextView")
displayed_text = text_element.text
button_element.click
sleep 3
puts displayed_text

driver.quit

■実行

Appiumを起動し右上にある右向き三角ボタン(いわゆる再生ボタン)をクリックし、以下のような表示になるまで少し待ちます。

コマンドプロンプトから以下のようにしてサンプルコードを実行します。

>ruby sample.rb

テスト対象アプリケーションとAppiumがテストで使用するアプリケーションのインストール、テスト対象アプリケーションの起動が行われテストが実行されます。最終的にコマンドプロンプトに"Text is sometimes displayed"が表示されれば成功です。

■解説

Appium側の操作によってサーバープログラムが起動しています。PCに接続したデバイスに対して直接操作を行うのがこのサーバーで、テストスクリプトからはサーバーを介して画面の操作や情報の取得を行うことになります。
スクリプトの12行目でサーバーへの接続を行い、Appium::Driverクラスのインスタンスを取得しています。4〜9行目のdesired_capsはそのためのパラメーターです。
15〜22行目がテストの本体となっている部分で、詳細な説明は省きますが、テストアプリケーションの画面に表示されている[Display text view]ボタンをクリックし、表示されたテキスト"Text is sometimes displayed"を変数に保存、それをコマンドプロンプトへ出力する、といった事をしています。

2015年10月28日水曜日


http://googledevelopers.blogspot.jp/2015/07/lighting-way-with-ble-beacons.html から引用

はじめに

弊社のブログでは様々なiOS + BLEやBLEデバイスの開発の取り組みを紹介してきました。

ということで!

Android Marshmallowの公開もされましたので、これを機にAndroid 6.0 + BLEに関しての記事を掲載していきたいと思います。

今回は第一回目として、BluetoothとBLEのおさらいをしていきながら、今後作るアプリやサービスのイメージを膨らませていきましょう。

Bluetooth

Bluetoothの特徴

  • 無線通信(数mから数十m程度の距離間での通信が可能)
  • 小型で低消費電力
  • 暗号化通信される
  • 混信する可能性がとても低い
Bluetoothは無線接続の状態を意識せずに常時接続したままでの使用状況に適しているので、日常的に身につけるものなどとの相性がとても良いです。
また、近距離で少し大き目のデータでも機器間で通信を行うことも出来ます。

特にPCのマウスやキーボード、ワイヤレスイヤホン、ヘッドフォンなどにも使用されています。
煩わしいケーブルを排除出来るので、作業スペース等がスッキリしてとても使いやすいです。

使用例:
  • マウスやキーボードのパソコン周辺機器
  • オーディオ機器
  • スキャナ/プリンタ

BLE(Bluetooth Low Energy)の特徴

  • 小型で電池消費量が極少(ボタン電池で1年以上) 
  • ペアリングを行わなくても他デバイスに通知が可能(ブロードキャスト通信) 
  • 通信速度は低い
Bluetooth4.0はBluetooth3.0にBLEの技術を統合したもので、BLEとはBluetooth 4.0以降の機能の一部を指します。筆者自身勘違いをしていたのですが、Bluetooth4.0 = BLEというわけではありません。
Bluetooth3.0規格の拡張版がBluetooth4.0であり、その機能の一部がBLEです。

ただし、BLE機能は過去バージョンとの下方互換がまったくない為、BLEのみに対応したデバイスと3.0までのBluetoothデバイスとは接続を行うことが出来ない点に注意が必要です。

BLEデバイスは以下の2種類に分類されます。

Bluetooth Smart

 BLEでのみ通信を行う。従来のBluetooth機器との接続不可。

Bluetooth Smart Ready

 BLEで通信をする子機との通信に対応し、従来のBluetooth機器との接続可。

※ロゴマークに関してはこちらを参照してください。

動画も公開しています。

BLEは常時データをやり取りする必要がなく、1回のデータ量も少ない用途に向いています。
超低消費電力なので、配置してからしばらく電池交換をする手間が必要ありません。
また、ペアリングを行わなくても他デバイスへの通知が可能なことから、通りがかっただけの人などを集客する効果も見込まれています。

使用例:
  • ライフログリストバンド
  • 運動用センサー(スピード/ケイデンス/心拍センサー)
  • 忘れ物防止タグ
  • 降水確立を知らせる傘立て(※)
  • ごみの収集日を知らせるごみ箱(※)
  • スマートウォッチ
※こちらを参照

その他にも生活で使用するもの以外でもユニークなものがこちらで紹介されています。

さて、特徴や使用例をいくつか挙げていきました。

ここまででおさらいしてきたBluetoothの特徴や既に販売されているものや実施されているサービスを踏まえつつ、次はAndroidへと目を向けていきましょう。

Android & Bluetooth

ではAndroidではどのようにBluetoothの制御を行っているのでしょうか。
ここではAndroidのBluetoothアーキテクチャと、Bluetoothのプロファイルについて触れたいと思います。
※アプリケーション側の実装方法などは次回以降紹介します。


Bluetoothアーキテクチャ

アプリケーションは、android.bluetoothのAPIを使いBluetoothハードウェアとの総合通信を行います。
内部的に、Binder IPCメカニズムを介してBluetooth processをコールします。
Bluetooth system serviceはJNIを介してBluetooth stackと通信を行います。
また、Binder IPCを介してアプリと通信を行います。
system serviceにより、開発者は様々なBluetooth profileへのアクセスが可能となります。

下図が、Bluetooth stackの一般的な構造となります。


      
https://source.android.com/devices/bluetooth.html より引用

Bluetooth system service
packages/apps/BluetoothにあるBluetooth system serviceは、Android appとしてパッケージされ、Bluetooth serviceおよびprofileをAndroid framework layerに実装します。このアプリはJNI経由でHAL layerをコールします。

JNI
android.bluetoothと連携しているJNIは、packages/apps/Bluetooth/jniにあります。JNIコードは、HAL layerにコールし、端末が発見された時などのように、特定のBluetoothオペレーションが発生した際にHALからコールバックを受信します。

このような構造で、AndroidはアプリケーションからBluetoothの機能を使用することが出来ます。

アプリケーション開発においては特に、Application Framework部とBluetooth Process部を意識することになりますが、このような構造を知っておくことで、不具合などが発生した場合のデバッグなどにも役立つと思います。

そして、次にBluetooth Process部にあるプロファイルに関して簡単に説明します。

プロファイル

プロファイルというのは簡単に言うと、Bluetooth機器が何を出来るかを定義したものです。
様々な機器と無線通信を行う性質上、どのような順番・タイミングで、どんな種類の情報を転送すべきか、という機器の「使い方」にあたる手順を共通化しておく必要がある。
この手順を機器の特性ごとに標準化したものが、プロファイルです。

参考:
Bluetoothプロファイル 【 Bluetooth Profile 】

接続するBluetooth機器同士が同じプロファイルに対応していることで、その機能が利用できますが、定義されていないと使用することが出来ません。
実際に使用する際にはプロファイルをよく理解し、適切なものを使用しましょう。

・主なBluetoothプロファイル(一部)
HID(Human Interface Device Profile) 入力機器を扱うためのプロファイル
HSP(Headset Profile) ヘッドセットと通信するためのプロファイル
HFP(Hands-Free Profile) ハンズフリー通話をするためのプロファイル
A2DP(Advanced Audio Distribution Profile) 高音質のステレオ音声を伝送するためのプロファイル
AVRCP(Audio/Video Remote Control Profile) AV機器のコントロール(再生、早送り等)を行うためのプロファル
FTP(File Transfer Profile) ファイル転送プロファイル

・4.0から使用出来るBluetoothプロファイル
ANP(Alert Notification Profile) 電話やメールなどの着信を通知するプロファイル
BLP(Blood Pressure Profile) 血圧計から血圧情報を伝送するためのプロファイル
CPP(Cycling Power Profile) サイクリング時の力などを情報を伝送するためのプロファイル
CSCP(Cycling Speed and Cadence Profile) サイクリング時のスピードや回転数などの情報を伝送するためのプロファイル
FMP(Find Me Profile) 遠隔からアラームやバイブレーションを鳴動させ、装置の場所を調べるためのプロファイル
GLP(Glucose Profile) 血糖値の情報を伝送するためのプロファイル
HOGP(HID over GATT Profile) マウスやキーボードなどを接続するためのプロファイル
HTP(Health Thermometer Profile) 体温計の情報を伝送するためのプロファイル
HRP(Heart Rate Profile) 心拍計の情報を伝送するためのプロファイル
IPSP (Internet Protocol Support Profile) IPv6/6LoWPAN経由でインターネットに接続するプロファイル
PASP(Phone Alert Status Profile) 電話着信時の鳴動などを他の機器から止めるためのプロファイル
PXP(Proximity Profile) 互いの機器間の距離をモニタリングするためのプロファイル
RSCP(Running Speed and Cadence Profile) ランニング時のスピードや歩幅などの情報を伝送するためのプロファイル
ScPP(Scan Parameters Profile) 装置のスキャンをするためのプロファイル
TIP(Time Profile) 時刻情報を通知するためのプロフィール
プロファイルの参考:

さいごに

今回はBluetoothやBLEに関してのおさらいを行いましたがいかがだったでしょうか。
BluetoothやBLEを使用したアプリやサービスのイメージは膨らみましたか?

次回からは実際にAndroidアプリケーションでBLEの検知、ペアリング方法を紹介したいと思います。

[第一回] 生活で使えるBLEデバイス


http://googledevelopers.blogspot.jp/2015/07/lighting-way-with-ble-beacons.html から引用

はじめに

弊社のブログでは様々なiOS + BLEやBLEデバイスの開発の取り組みを紹介してきました。

ということで!

Android Marshmallowの公開もされましたので、これを機にAndroid 6.0 + BLEに関しての記事を掲載していきたいと思います。

今回は第一回目として、BluetoothとBLEのおさらいをしていきながら、今後作るアプリやサービスのイメージを膨らませていきましょう。

Bluetooth

Bluetoothの特徴

  • 無線通信(数mから数十m程度の距離間での通信が可能)
  • 小型で低消費電力
  • 暗号化通信される
  • 混信する可能性がとても低い
Bluetoothは無線接続の状態を意識せずに常時接続したままでの使用状況に適しているので、日常的に身につけるものなどとの相性がとても良いです。
また、近距離で少し大き目のデータでも機器間で通信を行うことも出来ます。

特にPCのマウスやキーボード、ワイヤレスイヤホン、ヘッドフォンなどにも使用されています。
煩わしいケーブルを排除出来るので、作業スペース等がスッキリしてとても使いやすいです。

使用例:
  • マウスやキーボードのパソコン周辺機器
  • オーディオ機器
  • スキャナ/プリンタ

BLE(Bluetooth Low Energy)の特徴

  • 小型で電池消費量が極少(ボタン電池で1年以上) 
  • ペアリングを行わなくても他デバイスに通知が可能(ブロードキャスト通信) 
  • 通信速度は低い
Bluetooth4.0はBluetooth3.0にBLEの技術を統合したもので、BLEとはBluetooth 4.0以降の機能の一部を指します。筆者自身勘違いをしていたのですが、Bluetooth4.0 = BLEというわけではありません。
Bluetooth3.0規格の拡張版がBluetooth4.0であり、その機能の一部がBLEです。

ただし、BLE機能は過去バージョンとの下方互換がまったくない為、BLEのみに対応したデバイスと3.0までのBluetoothデバイスとは接続を行うことが出来ない点に注意が必要です。

BLEデバイスは以下の2種類に分類されます。

Bluetooth Smart

 BLEでのみ通信を行う。従来のBluetooth機器との接続不可。

Bluetooth Smart Ready

 BLEで通信をする子機との通信に対応し、従来のBluetooth機器との接続可。

※ロゴマークに関してはこちらを参照してください。

動画も公開しています。

BLEは常時データをやり取りする必要がなく、1回のデータ量も少ない用途に向いています。
超低消費電力なので、配置してからしばらく電池交換をする手間が必要ありません。
また、ペアリングを行わなくても他デバイスへの通知が可能なことから、通りがかっただけの人などを集客する効果も見込まれています。

使用例:
  • ライフログリストバンド
  • 運動用センサー(スピード/ケイデンス/心拍センサー)
  • 忘れ物防止タグ
  • 降水確立を知らせる傘立て(※)
  • ごみの収集日を知らせるごみ箱(※)
  • スマートウォッチ
※こちらを参照

その他にも生活で使用するもの以外でもユニークなものがこちらで紹介されています。

さて、特徴や使用例をいくつか挙げていきました。

ここまででおさらいしてきたBluetoothの特徴や既に販売されているものや実施されているサービスを踏まえつつ、次はAndroidへと目を向けていきましょう。

Android & Bluetooth

ではAndroidではどのようにBluetoothの制御を行っているのでしょうか。
ここではAndroidのBluetoothアーキテクチャと、Bluetoothのプロファイルについて触れたいと思います。
※アプリケーション側の実装方法などは次回以降紹介します。


Bluetoothアーキテクチャ

アプリケーションは、android.bluetoothのAPIを使いBluetoothハードウェアとの総合通信を行います。
内部的に、Binder IPCメカニズムを介してBluetooth processをコールします。
Bluetooth system serviceはJNIを介してBluetooth stackと通信を行います。
また、Binder IPCを介してアプリと通信を行います。
system serviceにより、開発者は様々なBluetooth profileへのアクセスが可能となります。

下図が、Bluetooth stackの一般的な構造となります。


      
https://source.android.com/devices/bluetooth.html より引用

Bluetooth system service
packages/apps/BluetoothにあるBluetooth system serviceは、Android appとしてパッケージされ、Bluetooth serviceおよびprofileをAndroid framework layerに実装します。このアプリはJNI経由でHAL layerをコールします。

JNI
android.bluetoothと連携しているJNIは、packages/apps/Bluetooth/jniにあります。JNIコードは、HAL layerにコールし、端末が発見された時などのように、特定のBluetoothオペレーションが発生した際にHALからコールバックを受信します。

このような構造で、AndroidはアプリケーションからBluetoothの機能を使用することが出来ます。

アプリケーション開発においては特に、Application Framework部とBluetooth Process部を意識することになりますが、このような構造を知っておくことで、不具合などが発生した場合のデバッグなどにも役立つと思います。

そして、次にBluetooth Process部にあるプロファイルに関して簡単に説明します。

プロファイル

プロファイルというのは簡単に言うと、Bluetooth機器が何を出来るかを定義したものです。
様々な機器と無線通信を行う性質上、どのような順番・タイミングで、どんな種類の情報を転送すべきか、という機器の「使い方」にあたる手順を共通化しておく必要がある。
この手順を機器の特性ごとに標準化したものが、プロファイルです。

参考:
Bluetoothプロファイル 【 Bluetooth Profile 】

接続するBluetooth機器同士が同じプロファイルに対応していることで、その機能が利用できますが、定義されていないと使用することが出来ません。
実際に使用する際にはプロファイルをよく理解し、適切なものを使用しましょう。

・主なBluetoothプロファイル(一部)
HID(Human Interface Device Profile) 入力機器を扱うためのプロファイル
HSP(Headset Profile) ヘッドセットと通信するためのプロファイル
HFP(Hands-Free Profile) ハンズフリー通話をするためのプロファイル
A2DP(Advanced Audio Distribution Profile) 高音質のステレオ音声を伝送するためのプロファイル
AVRCP(Audio/Video Remote Control Profile) AV機器のコントロール(再生、早送り等)を行うためのプロファル
FTP(File Transfer Profile) ファイル転送プロファイル

・4.0から使用出来るBluetoothプロファイル
ANP(Alert Notification Profile) 電話やメールなどの着信を通知するプロファイル
BLP(Blood Pressure Profile) 血圧計から血圧情報を伝送するためのプロファイル
CPP(Cycling Power Profile) サイクリング時の力などを情報を伝送するためのプロファイル
CSCP(Cycling Speed and Cadence Profile) サイクリング時のスピードや回転数などの情報を伝送するためのプロファイル
FMP(Find Me Profile) 遠隔からアラームやバイブレーションを鳴動させ、装置の場所を調べるためのプロファイル
GLP(Glucose Profile) 血糖値の情報を伝送するためのプロファイル
HOGP(HID over GATT Profile) マウスやキーボードなどを接続するためのプロファイル
HTP(Health Thermometer Profile) 体温計の情報を伝送するためのプロファイル
HRP(Heart Rate Profile) 心拍計の情報を伝送するためのプロファイル
IPSP (Internet Protocol Support Profile) IPv6/6LoWPAN経由でインターネットに接続するプロファイル
PASP(Phone Alert Status Profile) 電話着信時の鳴動などを他の機器から止めるためのプロファイル
PXP(Proximity Profile) 互いの機器間の距離をモニタリングするためのプロファイル
RSCP(Running Speed and Cadence Profile) ランニング時のスピードや歩幅などの情報を伝送するためのプロファイル
ScPP(Scan Parameters Profile) 装置のスキャンをするためのプロファイル
TIP(Time Profile) 時刻情報を通知するためのプロフィール
プロファイルの参考:

さいごに

今回はBluetoothやBLEに関してのおさらいを行いましたがいかがだったでしょうか。
BluetoothやBLEを使用したアプリやサービスのイメージは膨らみましたか?

次回からは実際にAndroidアプリケーションでBLEの検知、ペアリング方法を紹介したいと思います。


Android 5.0 Lollipopで追加されたandroid.hardware.camera2を使うことで、
JPEG画像だけでなく、RAW画像も撮影できるようになりました。

普段はJPEGで撮影しているけど、失敗できない"とっておきの時"はRAWで撮影する。
一眼レフカメラをお使いの方はそんな使い分けをされているかもしれません。

今回は、その撮影方法をご紹介したいと思います。

Camera2Rawをベースに撮影に必要な部分を引用して説明いたします。


■RAW画像とは


デジタルカメラでは一般的に「写真」としてJPEG画像を生成するが、RAW画像は
JPEG画像を生成する元となる「生」の画像データである。

非可逆圧縮されたJPEG画像と比べて、RAW画像は無圧縮(可逆圧縮)であるため
サイズが非常に大きくなっています。

しかし、RAW画像は撮影後に専用の現像ソフトによって露出やホワイトバランスを
思い通りに変更することができるため、「現像」工程を自身で行うことができます。


■撮影の流れ


下記の手順でカメラを制御することで撮影画像を取得することができます。
  • カメラをセットアップする
  • カメラを開く
  • プレビューを表示する
  • 撮影する
  • 画像を保存する

それでは早速内容を見ていきます。


カメラをセットアップする


カメラを使用して画像をSTORAGEへ保存するために下記パーミッションを追加します。

<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />

※注意※
 Android 6.0 (API Level 23)より上記パーミッションのプロテクションレベルが
 Dangerousとなります。
 そのため、そのまま使用すると実行時にSecurity Exceptionが発生します。

 上記の環境でプログラムを実行する際にはContextCompat.checkSelfPermissionを
 用いて、ユーザの許可を得る必要があります。


次に下記featureを定義することでRAW画像の撮影が可能になります。

<uses-feature android:name="android.hardware.camera" />
<uses-feature android:name="android.hardware.camera.raw" />


アプリが起動するとonResume→openCameraと呼ばれ、setUpCameraOutputs
の中でgetCameraCharacteristicsを呼び出すことでカメラデバイスが
有する機能を取得することができます。

CameraCharacteristics characteristics
    = manager.getCameraCharacteristics(cameraId);

// We only use a camera that supports RAW in this sample.
if (!contains(characteristics.get(
        CameraCharacteristics.REQUEST_AVAILABLE_CAPABILITIES),
   CameraCharacteristics.REQUEST_AVAILABLE_CAPABILITIES_RAW)) {
        continue;
}

上記では、取得した機能を用いてRAW撮影に対応している場合のみ撮影可能と判定しています。

また、ImageReaderへsetOnImageAvailableListenerでCallbackを設定することで
画像が保存可能になった際にCallbackを受けることができます。
第2引数へHandlerを渡すことで非同期に画像の取得処理を行います。

if (mRawImageReader == null || mRawImageReader.getAndRetain() == null) {
    mRawImageReader = new RefCountedAutoCloseable<>(<
            ImageReader.newInstance(largestRaw.getWidth(),
                    largestRaw.getHeight(), ImageFormat.RAW_SENSOR, /*maxImages*/ 5));
}
mRawImageReader.get().setOnImageAvailableListener(
        mOnRawImageAvailableListener, mBackgroundHandler);
}

カメラを開く


次にopenCameraに戻り、CameraManagerのopenCameraを呼び出します。
これにより、カメラを開き、処理が完了した際のCallbackを受けることができます。

private void openCamera() {

    CameraManager manager = (CameraManager) activity.getSystemService(Context.CAMERA_SERVICE);
        manager.openCamera(cameraId, mStateCallback, backgroundHandler);
}

カメラOpenのCallback処理にてプレビューを開始します。

private final CameraDevice.StateCallback mStateCallback = new CameraDevice.StateCallback() {
@Override
public void onOpened(CameraDevice cameraDevice) {
    synchronized (mCameraStateLock) {
        // Start the preview session if the TextureView has been set up already.
        if (mPreviewSize != null && mTextureView.isAvailable()) {
                createCameraPreviewSessionLocked();
        }
    }
}

■プレビューを表示する


createCaptureSessionにてCameraCaptureSessionを生成します。
生成が正常に完了すると、CameraCaptureSession.StateCallbackの
onConfiguredが呼び出されます。

setup3AControlsLockedでは、3A(auto-focus, auto-exposure, auto-white-balance)
の設定を行いRequestへ設定します。

Sessionに対して上記で設定したRequestを発行することでプレビュー用フレームデータを
取得することができます。

最後にsetRepeatingRequestを呼び出すと表示用のSurfaceTextureへプレビューが表示されます。
また、RepeatingRequestを設定することで、captureを繰り返し行う必要がなく、
プレビュー用フレームを継続的に取得することができます。

private void createCameraPreviewSessionLocked() {
    try {
        SurfaceTexture texture = mTextureView.getSurfaceTexture();

        // Here, we create a CameraCaptureSession for camera preview.
        mCameraDevice.createCaptureSession(Arrays.asList(surface,
           mJpegImageReader.get().getSurface(),
           mRawImageReader.get().getSurface()), new CameraCaptureSession.StateCallback() {
           @Override
           public void onConfigured(CameraCaptureSession cameraCaptureSession) {
               synchronized (mCameraStateLock) {

                  setup3AControlsLocked(mPreviewRequestBuilder);
                  // Finally, we start displaying the camera preview.
                  cameraCaptureSession.setRepeatingRequest(
                     mPreviewRequestBuilder.build(),
                     mPreCaptureCallback, mBackgroundHandler);
                  mState = STATE_PREVIEW;
 
    } catch (CameraAccessException e) {
        e.printStackTrace();
    }
}

■撮影する

CameraCaptureSessionのcaptureにより撮影を開始します。
フレームのキャプチャが開始されるとCaptureCallbackが呼び出されます。

private void takePicture() {
    // Replace the existing repeating request with one with updated 3A triggers.
    mCaptureSession.capture(mPreviewRequestBuilder.build(), mPreCaptureCallback,
        mBackgroundHandler);
}

CaptureCallbackではPre-capture処理としてcaptureStillPictureLockedを呼び出し、
キャプチャするフレームの設定を行います。
最後にもう一度CameraCaptureSessionのcaptureを呼び出すことで
カメラデバイスに対して撮影処理のRequestを発行します。

private void captureStillPictureLocked() {
    // Use the same AE and AF modes as the preview.
    setup3AControlsLocked(captureBuilder);

    // Create an ImageSaverBuilder in which to collect results, and add it to the queue
    // of active requests.
    ImageSaver.ImageSaverBuilder rawBuilder = new ImageSaver.ImageSaverBuilder(activity)
        .setCharacteristics(mCharacteristics);

    mRawResultQueue.put((int) request.getTag(), rawBuilder);
    mCaptureSession.capture(request, mCaptureCallback, mBackgroundHandler);
}

撮影が完了するとCameraCaptureSession.CaptureCallbackの
onCaptureCompletedが呼び出されます。

@Override
public void onCaptureCompleted(CameraCaptureSession session, CaptureRequest request,
    TotalCaptureResult result) {
        synchronized (mCameraStateLock) {
        rawBuilder = mRawResultQueue.get(requestId);

        handleCompletionLocked(requestId, rawBuilder, mRawResultQueue);

        if (rawBuilder != null) {
            rawBuilder.setResult(result);
            if (jpegBuilder != null) sb.append(", ");
            sb.append("Saving RAW as: ");
            sb.append(rawBuilder.getSaveLocation());
        }
        finishedCaptureLocked();
    }
}

handleCompletionLockedでImageSaverを生成し、
バックグラウンドのスレッドとして実行します。
ImageSaverでは、画像の保存処理を行います。

private void handleCompletionLocked(int requestId, ImageSaver.ImageSaverBuilder builder,
    TreeMap<Integer, ImageSaver.ImageSaverBuilder> queue) {

    ImageSaver saver = builder.buildIfComplete();
    if (saver != null) {
        queue.remove(requestId);
        AsyncTask.THREAD_POOL_EXECUTOR.execute(saver);
    }
}

■画像を保存する


ImageSaverでは、RAW画像の保存を行います。
DngCreator classを使って取得したデータをDNGファイル形式へ変換します。

DNGファイルとは米アドビシステムズが開発したファイル形式です。詳細は、リンク先の「Adobe DNG ~ specification」を参照ください


    switch (format) {
        case ImageFormat.RAW_SENSOR: {
            DngCreator dngCreator = new DngCreator(mCharacteristics, mCaptureResult);
            FileOutputStream output = null;
            try {
                output = new FileOutputStream(mFile);
                dngCreator.writeImage(output, mImage);
                success = true;
            } finally {
                mImage.close();
                closeOutput(output);
            }
        }
    }

最後にMediaScannerConnection classのscanFileを使って、
画像をContentProviderへ登録します。
これにより、撮影した画像をギャラリーへ反映させることができます。

    if (success) {
        MediaScannerConnection.scanFile(mContext, new String[]{mFile.getPath()},
        /*mimeTypes*/null, new MediaScannerConnection.MediaScannerConnectionClient() {

        @Override
        public void onScanCompleted(String path, Uri uri) {
            Log.i(TAG, "Scanned " + path + ":");
            Log.i(TAG, "-> uri=" + uri);
        }
    });

■撮影を終えて


Nexus6で撮影したところ、24MB程度のRAW画像が取得できました。
同じサイズで撮影したJPEGファイルは、1.5MB程度であるため、
比較すると非常に大きなサイズであることがわかります。

近年、スマホに搭載されるカメラの性能が上がったため、子供の運動会や
結婚式でもスマホで撮影しているシーンをよく見かけます。

大事なシーンの撮影は一眼レフカメラで撮影するイメージが強かったのですが、
スマホがどんどんその性能に近づいてきているんだなと実感しました。


[コラム]Android camera2を使ってRAW画像を撮影する



Android 5.0 Lollipopで追加されたandroid.hardware.camera2を使うことで、
JPEG画像だけでなく、RAW画像も撮影できるようになりました。

普段はJPEGで撮影しているけど、失敗できない"とっておきの時"はRAWで撮影する。
一眼レフカメラをお使いの方はそんな使い分けをされているかもしれません。

今回は、その撮影方法をご紹介したいと思います。

Camera2Rawをベースに撮影に必要な部分を引用して説明いたします。


■RAW画像とは


デジタルカメラでは一般的に「写真」としてJPEG画像を生成するが、RAW画像は
JPEG画像を生成する元となる「生」の画像データである。

非可逆圧縮されたJPEG画像と比べて、RAW画像は無圧縮(可逆圧縮)であるため
サイズが非常に大きくなっています。

しかし、RAW画像は撮影後に専用の現像ソフトによって露出やホワイトバランスを
思い通りに変更することができるため、「現像」工程を自身で行うことができます。


■撮影の流れ


下記の手順でカメラを制御することで撮影画像を取得することができます。
  • カメラをセットアップする
  • カメラを開く
  • プレビューを表示する
  • 撮影する
  • 画像を保存する

それでは早速内容を見ていきます。


カメラをセットアップする


カメラを使用して画像をSTORAGEへ保存するために下記パーミッションを追加します。

<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />

※注意※
 Android 6.0 (API Level 23)より上記パーミッションのプロテクションレベルが
 Dangerousとなります。
 そのため、そのまま使用すると実行時にSecurity Exceptionが発生します。

 上記の環境でプログラムを実行する際にはContextCompat.checkSelfPermissionを
 用いて、ユーザの許可を得る必要があります。


次に下記featureを定義することでRAW画像の撮影が可能になります。

<uses-feature android:name="android.hardware.camera" />
<uses-feature android:name="android.hardware.camera.raw" />


アプリが起動するとonResume→openCameraと呼ばれ、setUpCameraOutputs
の中でgetCameraCharacteristicsを呼び出すことでカメラデバイスが
有する機能を取得することができます。

CameraCharacteristics characteristics
    = manager.getCameraCharacteristics(cameraId);

// We only use a camera that supports RAW in this sample.
if (!contains(characteristics.get(
        CameraCharacteristics.REQUEST_AVAILABLE_CAPABILITIES),
   CameraCharacteristics.REQUEST_AVAILABLE_CAPABILITIES_RAW)) {
        continue;
}

上記では、取得した機能を用いてRAW撮影に対応している場合のみ撮影可能と判定しています。

また、ImageReaderへsetOnImageAvailableListenerでCallbackを設定することで
画像が保存可能になった際にCallbackを受けることができます。
第2引数へHandlerを渡すことで非同期に画像の取得処理を行います。

if (mRawImageReader == null || mRawImageReader.getAndRetain() == null) {
    mRawImageReader = new RefCountedAutoCloseable<>(<
            ImageReader.newInstance(largestRaw.getWidth(),
                    largestRaw.getHeight(), ImageFormat.RAW_SENSOR, /*maxImages*/ 5));
}
mRawImageReader.get().setOnImageAvailableListener(
        mOnRawImageAvailableListener, mBackgroundHandler);
}

カメラを開く


次にopenCameraに戻り、CameraManagerのopenCameraを呼び出します。
これにより、カメラを開き、処理が完了した際のCallbackを受けることができます。

private void openCamera() {

    CameraManager manager = (CameraManager) activity.getSystemService(Context.CAMERA_SERVICE);
        manager.openCamera(cameraId, mStateCallback, backgroundHandler);
}

カメラOpenのCallback処理にてプレビューを開始します。

private final CameraDevice.StateCallback mStateCallback = new CameraDevice.StateCallback() {
@Override
public void onOpened(CameraDevice cameraDevice) {
    synchronized (mCameraStateLock) {
        // Start the preview session if the TextureView has been set up already.
        if (mPreviewSize != null && mTextureView.isAvailable()) {
                createCameraPreviewSessionLocked();
        }
    }
}

■プレビューを表示する


createCaptureSessionにてCameraCaptureSessionを生成します。
生成が正常に完了すると、CameraCaptureSession.StateCallbackの
onConfiguredが呼び出されます。

setup3AControlsLockedでは、3A(auto-focus, auto-exposure, auto-white-balance)
の設定を行いRequestへ設定します。

Sessionに対して上記で設定したRequestを発行することでプレビュー用フレームデータを
取得することができます。

最後にsetRepeatingRequestを呼び出すと表示用のSurfaceTextureへプレビューが表示されます。
また、RepeatingRequestを設定することで、captureを繰り返し行う必要がなく、
プレビュー用フレームを継続的に取得することができます。

private void createCameraPreviewSessionLocked() {
    try {
        SurfaceTexture texture = mTextureView.getSurfaceTexture();

        // Here, we create a CameraCaptureSession for camera preview.
        mCameraDevice.createCaptureSession(Arrays.asList(surface,
           mJpegImageReader.get().getSurface(),
           mRawImageReader.get().getSurface()), new CameraCaptureSession.StateCallback() {
           @Override
           public void onConfigured(CameraCaptureSession cameraCaptureSession) {
               synchronized (mCameraStateLock) {

                  setup3AControlsLocked(mPreviewRequestBuilder);
                  // Finally, we start displaying the camera preview.
                  cameraCaptureSession.setRepeatingRequest(
                     mPreviewRequestBuilder.build(),
                     mPreCaptureCallback, mBackgroundHandler);
                  mState = STATE_PREVIEW;
 
    } catch (CameraAccessException e) {
        e.printStackTrace();
    }
}

■撮影する

CameraCaptureSessionのcaptureにより撮影を開始します。
フレームのキャプチャが開始されるとCaptureCallbackが呼び出されます。

private void takePicture() {
    // Replace the existing repeating request with one with updated 3A triggers.
    mCaptureSession.capture(mPreviewRequestBuilder.build(), mPreCaptureCallback,
        mBackgroundHandler);
}

CaptureCallbackではPre-capture処理としてcaptureStillPictureLockedを呼び出し、
キャプチャするフレームの設定を行います。
最後にもう一度CameraCaptureSessionのcaptureを呼び出すことで
カメラデバイスに対して撮影処理のRequestを発行します。

private void captureStillPictureLocked() {
    // Use the same AE and AF modes as the preview.
    setup3AControlsLocked(captureBuilder);

    // Create an ImageSaverBuilder in which to collect results, and add it to the queue
    // of active requests.
    ImageSaver.ImageSaverBuilder rawBuilder = new ImageSaver.ImageSaverBuilder(activity)
        .setCharacteristics(mCharacteristics);

    mRawResultQueue.put((int) request.getTag(), rawBuilder);
    mCaptureSession.capture(request, mCaptureCallback, mBackgroundHandler);
}

撮影が完了するとCameraCaptureSession.CaptureCallbackの
onCaptureCompletedが呼び出されます。

@Override
public void onCaptureCompleted(CameraCaptureSession session, CaptureRequest request,
    TotalCaptureResult result) {
        synchronized (mCameraStateLock) {
        rawBuilder = mRawResultQueue.get(requestId);

        handleCompletionLocked(requestId, rawBuilder, mRawResultQueue);

        if (rawBuilder != null) {
            rawBuilder.setResult(result);
            if (jpegBuilder != null) sb.append(", ");
            sb.append("Saving RAW as: ");
            sb.append(rawBuilder.getSaveLocation());
        }
        finishedCaptureLocked();
    }
}

handleCompletionLockedでImageSaverを生成し、
バックグラウンドのスレッドとして実行します。
ImageSaverでは、画像の保存処理を行います。

private void handleCompletionLocked(int requestId, ImageSaver.ImageSaverBuilder builder,
    TreeMap<Integer, ImageSaver.ImageSaverBuilder> queue) {

    ImageSaver saver = builder.buildIfComplete();
    if (saver != null) {
        queue.remove(requestId);
        AsyncTask.THREAD_POOL_EXECUTOR.execute(saver);
    }
}

■画像を保存する


ImageSaverでは、RAW画像の保存を行います。
DngCreator classを使って取得したデータをDNGファイル形式へ変換します。

DNGファイルとは米アドビシステムズが開発したファイル形式です。詳細は、リンク先の「Adobe DNG ~ specification」を参照ください


    switch (format) {
        case ImageFormat.RAW_SENSOR: {
            DngCreator dngCreator = new DngCreator(mCharacteristics, mCaptureResult);
            FileOutputStream output = null;
            try {
                output = new FileOutputStream(mFile);
                dngCreator.writeImage(output, mImage);
                success = true;
            } finally {
                mImage.close();
                closeOutput(output);
            }
        }
    }

最後にMediaScannerConnection classのscanFileを使って、
画像をContentProviderへ登録します。
これにより、撮影した画像をギャラリーへ反映させることができます。

    if (success) {
        MediaScannerConnection.scanFile(mContext, new String[]{mFile.getPath()},
        /*mimeTypes*/null, new MediaScannerConnection.MediaScannerConnectionClient() {

        @Override
        public void onScanCompleted(String path, Uri uri) {
            Log.i(TAG, "Scanned " + path + ":");
            Log.i(TAG, "-> uri=" + uri);
        }
    });

■撮影を終えて


Nexus6で撮影したところ、24MB程度のRAW画像が取得できました。
同じサイズで撮影したJPEGファイルは、1.5MB程度であるため、
比較すると非常に大きなサイズであることがわかります。

近年、スマホに搭載されるカメラの性能が上がったため、子供の運動会や
結婚式でもスマホで撮影しているシーンをよく見かけます。

大事なシーンの撮影は一眼レフカメラで撮影するイメージが強かったのですが、
スマホがどんどんその性能に近づいてきているんだなと実感しました。


2015年10月23日金曜日


Android6.0 Marshmallow (マシュマロ)では、テキスト選択(Text Selection)の動作が仕様変更となりました。これまでは、テキスト選択時に画面上部のアクションバー(Action Bar)という部分に、コピー、貼り付け、切り取り、などのメニューが表示されていましたが、今回の仕様変更によってアクションバーへの表示はなくなり、選択した文字列のすぐ近くにメニューバーが表示されるようになりました。これによって、ユーザーはテキスト選択時に、選んだ文字列からあまり視線を離すことなく、メニューを選ぶことができるようになります。今回は、そのテキストビューの変更とバックグラウンド機能として導入されたフローティングアクションバー(Floating Action Bar)について簡単に紹介したいと思います。


■仕様変更となったテキスト選択時のアクションバー


以前のテキスト選択時の動作は、画像1のように、画面上部に「Text selection」というタイトルが表示され、その横にメニューのアイコンが並ぶという形でした。

画像1 [テキスト選択時(Android API Lv 22)]

Android 6.0(API LV 23)では、画像2のような動きに変わりました。

画像2 [テキスト選択時(Android API Lv 23)]

プログラムの方ですが、開発者は何もしなくても、テキストビューを画面に配置しただけで、デフォルトでフローティングアクションモードとしてテキスト選択時の動きをしてくれます。実際、画像1と2のプログラムは、図1のように同じコードで、コンパイルするAPIレベルを22と23に変えただけです。

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        TextView textView = (TextView) findViewById(R.id.sample_text);
        textView.setText(R.string.sample_text);
        textView.setTextIsSelectable(true);

    }

もちろん、図2のようにレイアウトXMLに記載してもOKです。

    <TextView
        android:id="@+id/sample_text"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:textIsSelectable="true"
        android:text="@string/sample_text"
        />

この背後にある仕組みについて言います。

アクションバーへのメニューの表示やメニュー選択時の動きは、アクションモード(Action Mode)という仕組みで実現されています。テキストが選択された場合、テキストビューは、アクションバーにメニューを表示するようアクションモードに処理を依頼します(図3)。

図3 [アクションモード]

 このようにして、テキスト選択時の動作は実現されていますが、テキスト選択時のメニューバーの表示位置の変更にあたって、このアクションモードという仕組みに手が入りました。具体的には、アクションモードにフローティング(浮かんでいる)という新たな種別が追加になりました。このフローティングタイプのアクションモードを動かすと、対象となる部品のすぐそばにメニューバーを表示することになります。一方、これまでのアクションバーへの表示は、プライマリ(基本的な、主な)という種別として新たに呼ばれるようになり、アクションモードを利用する場合には、この2種類を選べるようになったというわけです。

いろいろ試してみましたが、テキストビューをプライマリのアクションモードとして簡単に設定しなおす方法はなさそうです。プロジェクトによっては、これまでアクションバー(画面上部)に表示されていたメニューが、アンドロイドのバージョンを6.0にあげたことにより、テキストのそばに表示されるようになってしまい、仕様と違う動きになって困るところも出てくるかもしれません。将来的にはどちらも選べるようになってほしいですね。

■Floating Action Mode を使ってみる


実際に、フローティングアクションモード(Floating Action Mode)を使って何か作ってみます。

例えば、テキストを並べたリストに対して、フローティングアクションモードを使ってみましょう。
メニューバーに並べる項目は、追加、削除、共有の三つにしておきます。

[実行の様子1]

サンプルプログラムは、複数選択のリストビューに対して、アイテムをクリックしたときにフローティングアクションバーを表示するようにしています。そのとき、アクションバーを表示する場所が、選択したアイテムに被らないように、選択したアイテムをちょうど覆う矩形領域を計算してアクションモードに渡しています。[実行の様子1]の青い部分が、その矩形領域です。

では、コードの要点の説明です。

アクションモードを使用する場合は、ユーザーの何らかのアクションに対して、アクションされたViewのstartActionModeメソッドを呼ぶ必要があります。


    private class CustomItemClickedListener implements AdapterView.OnItemClickListener {

        @Override
        public void onItemClick(AdapterView parent, View view, int position, long id) {
            ListView listView = (ListView)parent;
            boolean hasChecked = false;
            Rect rect = new Rect();
            Rect sumRect = null;
            int firstVisiblePosition = listView.getFirstVisiblePosition();
            for (int i = 0; i < listView.getChildCount(); i++) {
                TextView textView = (TextView) listView.getChildAt(i);
                if (listView.isItemChecked(firstVisiblePosition + i)) {
                    hasChecked = true;
                    textView.getGlobalVisibleRect(rect);
                    if (sumRect != null) {
                        sumRect.union(rect);
                    }
                    else {
                        sumRect = new Rect(rect);
                    }
                }
            }

            mSumRect = getRectRelTo(sumRect, listView);

            if (hasChecked) {
                showSelectRegion(mSumRect);
                // MEMO: startActionModeは、呼び出しスレッドとは別のスレッドでActionModeのコールバックを呼び出す
                mActionMode = listView.startActionMode(new CustomActionModeCallback(), ActionMode.TYPE_FLOATING);
            }
            else {
                showSelectRegion(null);
                if (mActionMode != null) {
                    mActionMode.finish();
                }
            }
        }
    }
[コード1]は、リストのアイテムをクリックしたときの処理です。

74行目~91行目で表示されている選択項目を覆う矩形領域を求めています。ついでに、選択項目があるかどうかもここでチェックしています。ここで求めた矩形領域は、コード2の方で使用します。

93行目から103行目では、項目が選択されている場合は、上で求めた矩形領域を表示し、リストビューに対して、startActionModeメソッドをTYPE_FLOATINGで呼び出しています。アクションモードのタイプを指定しないタイプのstartActionModeメソッドは、APIレベル11のときから存在していましたが、タイプを指定するstartActionModeメソッドは、APIレベル23から追加されました。startActionModeは、ActionModeオブジェクトを返します。クリックした結果、選択項目がなくなった場合に、このActionModeのfinish()メソッドを呼び出して、フローティングアクションバーを消しています。矩形領域もついでに消しています。showSelectionRegionメソッドは、筆者が作ったプライベートメソッドで、計算でもとめた矩形領域を青い透過色で可視化するためにあります。実際には必要ではありません。

次のコードは、ActionModeのコールバックの実装です。

    private class CustomActionModeCallback extends ActionMode.Callback2 {

        @Override
        public void onGetContentRect(ActionMode mode, View view, Rect outRect) {
            outRect.set(mSumRect);
            mSumRect = null;
        }

        @Override
        public boolean onCreateActionMode(ActionMode mode, Menu menu) {
            menu.add(INSERT);
            menu.add(DELETE);
            menu.add(SHARE);
            return true;
        }

        @Override
        public boolean onPrepareActionMode(ActionMode mode, Menu menu) {
            return false;
        }

        @Override
        public boolean onActionItemClicked(ActionMode mode, MenuItem item) {
            if (item.getTitle().equals(INSERT)) {
                insertNewItem();
            }
            else if (item.getTitle().equals(DELETE)) {
                deleteSelection();
            }
            else if (item.getTitle().equals(SHARE)) {
                shareSelections();
            }
            mode.finish();
            showSelectRegion(null);
            return true;
        }

        @Override
        public void onDestroyActionMode(ActionMode mode) {
        }
    }
[コード2]で実装しているのは、startActionModeメソッドの引数に渡しているActionModeのコールバッククラスです。以前のActionModeのコールバックであるActionMode.Callbackは、インターフェースクラスでしたが、APIレベル23で追加されたこのActionMode.Callback2は、ActionMode.Callbackを実装するクラスとなっています。Callback2クラスは、

public void onGetContentRect(ActionMode mode, View view, Rect outRect)

というメソッドが実装されています。第一引数は、表示しているアクションモードが渡ってきます。第2引数のviewは、startActionModeが呼ばれたViewです。このプログラムの場合は、ListViewがわたってきます。第3引数は、アウト引数で、ここには領域を設定して返してあげます。この領域というのは、フローティングアクションバーがその周りに表示される領域のことです。ここはプログラマーが任意に指定することができます。ActionMode.Callback2のデフォルトの実装では、outRectには、viewの表示領域がそのまま渡されます。今回のプログラムの場合は、アイテムクリック時に計算した矩形領域をここで渡しています(111行目)。

ActionMode.Callback2のその他のメソッドは、ActionMode.Callbackから受け継いだもので、APIレベル23で追加されたメソッドではないので、ここでの説明は省きます。

細かい説明をだいぶ省きましたが、フローティングアクションモードは、矩形領域を計算して、onGetContentRectでアクションモードへ渡してやることがポイントとなります。どんな実装でもこの矩形領域を計算する部分が面倒になりそうです。

■まとめ


簡単ではありますが、Android 6.0 で導入されたテキスト選択の新仕様と、フローティングアクションモードの使い方をご紹介しました。まとめるとこんな感じです:

  • テキストビューは、テキストのそばにメニューが表示され便利になりましたが、以前のように画面上部には表示できなくなりました。
  • 開発者は、アクションバーを使う場合、画面上部のプライマリーにするのか、フローティングにするのかを考えないといけなくなりました。
  • フローティングアクションバーを使う場合は、矩形領域の計算で苦労すると思われます。
冒頭の写真は、いま流行のマシュマロコーヒーです。
今回のマシュマロ・アンドロイドでは、コーヒーに浮かぶマシュマロのような機能が一つ追加されたというわけです。

[コラム] Android6.0「テキスト選択」の新仕様とFloating Action Mode


Android6.0 Marshmallow (マシュマロ)では、テキスト選択(Text Selection)の動作が仕様変更となりました。これまでは、テキスト選択時に画面上部のアクションバー(Action Bar)という部分に、コピー、貼り付け、切り取り、などのメニューが表示されていましたが、今回の仕様変更によってアクションバーへの表示はなくなり、選択した文字列のすぐ近くにメニューバーが表示されるようになりました。これによって、ユーザーはテキスト選択時に、選んだ文字列からあまり視線を離すことなく、メニューを選ぶことができるようになります。今回は、そのテキストビューの変更とバックグラウンド機能として導入されたフローティングアクションバー(Floating Action Bar)について簡単に紹介したいと思います。


■仕様変更となったテキスト選択時のアクションバー


以前のテキスト選択時の動作は、画像1のように、画面上部に「Text selection」というタイトルが表示され、その横にメニューのアイコンが並ぶという形でした。

画像1 [テキスト選択時(Android API Lv 22)]

Android 6.0(API LV 23)では、画像2のような動きに変わりました。

画像2 [テキスト選択時(Android API Lv 23)]

プログラムの方ですが、開発者は何もしなくても、テキストビューを画面に配置しただけで、デフォルトでフローティングアクションモードとしてテキスト選択時の動きをしてくれます。実際、画像1と2のプログラムは、図1のように同じコードで、コンパイルするAPIレベルを22と23に変えただけです。

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        TextView textView = (TextView) findViewById(R.id.sample_text);
        textView.setText(R.string.sample_text);
        textView.setTextIsSelectable(true);

    }

もちろん、図2のようにレイアウトXMLに記載してもOKです。

    <TextView
        android:id="@+id/sample_text"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:textIsSelectable="true"
        android:text="@string/sample_text"
        />

この背後にある仕組みについて言います。

アクションバーへのメニューの表示やメニュー選択時の動きは、アクションモード(Action Mode)という仕組みで実現されています。テキストが選択された場合、テキストビューは、アクションバーにメニューを表示するようアクションモードに処理を依頼します(図3)。

図3 [アクションモード]

 このようにして、テキスト選択時の動作は実現されていますが、テキスト選択時のメニューバーの表示位置の変更にあたって、このアクションモードという仕組みに手が入りました。具体的には、アクションモードにフローティング(浮かんでいる)という新たな種別が追加になりました。このフローティングタイプのアクションモードを動かすと、対象となる部品のすぐそばにメニューバーを表示することになります。一方、これまでのアクションバーへの表示は、プライマリ(基本的な、主な)という種別として新たに呼ばれるようになり、アクションモードを利用する場合には、この2種類を選べるようになったというわけです。

いろいろ試してみましたが、テキストビューをプライマリのアクションモードとして簡単に設定しなおす方法はなさそうです。プロジェクトによっては、これまでアクションバー(画面上部)に表示されていたメニューが、アンドロイドのバージョンを6.0にあげたことにより、テキストのそばに表示されるようになってしまい、仕様と違う動きになって困るところも出てくるかもしれません。将来的にはどちらも選べるようになってほしいですね。

■Floating Action Mode を使ってみる


実際に、フローティングアクションモード(Floating Action Mode)を使って何か作ってみます。

例えば、テキストを並べたリストに対して、フローティングアクションモードを使ってみましょう。
メニューバーに並べる項目は、追加、削除、共有の三つにしておきます。

[実行の様子1]

サンプルプログラムは、複数選択のリストビューに対して、アイテムをクリックしたときにフローティングアクションバーを表示するようにしています。そのとき、アクションバーを表示する場所が、選択したアイテムに被らないように、選択したアイテムをちょうど覆う矩形領域を計算してアクションモードに渡しています。[実行の様子1]の青い部分が、その矩形領域です。

では、コードの要点の説明です。

アクションモードを使用する場合は、ユーザーの何らかのアクションに対して、アクションされたViewのstartActionModeメソッドを呼ぶ必要があります。


    private class CustomItemClickedListener implements AdapterView.OnItemClickListener {

        @Override
        public void onItemClick(AdapterView parent, View view, int position, long id) {
            ListView listView = (ListView)parent;
            boolean hasChecked = false;
            Rect rect = new Rect();
            Rect sumRect = null;
            int firstVisiblePosition = listView.getFirstVisiblePosition();
            for (int i = 0; i < listView.getChildCount(); i++) {
                TextView textView = (TextView) listView.getChildAt(i);
                if (listView.isItemChecked(firstVisiblePosition + i)) {
                    hasChecked = true;
                    textView.getGlobalVisibleRect(rect);
                    if (sumRect != null) {
                        sumRect.union(rect);
                    }
                    else {
                        sumRect = new Rect(rect);
                    }
                }
            }

            mSumRect = getRectRelTo(sumRect, listView);

            if (hasChecked) {
                showSelectRegion(mSumRect);
                // MEMO: startActionModeは、呼び出しスレッドとは別のスレッドでActionModeのコールバックを呼び出す
                mActionMode = listView.startActionMode(new CustomActionModeCallback(), ActionMode.TYPE_FLOATING);
            }
            else {
                showSelectRegion(null);
                if (mActionMode != null) {
                    mActionMode.finish();
                }
            }
        }
    }
[コード1]は、リストのアイテムをクリックしたときの処理です。

74行目~91行目で表示されている選択項目を覆う矩形領域を求めています。ついでに、選択項目があるかどうかもここでチェックしています。ここで求めた矩形領域は、コード2の方で使用します。

93行目から103行目では、項目が選択されている場合は、上で求めた矩形領域を表示し、リストビューに対して、startActionModeメソッドをTYPE_FLOATINGで呼び出しています。アクションモードのタイプを指定しないタイプのstartActionModeメソッドは、APIレベル11のときから存在していましたが、タイプを指定するstartActionModeメソッドは、APIレベル23から追加されました。startActionModeは、ActionModeオブジェクトを返します。クリックした結果、選択項目がなくなった場合に、このActionModeのfinish()メソッドを呼び出して、フローティングアクションバーを消しています。矩形領域もついでに消しています。showSelectionRegionメソッドは、筆者が作ったプライベートメソッドで、計算でもとめた矩形領域を青い透過色で可視化するためにあります。実際には必要ではありません。

次のコードは、ActionModeのコールバックの実装です。

    private class CustomActionModeCallback extends ActionMode.Callback2 {

        @Override
        public void onGetContentRect(ActionMode mode, View view, Rect outRect) {
            outRect.set(mSumRect);
            mSumRect = null;
        }

        @Override
        public boolean onCreateActionMode(ActionMode mode, Menu menu) {
            menu.add(INSERT);
            menu.add(DELETE);
            menu.add(SHARE);
            return true;
        }

        @Override
        public boolean onPrepareActionMode(ActionMode mode, Menu menu) {
            return false;
        }

        @Override
        public boolean onActionItemClicked(ActionMode mode, MenuItem item) {
            if (item.getTitle().equals(INSERT)) {
                insertNewItem();
            }
            else if (item.getTitle().equals(DELETE)) {
                deleteSelection();
            }
            else if (item.getTitle().equals(SHARE)) {
                shareSelections();
            }
            mode.finish();
            showSelectRegion(null);
            return true;
        }

        @Override
        public void onDestroyActionMode(ActionMode mode) {
        }
    }
[コード2]で実装しているのは、startActionModeメソッドの引数に渡しているActionModeのコールバッククラスです。以前のActionModeのコールバックであるActionMode.Callbackは、インターフェースクラスでしたが、APIレベル23で追加されたこのActionMode.Callback2は、ActionMode.Callbackを実装するクラスとなっています。Callback2クラスは、

public void onGetContentRect(ActionMode mode, View view, Rect outRect)

というメソッドが実装されています。第一引数は、表示しているアクションモードが渡ってきます。第2引数のviewは、startActionModeが呼ばれたViewです。このプログラムの場合は、ListViewがわたってきます。第3引数は、アウト引数で、ここには領域を設定して返してあげます。この領域というのは、フローティングアクションバーがその周りに表示される領域のことです。ここはプログラマーが任意に指定することができます。ActionMode.Callback2のデフォルトの実装では、outRectには、viewの表示領域がそのまま渡されます。今回のプログラムの場合は、アイテムクリック時に計算した矩形領域をここで渡しています(111行目)。

ActionMode.Callback2のその他のメソッドは、ActionMode.Callbackから受け継いだもので、APIレベル23で追加されたメソッドではないので、ここでの説明は省きます。

細かい説明をだいぶ省きましたが、フローティングアクションモードは、矩形領域を計算して、onGetContentRectでアクションモードへ渡してやることがポイントとなります。どんな実装でもこの矩形領域を計算する部分が面倒になりそうです。

■まとめ


簡単ではありますが、Android 6.0 で導入されたテキスト選択の新仕様と、フローティングアクションモードの使い方をご紹介しました。まとめるとこんな感じです:

  • テキストビューは、テキストのそばにメニューが表示され便利になりましたが、以前のように画面上部には表示できなくなりました。
  • 開発者は、アクションバーを使う場合、画面上部のプライマリーにするのか、フローティングにするのかを考えないといけなくなりました。
  • フローティングアクションバーを使う場合は、矩形領域の計算で苦労すると思われます。
冒頭の写真は、いま流行のマシュマロコーヒーです。
今回のマシュマロ・アンドロイドでは、コーヒーに浮かぶマシュマロのような機能が一つ追加されたというわけです。

2015年10月1日木曜日



EPSON MOVERIO BT-200をモニターとしてお借りしておりましたが、半年間のモニター期間が終了してBT-200の返却期限が迫ってきました。

モニター終了と同時に、最後に「MOVERIO座談会」が開かれるということでエプソン様にご招待頂きましたので参加してまりました。その様子をご紹介致します。

また、ショートプレゼンの時間も頂けるとのことで、私が半年間BT-200を使ってみて、業務での利用を想定して感じたことを喋ってきました。

まずは、一番見たかったのはこれ!



そう、MOBERIO Pro BT-2000です!展示がありましたのでしっかり触ってきました!
装着感は良好で、視界もくっきり、鼻が痛くならない跳ね上げ式が好感でした。


業務用の大本命ではないかと個人的には思っているMOBERIO Pro BT-2000です。
屋外でも見やすくなっている、解像度も上がっているとのこと。
実際に掛けてみると、とにかく楽です。画面が大きいのに、頭で固定するから装着性が非常に高い!長時間かけていられるウェアラブルの形とは、これだ!という確信を得ましたね。

本当に、ウェアラブルを使った経験やBT-200を利用した経験がある方こそ、BT-2000の良さがわかるというものでしょう。

イベントではまずEPSON様から紹介がありました。3月からモニターとしてお借りしたBT-200のイベント振り返りと今後のイベントの紹介。
また6月に業務用モデルとしてBT-2000発表、お値段は30万円台で、9月17日に販売開始したとの事。
そしてBT-2000の開発で苦労した点として、
試作のコントローラーはバッテリーを大きくして長時間動作させ、さらに防塵防滴なので、「弁当箱か!」というぐらい大きくなってしまい、大きさと装着性のバランスをとるのに苦労した、といった話をお伺いできました。

さてBT-2000のポイントとして、私が気に入った点を列挙しておきます。

UIは、手袋をした状態でも操作しやすいようにボタンを作っている。大きめのボタンで設計されている。

バッテリーは2つ積んだ状態。だから電源を入れたまま1つずつ交換が可能!ホットスワップでバッテリー交換可能な訳です。この辺、業務利用をとことん考慮されていますね!

あとは、ディスプレイがフリップアップ機能(跳ね上げ式!)により、邪魔なときには跳ね上げて肉眼で見れる点!この機構はほんと素晴らしいと思います。

音声制御によるハンズフリー制御が可能。

なんと!ステレオカメラ!2台のカメラによりデプスセンシング(奥行きの取得)が出来るようになる。まだまだ精度は低いが、30cm、1mmの距離で。とのこと!

私のショートプレゼンでは業務利用でのウェアラブルの話をしてきました。内容は今まで単眼のウェアラブルディスプレイを業務に利用できないかといろいろ試してきましたが、技術的な問題ではなくて、単眼ウェアラブルの装着性はちょっと疑問視していました。
こんな小さなディスプレイで、本当に業務利用できるのか?
工場のおっちゃん、おばちゃんがつかってくれるのか?
で、行き着いたのが、BT-200や、もちろん弊社のMIRAMAもそうですが、両眼シースルータイプが、業務利用の可能性が一番高いと思う、その点、今回9月に発売とになったEPSON BT-2000はまさに理想の形、といった内容で話させて頂きました。30万円台で防水防滴。業務用としては良いところついてる気がします。












その後、モニター参加者からの色々な意見交換、ディスカッションを行い、発表をしました。内容は記載しませんが、BT-200を実際に半年間使ってみたからこその出た、次のウェアラブルデバイスへのアイディアが多く詰まっており、参加者である私としてもとても勉強になる内容となりました。



最後に、EPSON様からサプライズ。



なんと、返却予定だったMOVERIO BT-200ですが「モニター参加者の皆様に差し上げます」との事!EPSONさん太っ腹!ありがとうございます。

全体的に今回の座談会での収穫はBT-2000の出来がとても良い事を確認できたこと、ディスカッションで色々な意見を聞けたことですね。MOBERIO Pro BT-2000はウェアラブルを使った業務利用に活用できるものと期待しております。今後も研究開発を進めていきたいと思います。

[コラム]EPSON MOVERIO座談会に参加してショートプレゼンをしてきました



EPSON MOVERIO BT-200をモニターとしてお借りしておりましたが、半年間のモニター期間が終了してBT-200の返却期限が迫ってきました。

モニター終了と同時に、最後に「MOVERIO座談会」が開かれるということでエプソン様にご招待頂きましたので参加してまりました。その様子をご紹介致します。

また、ショートプレゼンの時間も頂けるとのことで、私が半年間BT-200を使ってみて、業務での利用を想定して感じたことを喋ってきました。

まずは、一番見たかったのはこれ!



そう、MOBERIO Pro BT-2000です!展示がありましたのでしっかり触ってきました!
装着感は良好で、視界もくっきり、鼻が痛くならない跳ね上げ式が好感でした。


業務用の大本命ではないかと個人的には思っているMOBERIO Pro BT-2000です。
屋外でも見やすくなっている、解像度も上がっているとのこと。
実際に掛けてみると、とにかく楽です。画面が大きいのに、頭で固定するから装着性が非常に高い!長時間かけていられるウェアラブルの形とは、これだ!という確信を得ましたね。

本当に、ウェアラブルを使った経験やBT-200を利用した経験がある方こそ、BT-2000の良さがわかるというものでしょう。

イベントではまずEPSON様から紹介がありました。3月からモニターとしてお借りしたBT-200のイベント振り返りと今後のイベントの紹介。
また6月に業務用モデルとしてBT-2000発表、お値段は30万円台で、9月17日に販売開始したとの事。
そしてBT-2000の開発で苦労した点として、
試作のコントローラーはバッテリーを大きくして長時間動作させ、さらに防塵防滴なので、「弁当箱か!」というぐらい大きくなってしまい、大きさと装着性のバランスをとるのに苦労した、といった話をお伺いできました。

さてBT-2000のポイントとして、私が気に入った点を列挙しておきます。

UIは、手袋をした状態でも操作しやすいようにボタンを作っている。大きめのボタンで設計されている。

バッテリーは2つ積んだ状態。だから電源を入れたまま1つずつ交換が可能!ホットスワップでバッテリー交換可能な訳です。この辺、業務利用をとことん考慮されていますね!

あとは、ディスプレイがフリップアップ機能(跳ね上げ式!)により、邪魔なときには跳ね上げて肉眼で見れる点!この機構はほんと素晴らしいと思います。

音声制御によるハンズフリー制御が可能。

なんと!ステレオカメラ!2台のカメラによりデプスセンシング(奥行きの取得)が出来るようになる。まだまだ精度は低いが、30cm、1mmの距離で。とのこと!

私のショートプレゼンでは業務利用でのウェアラブルの話をしてきました。内容は今まで単眼のウェアラブルディスプレイを業務に利用できないかといろいろ試してきましたが、技術的な問題ではなくて、単眼ウェアラブルの装着性はちょっと疑問視していました。
こんな小さなディスプレイで、本当に業務利用できるのか?
工場のおっちゃん、おばちゃんがつかってくれるのか?
で、行き着いたのが、BT-200や、もちろん弊社のMIRAMAもそうですが、両眼シースルータイプが、業務利用の可能性が一番高いと思う、その点、今回9月に発売とになったEPSON BT-2000はまさに理想の形、といった内容で話させて頂きました。30万円台で防水防滴。業務用としては良いところついてる気がします。












その後、モニター参加者からの色々な意見交換、ディスカッションを行い、発表をしました。内容は記載しませんが、BT-200を実際に半年間使ってみたからこその出た、次のウェアラブルデバイスへのアイディアが多く詰まっており、参加者である私としてもとても勉強になる内容となりました。



最後に、EPSON様からサプライズ。



なんと、返却予定だったMOVERIO BT-200ですが「モニター参加者の皆様に差し上げます」との事!EPSONさん太っ腹!ありがとうございます。

全体的に今回の座談会での収穫はBT-2000の出来がとても良い事を確認できたこと、ディスカッションで色々な意見を聞けたことですね。MOBERIO Pro BT-2000はウェアラブルを使った業務利用に活用できるものと期待しております。今後も研究開発を進めていきたいと思います。

2015年8月21日金曜日

[コラム]どうなった?Android Auto -アプリ公開編-

Related Posts Plugin for WordPress, Blogger...