Introduced in Android 4.0 (API level 14), an Android Application Record (AAR) provides a stronger certainty that your application is started when an NFC tag is scanned. An AAR has the package name of an application embedded inside an NDEF record. You can add an AAR to any NDEF record of your NDEF message, because Android searches the entire NDEF message for AARs. If it finds an AAR, it starts the application based on the package name inside the AAR. If the application is not present on the device, Google Play is launched to download the application.
AARs are useful if you want to prevent other applications from filtering for the same intent and potentially handling specific tags that you have deployed. AARs are only supported at the application level, because of the package name constraint, and not at the Activity level as with intent filtering. If you want to handle an intent at the Activity level, use intent filters.
If a tag contains an AAR, the tag dispatch system dispatches in the following manner:
Try to start an Activity using an intent filter as normal. If the Activity that matches the intent also matches the AAR, start the Activity.
If the Activity that filters for the intent does not match the AAR, if multiple Activities can handle the intent, or if no Activity handles the intent, start the application specified by the AAR.
If no application can start with the AAR, go to Google Play to download the application based on the AAR.
Note: You can override AARs and the intent dispatch system with the foreground dispatch system, which allows a foreground activity to have priority when an NFC tag is discovered. With this method, the activity must be in the foreground to override AARs and the intent dispatch system.
If you still want to filter for scanned tags that do not contain an AAR, you can declare intent filters as normal. This is useful if your application is interested in other tags that do not contain an AAR. For example, maybe you want to guarantee that your application handles proprietary tags that you deploy as well as general tags deployed by third parties. Keep in mind that AARs are specific to Android 4.0 devices or later, so when deploying tags, you most likely want to use a combination of AARs and MIME types/URIs to support the widest range of devices. In addition, when you deploy NFC tags, think about how you want to write your NFC tags to enable support for the most devices (Android-powered and other devices). You can do this by defining a relatively unique MIME type or URI to make it easier for applications to distinguish.
Android provides a simple API to create an AAR, createApplicationRecord(). All you need to do is embed the AAR anywhere in your NdefMessage. You do not want to use the first record of your NdefMessage, unless the AAR is the only record in the NdefMessage. This is because the Android system checks the first record of an NdefMessage to determine the MIME type or URI of the tag, which is used to create an intent for applications to filter. The following code shows you how to create an AAR:
NdefMessage msg = new NdefMessage(
new NdefRecord[] {
...,
NdefRecord.createApplicationRecord("com.example.android.beam")}
Beaming NDEF Messages to Other Devices
Android Beam allows simple peer-to-peer data exchange between two Android-powered devices. The application that wants to beam data to another device must be in the foreground and the device receiving the data must not be locked. When the beaming device comes in close enough contact with a receiving device, the beaming device displays the "Touch to Beam" UI. The user can then choose whether or not to beam the message to the receiving device.
Note: Foreground NDEF pushing was available at API level 10, which provides similar functionality to Android Beam. These APIs have since been deprecated, but are available to support older devices. See enableForegroundNdefPush() for more information.
You can enable Android Beam for your application by calling one of the two methods:
setNdefPushMessage(): Accepts an NdefMessage to set as the message to beam. Automatically beams the message when two devices are in close enough proximity.
setNdefPushMessageCallback(): Accepts a callback that contains a createNdefMessage() which is called when a device is in range to beam data to. The callback lets you create the NDEF message only when necessary.
An activity can only push one NDEF message at a time, so setNdefPushMessageCallback() takes precedence over setNdefPushMessage() if both are set. To use Android Beam, the following general guidelines must be met:
The activity that is beaming the data must be in the foreground. Both devices must have their screens unlocked.
You must encapsulate the data that you are beaming in an NdefMessage object.
The NFC device that is receiving the beamed data must support the com.android.npp NDEF push protocol or NFC Forum's SNEP (Simple NDEF Exchange Protocol). The com.android.npp protocol is required for devices on API level 9 (Android 2.3) to API level 13 (Android 3.2). com.android.npp and SNEP are both required on API level 14 (Android 4.0) and later.
Note: If your activity enables Android Beam and is in the foreground, the standard intent dispatch system is disabled. However, if your activity also enables foreground dispatching, then it can still scan tags that match the intent filters set in the foreground dispatching.
To enable Android Beam:
Create an NdefMessage that contains the NdefRecords that you want to push onto the other device.
Call setNdefPushMessage() with a NdefMessage or call setNdefPushMessageCallback passing in a NfcAdapter.CreateNdefMessageCallback object in the onCreate() method of your activity. These methods require at least one activity that you want to enable with Android Beam, along with an optional list of other activities to activate.
In general, you normally use setNdefPushMessage() if your Activity only needs to push the same NDEF message at all times, when two devices are in range to communicate. You use setNdefPushMessageCallback when your application cares about the current context of the application and wants to push an NDEF message depending on what the user is doing in your application.
The following sample shows how a simple activity calls NfcAdapter.CreateNdefMessageCallback in the onCreate() method of an activity (see AndroidBeamDemo for the complete sample). This example also has methods to help you create a MIME record:
package com.example.android.beam;
import android.app.Activity;
import android.content.Intent;
import android.nfc.NdefMessage;
import android.nfc.NdefRecord;
import android.nfc.NfcAdapter;
import android.nfc.NfcAdapter.CreateNdefMessageCallback;
import android.nfc.NfcEvent;
import android.os.Bundle;
import android.os.Parcelable;
import android.widget.TextView;
import android.widget.Toast;
import java.nio.charset.Charset;
public class Beam extends Activity implements CreateNdefMessageCallback {
NfcAdapter mNfcAdapter;
TextView textView;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
TextView textView = (TextView) findViewById(R.id.textView);
// Check for available NFC Adapter
mNfcAdapter = NfcAdapter.getDefaultAdapter(this);
if (mNfcAdapter == null) {
Toast.makeText(this, "NFC is not available", Toast.LENGTH_LONG).show();
finish();
return;
}
// Register callback
mNfcAdapter.setNdefPushMessageCallback(this, this);
}
@Override
public NdefMessage createNdefMessage(NfcEvent event) {
String text = ("Beam me up, Android!\n\n" +
"Beam Time: " + System.currentTimeMillis());
NdefMessage msg = new NdefMessage(
new NdefRecord[] { createMimeRecord(
"application/com.example.android.beam", text.getBytes())
/**
* The Android Application Record (AAR) is commented out. When a device
* receives a push with an AAR in it, the application specified in the AAR
* is guaranteed to run. The AAR overrides the tag dispatch system.
* You can add it back in to guarantee that this
* activity starts when receiving a beamed message. For now, this code
* uses the tag dispatch system.
*/
//,NdefRecord.createApplicationRecord("com.example.android.beam")
});
return msg;
}
@Override
public void onResume() {
super.onResume();
// Check to see that the Activity started due to an Android Beam
if (NfcAdapter.ACTION_NDEF_DISCOVERED.equals(getIntent().getAction())) {
processIntent(getIntent());
}
}
@Override
public void onNewIntent(Intent intent) {
// onResume gets called after this to handle the intent
setIntent(intent);
}
/**
* Parses the NDEF Message from the intent and prints to the TextView
*/
void processIntent(Intent intent) {
textView = (TextView) findViewById(R.id.textView);
Parcelable[] rawMsgs = intent.getParcelableArrayExtra(
NfcAdapter.EXTRA_NDEF_MESSAGES);
// only one message sent during the beam
NdefMessage msg = (NdefMessage) rawMsgs[0];
// record 0 contains the MIME type, record 1 is the AAR, if present
textView.setText(new String(msg.getRecords()[0].getPayload()));
}
/**
* Creates a custom MIME type encapsulated in an NDEF record
*/
public NdefRecord createMimeRecord(String mimeType, byte[] payload) {
byte[] mimeBytes = mimeType.getBytes(Charset.forName("US-ASCII"));
NdefRecord mimeRecord = new NdefRecord(
NdefRecord.TNF_MIME_MEDIA, mimeBytes, new byte[0], payload);
return mimeRecord;
}
}
Note that this code comments out an AAR, which you can remove. If you enable the AAR, the application specified in the AAR always receives the Android Beam message. If the application is not present, Google Play launches to download the application. Therefore, the following intent filter is not technically necessary for Android 4.0 devices or later if the AAR is used:
<intent-filter>
<action android:name="android.nfc.action.NDEF_DISCOVERED"/>
<category android:name="android.intent.category.DEFAULT"/>
<data android:mimeType="application/com.example.android.beam"/>
</intent-filter>
With this intent filter, the com.example.android.beam application now can be started when it scans an NFC tag or receives an Android Beam with an AAR of type com.example.android.beam, or when an NDEF formatted message contains a MIME record of type application/com.example.android.beam.
Even though AARs guarantee an application is started or downloaded, intent filters are recommended, because they let you start an Activity of your choice in your application instead of always starting the main Activity within the package specified by an AAR. AARs do not have Activity level granularity. Also, because some Android-powered devices do not support AARs, you should also embed identifying information in the first NDEF record of your NDEF messages and filter for that as well, just in case. See Creating Common Types of NDEF records for more information on how to create records.
2012年9月28日金曜日
Android 4.0 Platform NFC Basics/Beaming NDEF Messages to Other Devices
Android Beam は NFC ベースの機能で、NFC が利用可能な携帯端末を重ねることによって、ユーザが使用しているアプリに関する情報を即座に共有する機能です。範囲内にデバイスが存在する時ー数センチメートル以内でーシステムは NFC 接続を準備し、共有のための UI を表示します。見ている何かを他のデバイスと共有するには、ユーザはスクリーンをただタッチするだけです。
開発者にとって、Android Beam は殆ど全てのタイプの、接近に基づいたインタラクションを引き起こす新しい方法です。例えば、ユーザは連絡帳を即座に交換、マルチプレイヤーのゲームのセットアップ、チャットやテレビ電話への参加、写真やビデオの共有、などを行うことができます。システムは低レベルの NFC サポートと 共有のUI を提供する一方、フォアグラウンドのアプリは他のデバイスに転送するための軽量のデータを提供します。開発者は共有されるデータとそれがどのように取り扱われるかについて、完全に制御しているため、殆どのインタラクションが可能です。
もっと大きなペイロードについては、Android Beam を初回の接続として利用し、ユーザがペアリングを意識する必要なくBluetooth経由でデータを転送することができます。
開発者が Android Beam に基づくインタラクションに手を加えなくても、Android の中に深く統合された利益を享受することができる場合があります。デフォルトではシステムは アプリケーションの Android Market のURL を共有します。そのため、ユーザはすぐにアプリケーションのダウンロードまたは購入することが簡単にできます。
Android Beam (NDEF Push with NFC)の仕組み
Android Beam は あるデバイスから他へ NDEF メッセージを送信すること（この処理は "NDEFプッシュ" としても知られています）を可能とする新しい NFC の機能です。Android Beam をサポートする2台の Android デバイスが隣接（約4cm）し、通常は背面同士がタッチしている時、データ転送は初期化されます。NDEF メッセージの中のデータは、デバイス間で共有したいデータを含むことができます。例えば、連絡帳の共有、YouTubeの共有ビデオ、ブラウザによるURLの共有を行うアプリは Android Beam を使えます。
Android Beam を使ったデバイス間のデータの送信には、アクティビティがフォアグラウンドにある間に、共有したい情報を含む NdefMessage を生成する必要があります。次の2つの方法のうちのいずれかでシステムに対して NdefMessage を渡す必要があります：
アクティビティ中でプッシュする 単一の NdefMessage の定義：
メッセージを送りたい時に都度 setNdefPushMessage() を呼び出します。例えば、おそらく、アクティビティの onCreate() メソッドでこのメソッドを呼び出して、NdefMessage を渡すことでしょう。アクティビティがフォアグラウンドにいる間、 Android Beam が他のデバイスから活性化される場合は常に、システムは NdefMessage を他のデバイスに送信します。
Android Beam の初期化と同時にプッシュする NdefMessage の定義：
送りたい NdefMessage を返す createNdefMessage() メソッドの実装中に、NfcAdapter.CreateNdefMessageCallback を実装する。その時、NfcAdapter.CreateNdefMessageCallback を setNdefPushMessageCallback() の実装へ渡します。
このケースではアクティビティがフォアグラウンドにある間、他のデバイスから活性化された時、システムは送りたい NdefMessage を引き出すために createNdefMessage() を呼び出します。これは、メッセージのコンテンツがアクティビティの存在中に終始変化するかもしれないケースにおいて、初期化された Android Beam を一度だけ配信するために NdefMessage を定義することを許します。
システムによって他のデバイスへの NDEF メッセージの送信に成功した際に、特定のコードを処理したい場合は、NfcAdapter.OnNdefPushCompleteCallback を実装し、setNdefPushCompleteCallback() でセットすることができます。メッセージが配信された時、システムは onNdefPushComplete() を呼び出すでしょう。
デバイスの受信時、通常の NFC タグと同等の方法で NDEF プッシュメッセージを処理します。
システムはアクティビティを開始するために、ACTION_NDEF_DISCOVERED アクションとNdefMessage の 最初の NdefRecord に従って URL か MIME タイプのいずれかを設定して、インテントを起動します。アクティビティで反応させるために、対応したい URL か MIME タイプのインテントフィルタを定義することができます。詳細は NFC 開発者ガイドの Tag の処理についてを参照して下さい。
URL を NdefMessage で送りたい場合、文字列か Uri オブジェクトを元とした新しい NdefRecord を作成する createUri という便利なメソッドを使うことができます。URI が、Android Beam のイベント中受信するアプリケーションが特別なフォーマットであるという場合、送られてくる NDEF メッセージを受信するために、同一の URI スキームを使用するアクティビティのためのインテントフィルタを生成すべきです。
例え他のアプリケーションが同じインテントアクションをフィルタを処理するとしても、入ってくる NDEF メッセージをアプリケーションが処理することを保証するためには、NdefMessage と共に"Android アプリケーションレコード" も渡すようにすべきです。createApplicationRecord() を呼び出すことで Android アプリケーションレコード を生成することができ、アプリケーションのパッケージ名を渡すことができます。アプリケーションレコードと、特定のインテントを処理するアクティビティを含む複数のアプリケーションを伴う NDEF メッセージを他のデバイスで他のデバイスが受信した時、システムはいつも（アプリケーションレコードにマッチしたものに基づいた）アプリケーション中のアクティビティにメッセージを配信します。その際、ターゲットのデバイスにアプリケーションがインストールされていない場合、システムは Android マーケットを起動してユーザにアプリケーションをインストールさせるために Android application record を用います。
アプリケーションが NDEF プッシュメッセージを行うのに NFC API を使わない場合、その時は Android は標準の振る舞いを行います：あるデバイスのアプリケーションがフォアグラウンドにあり、他の Android デバイスから Android Beam が起動される時、他のデバイスは Android アプリケーションレコードとアプリケーションのID を含む NDEF メッセージを受信します。受信したデバイスにアプリケーションが既にインストールされている場合、システムはそれを起動します。インストールされていない場合は、Android マーケットが開き、インストールするためにユーザを案内します。
Android Beam と その他の NFC の機能について、NFC 基本 開発者ガイドを読むことができます。Android Beam を使ったサンプルコードは Android Beam デモを御覧ください。
Android Beam の詳細
Android Beam は、2つのAndroidデバイス間でシンプルなピア・ツー・ピアデータ交換を可能にします。他のデバイスへデータを送りたいアプリケーションは、フォアグラウンドにいて、且つ、データを受信するデバイスがロックされていないことが必要です。受信側のデバイスに接触するぐらい十分に送信するデバイスを近づけると、送信側のディスプレイに "Touch to Beam" UIが表示されます。ユーザーは受信側のデバイスにメッセージを受信するかどうかを選択することができます。
注意：フォアグラウンド NDEF プッシングは API レベル10から使用可能で、Android Beam と同様の機能を有します。これらの API 群は非推奨となりましたが、旧デバイスをサポートすることが可能です。詳細はenableForegroundNdefPush() をご覧下さい。
アプリケーションで Android Beam を有効にするために、次の2つのメソッドのうちいずれかを使用できます：
setNdefPushMessage()： 送信するメッセージをセットするためのNdefMessage を受け入れます。2つのデバイスが十分近くに隣接すると自動的にメッセージを送信します。
setNdefPushMessageCallback()：送信範囲内にデバイスが存在する時に呼び出されるcreateNdefMessage() を含むコールバックを受け入れます。コールバックは必要な時に限って、NDEF メッセージを生成させます。
アクティビティは、１度に１つの NDEF メッセージのみをプッシュすることが可能です。そのため、両方がセットされている時は、setNdefPushMessageCallback() は setNdefPushMessage() よりも優先されます。
Android Beam を使うためには、下記の一般的なガイドラインに従う必要があります：
データを送信するアクティビティはフォアグラウンドにある必要があります。両デバイス共にスクリーンはアンロック状態である必要があります。
NdefMessage オブジェクトに送信したいデータをカプセル化する必要があります。
送信されたデータを受信するNFC デバイスは、com.android.npp NDEF push protocol か、NFC フォーラムの SNEP(Simple NDEF Exchange Protocol) のいずれかをサポートする必要があります。com.android.npp プロトコルは API レベル9 (Android 2.3) から API レベル13 (Android 3.2) のデバイスが必要です。com.android.npp と SNEP の両方は API レベル14 (Android 4.0) 以降が必要です。
注意：Android Beam が使用可能なアクティビティがフォアグラウンドにある場合、標準的なインテントの処理は無効となります。しかし、アクティビティがフォアグラウンドで処理することもまた有効である場合、フォアグラウンド処理中にインテントフィルタにマッチするタグを引き続きスキャンする事ができます。
Android Beam を有効にするために：
他のデバイスへプッシュしたい NdefRecords を含んだ NdefMessage を生成します。
NdefMessage を含む setNdefPushMessage() を呼び出すか、アクティビティ中の onCreate() メソッドの中で NfcAdapter.CreateNdefMessageCallback オブジェクトが渡された setNdefPushMessageCallback を呼び出します。これらのメソッドは、活性化したい他のアクティビティのオプションのリストと共に、 Android Beam で有効にしたいアクティビティが少なくとも1つは必要です。
一般に、2つのデバイスがコミュニケーションする範囲内にある場合、アクティビティがいつも同じ NDEF メッセージをプッシュする必要があるだけである場合は、通常 setNdefPushMessage() を使います。アプリケーションが現在のアプリケーションのコンテキストを扱いたい時やユーザがアプリケーションに対して行っていることに依存する NDEF メッセージをプッシュしたい時は、setNdefPushMessageCallback を使います。
以下は アクティビティの onCreate() メソッド中で、NfcAdapter.CreateNdefMessageCallback を呼び出す単純なアクティビティをどのように実装するかの例です（完全なサンプルを御覧ください）。この例はまた MIME レコードの作り方も示しています：
package com.example.android.beam;
import android.app.Activity;
import android.content.Intent;
import android.nfc.NdefMessage;
import android.nfc.NdefRecord;
import android.nfc.NfcAdapter;
import android.nfc.NfcAdapter.CreateNdefMessageCallback;
import android.nfc.NfcEvent;
import android.os.Bundle;
import android.os.Parcelable;
import android.widget.TextView;
import android.widget.Toast;
import java.nio.charset.Charset;
public class Beam extends Activity implements CreateNdefMessageCallback {
NfcAdapter mNfcAdapter;
TextView textView;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
TextView textView = (TextView) findViewById(R.id.textView);
// 利用可能なNFC アダプタのチェック
mNfcAdapter = NfcAdapter.getDefaultAdapter(this);
if (mNfcAdapter == null) {
Toast.makeText(this, "NFC is not available", Toast.LENGTH_LONG).show();
finish();
return;
}
// コールバックを登録する
mNfcAdapter.setNdefPushMessageCallback(this, this);
}
@Override
public NdefMessage createNdefMessage(NfcEvent event) {
String text = ("Beam me up, Android!\n\n" +
"Beam Time: " + System.currentTimeMillis());
NdefMessage msg = new NdefMessage(
new NdefRecord[] { createMimeRecord(
"application/com.example.android.beam", text.getBytes())
/**
* Android Application Record(AAR)はコメントアウトされています。
* デバイスがAARを含むプッシュを受信した時、アプリケーションは
* 実行を保証するためにAARを指定します。AARはタグの処理システムをオーバーライドします。
* メッセージを受信した時にこのアクティビティが開始されることを保証するために、
* 後ろに追加することができます。今のところ、このコードはタグ処理
* システムを使っています。
*/
//,NdefRecord.createApplicationRecord("com.example.android.beam")
});
return msg;
}
@Override
public void onResume() {
super.onResume();
// アクティビティがAndroid Beamによって開始されたことをチェックする
if (NfcAdapter.ACTION_NDEF_DISCOVERED.equals(getIntent().getAction())) {
processIntent(getIntent());
}
}
@Override
public void onNewIntent(Intent intent) {
// インテントを処理するために、この後でonResumeが呼ばれる
setIntent(intent);
}
/**
* インテントからのNDEFメッセージのパースとTextViewへの表示
*/
void processIntent(Intent intent) {
textView = (TextView) findViewById(R.id.textView);
Parcelable[] rawMsgs = intent.getParcelableArrayExtra(
NfcAdapter.EXTRA_NDEF_MESSAGES);
// ビームの送信中は一つだけのメッセージ
NdefMessage msg = (NdefMessage) rawMsgs[0];
// 現在は、レコード0はMIMEタイプを含む、レコード1はAARを含む
textView.setText(new String(msg.getRecords()[0].getPayload()));
}
/**
* NDEFレコード内にカスタムMIMEタイプをカプセル化して生成する
*/
public NdefRecord createMimeRecord(String mimeType, byte[] payload) {
byte[] mimeBytes = mimeType.getBytes(Charset.forName("US-ASCII"));
NdefRecord mimeRecord = new NdefRecord(
NdefRecord.TNF_MIME_MEDIA, mimeBytes, new byte[0], payload);
return mimeRecord;
}
}
このコードはAARをコメントアウトしていますが、除去できることに注意して下さい。AARを有効にした場合、AAR中の特定のアプリケーションは常にAndroid Beam メッセージを受信します。アプリケーションが存在しない場合、Android Market がアプリケーションをダウンロードするために起動します。したがって、AAR が使われる場合、下記のインテントフィルタは Android 4.0 以降のデバイスでは技術的に必要ありません：
<intent-filter>
<action android:name="android.nfc.action.NDEF_DISCOVERED"/>
<category android:name="android.intent.category.DEFAULT"/>
<data android:mimeType="application/com.example.android.beam"/>
</intent-filter>
このインテントフィルタにより、 com.example.android.beam アプリケーションが NFC タグをスキャンした時やcom.example.android.beam 型のAARを伴うAndroid Beamを受信した時、または、NDEF フォーマットのメッセージが application/com.example.android.beam 型の MIME レコードを含んでいる時に、開始することができます。
例え AAR がアプリケーションの開始とダウンロードを保証していても、インテントフィルタは推奨されます。何故なら、AAR によって特定されたパッケージの範囲内にあるメインのアクティビティを常に開始する代わりに、アプリケーション中の開始するアクティビティを選択する余地を与えるためです。AAR はアクティビティレベルの保証は行いません。また、いくつかの Android 端末は AAR をサポートしないため、万が一のために、NDEF メッセージの最初の NDEF レコードに、IDの情報を埋め込み、同様にフィルターすべきです。レコードの生成方法に関する詳しい情報は、NDEF レコードの共通タイプの作成を御覧ください。
開発者にとって、Android Beam は殆ど全てのタイプの、接近に基づいたインタラクションを引き起こす新しい方法です。例えば、ユーザは連絡帳を即座に交換、マルチプレイヤーのゲームのセットアップ、チャットやテレビ電話への参加、写真やビデオの共有、などを行うことができます。システムは低レベルの NFC サポートと 共有のUI を提供する一方、フォアグラウンドのアプリは他のデバイスに転送するための軽量のデータを提供します。開発者は共有されるデータとそれがどのように取り扱われるかについて、完全に制御しているため、殆どのインタラクションが可能です。
もっと大きなペイロードについては、Android Beam を初回の接続として利用し、ユーザがペアリングを意識する必要なくBluetooth経由でデータを転送することができます。
開発者が Android Beam に基づくインタラクションに手を加えなくても、Android の中に深く統合された利益を享受することができる場合があります。デフォルトではシステムは アプリケーションの Android Market のURL を共有します。そのため、ユーザはすぐにアプリケーションのダウンロードまたは購入することが簡単にできます。
Android Beam (NDEF Push with NFC)の仕組み
Android Beam は あるデバイスから他へ NDEF メッセージを送信すること（この処理は "NDEFプッシュ" としても知られています）を可能とする新しい NFC の機能です。Android Beam をサポートする2台の Android デバイスが隣接（約4cm）し、通常は背面同士がタッチしている時、データ転送は初期化されます。NDEF メッセージの中のデータは、デバイス間で共有したいデータを含むことができます。例えば、連絡帳の共有、YouTubeの共有ビデオ、ブラウザによるURLの共有を行うアプリは Android Beam を使えます。
Android Beam を使ったデバイス間のデータの送信には、アクティビティがフォアグラウンドにある間に、共有したい情報を含む NdefMessage を生成する必要があります。次の2つの方法のうちのいずれかでシステムに対して NdefMessage を渡す必要があります：
アクティビティ中でプッシュする 単一の NdefMessage の定義：
メッセージを送りたい時に都度 setNdefPushMessage() を呼び出します。例えば、おそらく、アクティビティの onCreate() メソッドでこのメソッドを呼び出して、NdefMessage を渡すことでしょう。アクティビティがフォアグラウンドにいる間、 Android Beam が他のデバイスから活性化される場合は常に、システムは NdefMessage を他のデバイスに送信します。
Android Beam の初期化と同時にプッシュする NdefMessage の定義：
送りたい NdefMessage を返す createNdefMessage() メソッドの実装中に、NfcAdapter.CreateNdefMessageCallback を実装する。その時、NfcAdapter.CreateNdefMessageCallback を setNdefPushMessageCallback() の実装へ渡します。
このケースではアクティビティがフォアグラウンドにある間、他のデバイスから活性化された時、システムは送りたい NdefMessage を引き出すために createNdefMessage() を呼び出します。これは、メッセージのコンテンツがアクティビティの存在中に終始変化するかもしれないケースにおいて、初期化された Android Beam を一度だけ配信するために NdefMessage を定義することを許します。
システムによって他のデバイスへの NDEF メッセージの送信に成功した際に、特定のコードを処理したい場合は、NfcAdapter.OnNdefPushCompleteCallback を実装し、setNdefPushCompleteCallback() でセットすることができます。メッセージが配信された時、システムは onNdefPushComplete() を呼び出すでしょう。
デバイスの受信時、通常の NFC タグと同等の方法で NDEF プッシュメッセージを処理します。
システムはアクティビティを開始するために、ACTION_NDEF_DISCOVERED アクションとNdefMessage の 最初の NdefRecord に従って URL か MIME タイプのいずれかを設定して、インテントを起動します。アクティビティで反応させるために、対応したい URL か MIME タイプのインテントフィルタを定義することができます。詳細は NFC 開発者ガイドの Tag の処理についてを参照して下さい。
URL を NdefMessage で送りたい場合、文字列か Uri オブジェクトを元とした新しい NdefRecord を作成する createUri という便利なメソッドを使うことができます。URI が、Android Beam のイベント中受信するアプリケーションが特別なフォーマットであるという場合、送られてくる NDEF メッセージを受信するために、同一の URI スキームを使用するアクティビティのためのインテントフィルタを生成すべきです。
例え他のアプリケーションが同じインテントアクションをフィルタを処理するとしても、入ってくる NDEF メッセージをアプリケーションが処理することを保証するためには、NdefMessage と共に"Android アプリケーションレコード" も渡すようにすべきです。createApplicationRecord() を呼び出すことで Android アプリケーションレコード を生成することができ、アプリケーションのパッケージ名を渡すことができます。アプリケーションレコードと、特定のインテントを処理するアクティビティを含む複数のアプリケーションを伴う NDEF メッセージを他のデバイスで他のデバイスが受信した時、システムはいつも（アプリケーションレコードにマッチしたものに基づいた）アプリケーション中のアクティビティにメッセージを配信します。その際、ターゲットのデバイスにアプリケーションがインストールされていない場合、システムは Android マーケットを起動してユーザにアプリケーションをインストールさせるために Android application record を用います。
アプリケーションが NDEF プッシュメッセージを行うのに NFC API を使わない場合、その時は Android は標準の振る舞いを行います：あるデバイスのアプリケーションがフォアグラウンドにあり、他の Android デバイスから Android Beam が起動される時、他のデバイスは Android アプリケーションレコードとアプリケーションのID を含む NDEF メッセージを受信します。受信したデバイスにアプリケーションが既にインストールされている場合、システムはそれを起動します。インストールされていない場合は、Android マーケットが開き、インストールするためにユーザを案内します。
Android Beam と その他の NFC の機能について、NFC 基本 開発者ガイドを読むことができます。Android Beam を使ったサンプルコードは Android Beam デモを御覧ください。
Android Beam の詳細
Android Beam は、2つのAndroidデバイス間でシンプルなピア・ツー・ピアデータ交換を可能にします。他のデバイスへデータを送りたいアプリケーションは、フォアグラウンドにいて、且つ、データを受信するデバイスがロックされていないことが必要です。受信側のデバイスに接触するぐらい十分に送信するデバイスを近づけると、送信側のディスプレイに "Touch to Beam" UIが表示されます。ユーザーは受信側のデバイスにメッセージを受信するかどうかを選択することができます。
注意：フォアグラウンド NDEF プッシングは API レベル10から使用可能で、Android Beam と同様の機能を有します。これらの API 群は非推奨となりましたが、旧デバイスをサポートすることが可能です。詳細はenableForegroundNdefPush() をご覧下さい。
アプリケーションで Android Beam を有効にするために、次の2つのメソッドのうちいずれかを使用できます：
setNdefPushMessage()： 送信するメッセージをセットするためのNdefMessage を受け入れます。2つのデバイスが十分近くに隣接すると自動的にメッセージを送信します。
setNdefPushMessageCallback()：送信範囲内にデバイスが存在する時に呼び出されるcreateNdefMessage() を含むコールバックを受け入れます。コールバックは必要な時に限って、NDEF メッセージを生成させます。
アクティビティは、１度に１つの NDEF メッセージのみをプッシュすることが可能です。そのため、両方がセットされている時は、setNdefPushMessageCallback() は setNdefPushMessage() よりも優先されます。
Android Beam を使うためには、下記の一般的なガイドラインに従う必要があります：
データを送信するアクティビティはフォアグラウンドにある必要があります。両デバイス共にスクリーンはアンロック状態である必要があります。
NdefMessage オブジェクトに送信したいデータをカプセル化する必要があります。
送信されたデータを受信するNFC デバイスは、com.android.npp NDEF push protocol か、NFC フォーラムの SNEP(Simple NDEF Exchange Protocol) のいずれかをサポートする必要があります。com.android.npp プロトコルは API レベル9 (Android 2.3) から API レベル13 (Android 3.2) のデバイスが必要です。com.android.npp と SNEP の両方は API レベル14 (Android 4.0) 以降が必要です。
注意：Android Beam が使用可能なアクティビティがフォアグラウンドにある場合、標準的なインテントの処理は無効となります。しかし、アクティビティがフォアグラウンドで処理することもまた有効である場合、フォアグラウンド処理中にインテントフィルタにマッチするタグを引き続きスキャンする事ができます。
Android Beam を有効にするために：
他のデバイスへプッシュしたい NdefRecords を含んだ NdefMessage を生成します。
NdefMessage を含む setNdefPushMessage() を呼び出すか、アクティビティ中の onCreate() メソッドの中で NfcAdapter.CreateNdefMessageCallback オブジェクトが渡された setNdefPushMessageCallback を呼び出します。これらのメソッドは、活性化したい他のアクティビティのオプションのリストと共に、 Android Beam で有効にしたいアクティビティが少なくとも1つは必要です。
一般に、2つのデバイスがコミュニケーションする範囲内にある場合、アクティビティがいつも同じ NDEF メッセージをプッシュする必要があるだけである場合は、通常 setNdefPushMessage() を使います。アプリケーションが現在のアプリケーションのコンテキストを扱いたい時やユーザがアプリケーションに対して行っていることに依存する NDEF メッセージをプッシュしたい時は、setNdefPushMessageCallback を使います。
以下は アクティビティの onCreate() メソッド中で、NfcAdapter.CreateNdefMessageCallback を呼び出す単純なアクティビティをどのように実装するかの例です（完全なサンプルを御覧ください）。この例はまた MIME レコードの作り方も示しています：
package com.example.android.beam;
import android.app.Activity;
import android.content.Intent;
import android.nfc.NdefMessage;
import android.nfc.NdefRecord;
import android.nfc.NfcAdapter;
import android.nfc.NfcAdapter.CreateNdefMessageCallback;
import android.nfc.NfcEvent;
import android.os.Bundle;
import android.os.Parcelable;
import android.widget.TextView;
import android.widget.Toast;
import java.nio.charset.Charset;
public class Beam extends Activity implements CreateNdefMessageCallback {
NfcAdapter mNfcAdapter;
TextView textView;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
TextView textView = (TextView) findViewById(R.id.textView);
// 利用可能なNFC アダプタのチェック
mNfcAdapter = NfcAdapter.getDefaultAdapter(this);
if (mNfcAdapter == null) {
Toast.makeText(this, "NFC is not available", Toast.LENGTH_LONG).show();
finish();
return;
}
// コールバックを登録する
mNfcAdapter.setNdefPushMessageCallback(this, this);
}
@Override
public NdefMessage createNdefMessage(NfcEvent event) {
String text = ("Beam me up, Android!\n\n" +
"Beam Time: " + System.currentTimeMillis());
NdefMessage msg = new NdefMessage(
new NdefRecord[] { createMimeRecord(
"application/com.example.android.beam", text.getBytes())
/**
* Android Application Record(AAR)はコメントアウトされています。
* デバイスがAARを含むプッシュを受信した時、アプリケーションは
* 実行を保証するためにAARを指定します。AARはタグの処理システムをオーバーライドします。
* メッセージを受信した時にこのアクティビティが開始されることを保証するために、
* 後ろに追加することができます。今のところ、このコードはタグ処理
* システムを使っています。
*/
//,NdefRecord.createApplicationRecord("com.example.android.beam")
});
return msg;
}
@Override
public void onResume() {
super.onResume();
// アクティビティがAndroid Beamによって開始されたことをチェックする
if (NfcAdapter.ACTION_NDEF_DISCOVERED.equals(getIntent().getAction())) {
processIntent(getIntent());
}
}
@Override
public void onNewIntent(Intent intent) {
// インテントを処理するために、この後でonResumeが呼ばれる
setIntent(intent);
}
/**
* インテントからのNDEFメッセージのパースとTextViewへの表示
*/
void processIntent(Intent intent) {
textView = (TextView) findViewById(R.id.textView);
Parcelable[] rawMsgs = intent.getParcelableArrayExtra(
NfcAdapter.EXTRA_NDEF_MESSAGES);
// ビームの送信中は一つだけのメッセージ
NdefMessage msg = (NdefMessage) rawMsgs[0];
// 現在は、レコード0はMIMEタイプを含む、レコード1はAARを含む
textView.setText(new String(msg.getRecords()[0].getPayload()));
}
/**
* NDEFレコード内にカスタムMIMEタイプをカプセル化して生成する
*/
public NdefRecord createMimeRecord(String mimeType, byte[] payload) {
byte[] mimeBytes = mimeType.getBytes(Charset.forName("US-ASCII"));
NdefRecord mimeRecord = new NdefRecord(
NdefRecord.TNF_MIME_MEDIA, mimeBytes, new byte[0], payload);
return mimeRecord;
}
}
このコードはAARをコメントアウトしていますが、除去できることに注意して下さい。AARを有効にした場合、AAR中の特定のアプリケーションは常にAndroid Beam メッセージを受信します。アプリケーションが存在しない場合、Android Market がアプリケーションをダウンロードするために起動します。したがって、AAR が使われる場合、下記のインテントフィルタは Android 4.0 以降のデバイスでは技術的に必要ありません：
<intent-filter>
<action android:name="android.nfc.action.NDEF_DISCOVERED"/>
<category android:name="android.intent.category.DEFAULT"/>
<data android:mimeType="application/com.example.android.beam"/>
</intent-filter>
このインテントフィルタにより、 com.example.android.beam アプリケーションが NFC タグをスキャンした時やcom.example.android.beam 型のAARを伴うAndroid Beamを受信した時、または、NDEF フォーマットのメッセージが application/com.example.android.beam 型の MIME レコードを含んでいる時に、開始することができます。
例え AAR がアプリケーションの開始とダウンロードを保証していても、インテントフィルタは推奨されます。何故なら、AAR によって特定されたパッケージの範囲内にあるメインのアクティビティを常に開始する代わりに、アプリケーション中の開始するアクティビティを選択する余地を与えるためです。AAR はアクティビティレベルの保証は行いません。また、いくつかの Android 端末は AAR をサポートしないため、万が一のために、NDEF メッセージの最初の NDEF レコードに、IDの情報を埋め込み、同様にフィルターすべきです。レコードの生成方法に関する詳しい情報は、NDEF レコードの共通タイプの作成を御覧ください。
VirtualBoxにAndroid-x86をインストールしてEclipseからデバッグに使う方法
環境が整ったので少しずつコードを書いたりしてるわけですが、デバッグに使っているAndroidのエミュレータが遅いんですよね。作業が終わるまでは立ち上げっぱなしなので、起動の遅さはまあ許せるんですが、処理自体が遅いのはちょっといただけません。
何か良い方法は無いのかと思ってネットを徘徊しまくってた訳ですが、そこで思い出したのがx86用のAndroid。Androidのアプリはその仕組み上、CPUにほとんど(NDKを使ってネイティブコードを書かない限り)依存しないのでこんなものが作られている訳ですが、仮想PCソフトでx86バイナリのAndroidを動かせば、AVD(ARMのエミュレータ)上でARMバイナリのAndroidを動かすよりは軽くなるはず。見てみると3週間ほど前にAndroid 2.2(Froyo)が公開されていて良い感じです。
ということで、VirtualBoxにインストールしたAndroid-x86を、adbツールやEclipse＋ADT(DDMS)からデバイスとして使えるように仕立ててみたので、その方法をば。なお、例によって手順が多いので省けるところは省いてサクサク行きます。
- Android-x86のダウンロード
Android-x86 - Porting Android to x86のDownloadのページからStableReleaseのAndroid-x86 2.2 live & installation isoのgeneric版(android-x86-2.2-generic.iso)をダウンロードしておきます。この時点ではまだ使いません。 - VirtualBoxのインストール
VirtualBox.orgのDownload VirtualBoxのページからVirtualBox 4.0.2のWindows版(VirtualBox-4.0.2-69518-Win.exe)をダウンロード。インストーラーを起動して、[Next]→[Next]→[Next]→[Yes]→[Install]でインストールを開始します。インストール中、[ソフトウェアのインストール]と[ハードウェアのインストール]のダイアログが合わせて10回以上出てくるので(苦笑)、すべて[続行(C)]で進めて、最後に[Finish]でインストーラーを終了させます。 - VirtualBoxの設定変更
インストーラーと入れ替わりに[Oracle VM VirtualBox マネージャー]が起動するので、VirtualBoxをVirtualPCっぽく使うために設定を行います。そのままで良いという人は、この項目はスキップして構わないです。VirtualBoxをAndroid-x86にしか使わないなら、ホットキーは標準の右[Ctrl]のままのほうが使いやすいかもしれません。
[Oracle VM VirtualBox マネージャー]のメニューから[ファイル(F)]→[環境設定(P)...]と選んで[VirtualBox ー 設定]ダイアログを開きます。開いたら、[一般]→[デフォルト 仮想マシン フォルダ]から[その他...]→[フォルダの参照]ダイアログを開く→"マイドキュメント"を選ぶ→[新しいフォルダの作成(M)]で"VirtualBox VMs"フォルダを作成する→[OK]として、仮想PCをマイドキュメント以下の"VirtualBox VMs"フォルダに置くように変更します。加えて[入力]→[ホストキー(K)]をクリック→右[Alt]キーとして、ホストキーの設定を変更し、[OK(O)]でダイアログを閉じて[Oracle VM VirtualBox マネージャー]に戻ります。
なお、ホットキーは仮想マシンのウインドウの右下に表示されています。仮想マシンからマウスやキーボードを開放したり、仮想マシンのハードウェア操作をするために使うキーなので、覚えておいてください。 - 新規仮想マシンの作成
[新規(N)]で[新規仮想マシンの作成]ダイアログ(新規仮想マシン作成ウィザード)を開き[次へ(N)]、[名前(A)]に"Android-x86"と入力し、[オペレーティングシステム(S)]を[Linux]に、[バージョン]を[Linux 2.6]に変更します。変更したら[次へ(N)]→[次へ(N)]→[次へ(N)]→[次へ(N)]→[次へ(N)]→[サイズ]を1GBに変更→[次へ(N)]→[完了(F)]→[完了(F)]として、1GBのハードディスク(内蔵ストレージ相当)を持つ仮想マシンを作成します。
ちなみにシステムデータの容量は200MB程度ですので、内蔵ストレージは一応256MBあればインストール可能です。ただ、それだとギリギリすぎるのでオススメしませんが……。大きくする分には特に制限はありません。 - 仮想マシンの設定
出来上がった[Android-x86]を選んで[設定(S)]で[Android-x86 - 設定]ダイアログを開き、以下の設定を行います。終わったら[OK(O)]でダイアログを閉じましょう。- [一般]→[高度(A)]タブ→[クリップボードの共有(S)]を[無効]に
- [システム]→[マザーボード(M)]タブ→[IO APICを有効化(I)]をONに、[絶対座標指定のデバイスを有効化(A)]をOFFに
- [ディスプレイ]→[ビデオ(V)]タブ→[ビデオメモリ(M)]を8MBに
- [ストレージ]→[IDEコントローラ]の下の[空]を選択→[CD/DVDドライブ(D)]の右にあるCDのアイコンをクリック→[仮想CD/DVDディスクファイルの選択]として[仮想CD/DVDディスクファイルの選択]ダイアログを開き、ダウンロードしておいたandroid-x86-2.2-generic.isoを選択して[開く(O)]で、仮想CDドライブの中にisoイメージを挿入
- [ストレージ]→[SATA コントローラ]を右クリック→[ハードディスクを追加]→[VirtualBox - 質問]ダイアログに対して[新規ディスクの作成(N)]として[新規ディスクの作成]ダイアログ(新規仮想ディスク作成ウィザード)を開く→[次へ(N)]→[次へ(N)]→[サイズ]を8GBに、[場所(L)]を"sdcard.vdi"に変更→[次へ(N)]→[完了(F)]として8GBのハードディスク(SDカード相当)を追加
- [ネットワーク]→[アダプタ 1]タブ→[割り当て(A)]を[ホストオンリー アダプタ]に→[高度(D)]→[アダプタタイプ(T)]を[PCnet-FAST III (Am79C973)]に
- [USB]→[USB コントローラを有効化(U)]をOFFに
- 仮想マシンの起動とAndroid-x86のインストール
[Android-x86]を選んで[起動(T)]で仮想マシンを起動したら、仮想マシンの画面をクリックして仮想マシンに入り、仮想マシン内のインストール画面(Linuxベース)を操作します。
[GNU GRUB]のメニューで[Installation Android-x86 to harddisk]を選んで[Enter]を押し、青いバックに灰色のメニューが出たところで[Alt]＋[F2]を押します。真っ黒い画面に切り替わるので、"cfdisk /dev/sdb"と入力して[Enter]でcfdiskユーティリティを起動し、[n]→[p]→[Enter]→[t]→[Enter]→"0c"と入力して[Enter]→[W](大文字)→"yes"と入力して[Enter]→[q]で、cfdiskユーティリティを終了します。
[Alt]＋[F1]で元の画面に戻り、メニューから[Create/Modify partitions]を選んで[Enter]。またcfdiskユーティリティが起動するので、今度は[n]→[p]→[Enter]→[b]→[W](大文字)→"yes"と入力して[Enter]→[q]。
メニューに戻ってくるので、一番上の[sda1 Linux VBOX HARDDISK]を選択し[Enter]→[ext3]を選択して[Enter]→[y]としてフォーマットを行い、[y]→[y]としてインストールを開始します。インストールが終わって[Congratulations!]というメニューが開いたら、ホストキーを押して仮想マシンから抜け、仮想マシンのメニューから[デバイス(D)]→[CD/DVD デバイス(C)]→[仮想ドライブからディスクを除去]と選び、[VirtualBox - 質問]のダイアログには[強制マウント解除]としてisoイメージを仮想CDドライブから取り出します。取り出したら仮想マシンに戻り、メニューから[Reboot]を選んで[Enter]で仮想マシンをリセットします。リセット後に放っておくと勝手にAndroidが起動してしまうので、この後の[GNU GRUB]のメニューでの操作は素早く行ってください。 - Android-x86の起動設定変更
[GNU GRUB]のメニューで[Android-x86 2.2 (Debug mode)]を選んで[Enter]を押し、テキスト画面のスクロールが止まって"(debug-found)@android:/android #"と表示されたら、"vi /mnt/grub/menu.lst"と入力して[Enter]で、viエディタ*1でファイルを開きます。7行目のkernelで始まる行の最後に" vga=788 SDCARD=/dev/sdb"を、11行目の同じくkernelで始まる行の最後に" vga=785 SDCARD=/dev/sdb"を書き加えてセーブしviエディタを抜けます*2。なお、システムの認識が英語キーボードなので、そのままではいくつかのキーが入力できません。"="(イコール)は[^]キー([Back space]キーの2つ左)で、":"(コロン)は[Shift]＋[;](セミコロン)キーで入力してください。viエディタを抜けたら"exit"と入力し[Enter]として、ウインドウが広がって文字のスクロールが止まったら、ホストキー＋[R]を押して仮想マシンをリセットします。 - VirtualBoxネットワークブリッジの設定
仮想マシンのウインドウは開いたままで、[スタート]→[接続(T)]→[すべての接続の表示(S)]と選んで、[ネットワーク接続]のウインドウを開き、[Ctrl]キーを押しながら[VirtualBox Host-Only Network]と普段使っているネットワーク([ローカルエリア接続]など)の2つを選択し、右クリック→[ブリッジ接続(G)]を選びます。[ハードウェアのインストール]ダイアログには[続行(C)]として進め、しばらく待って[ネットワーク接続]のウインドウの中に[ネットワークブリッジ]という項目が増えたら、ウインドウを閉じます。 - Android-x86のIPアドレス設定
仮想マシンに入り、ホーム画面のランチャーアイコンから、[Settings]→[Ethernet configuration]→[Ethernet configuration]と選んで[Configure Ethernet device]ダイアログを開き、自分のネットワークに合わせてIPアドレスを設定します。固定IPアドレスを指定した場合は、あとで使うのでIPアドレスをメモしておきます。 - Android-x86の環境設定
ランチャーアイコンから、[Settings]→[SD card & phone storage]→[Format SD card]→[Format SD card]→[Erase everything]→[Mount SD card]としてSDカードをフォーマットしてからマウントします。[Esc]キー→[Language & Keyboard]→[Select language]→[Japanese]として日本語環境へ切り替え、[Keybord layout setting]→[Japanese]でキーボード設定も日本語キーボードに変更します。後の入力で邪魔になるので、[Esc]キー→中国語IME(谷歌なんたら(苦笑))のチェックをOFFにして無効にし、さらに[Esc]キー→[日付と時刻]→[自動]のチェックを外す→[タイムゾーンの選択]→[日本標準時(東京)]としてタイムゾーン設定も変更します。終わったら、ホストキー＋[H]を押して[携帯電話オプション]ダイアログを出し、[Reboot]→[OK]で仮想マシンを再起動します。 - システム情報アプリのインストールとIPアドレス確認
IPアドレスをDHCP設定にした場合にはIPアドレスを調べる必要があるので、システム情報アプリをインストールします。固定IPを設定した場合には、この項目はスキップして構いません。
ランチャーアイコン→[App Store]→虫眼鏡アイコンと選び、"system info"と入力して[Enter]で検索すると候補が2つ出るので、[Quick System Info PRO]の方を選んでインストールします。インストールしたら起動して、[Basic Info]の[Network]の項目にあるIPアドレスをメモしておきます。 - adbサーバと仮想マシンの接続
adbツールを使うので、Android SDKのツールフォルダ(以前のインストール例なら"C:\Android\sdk\tools"と"C:\Android\sdk\platform-tools")にパスを通します。
コマンドプロンプトを開き、パスが通っているのを確認したら、"adb connect <メモしておいたIPアドレス>"と入力します。"connected to <メモしておいたIPアドレス>:<数字>"と表示されたら成功。"adb devices"でデバイスが増えているのを確認してください。これでエミュレータや実機と同様にEclipseからコントロールできるようになります。
使い終わったら"adb disconnect <メモしておいたIPアドレス>"(もしくはIPアドレス無しで全部一括)で接続を切断することが出来ます。なお、仮想マシン側を再起動したりするとデバイスとして認識しなくなりますが、その場合は一旦disconnectして、再度connectすると直ります。 - (おまけ)日本語IME「Simeji」のインストール
throw Life - x86で動くSimejiのページからSimeji3.A.3_x86.apkをダウンロードしてきます。コマンドプロンプトでダウンロードしたapkのあるフォルダに移動し(もちろん仮想マシンも起動してadb接続を済ませておきます)、"adb -s <接続した際に表示されたデバイス名> install Simeji3.A.3_x86.apk"としてインストールします。インストール出来たら仮想マシンに入り、ランチャーアイコン→[Simeji]で表示される手順に従ってSimejiを有効にすれば完了です。
何気に開発環境のインストールより長い解説になりましたが、これでAVDの代わりにVirtualBox＋Android-x86のエミュレータを使うことが出来ます。AVDのように自動的に起動＆接続をしてくれたり、画面の向きに合わせて回転してくれたりはしませんが、起動は20秒くらい(AthlonX2 2.2GHzの場合)で終わるので、接続の手間を考えてもまだ早いですし、アプリの動作速度も実機のIS01以上です。まあ、信頼性の面で言えばハテナマークが付いてしまうのですが、趣味のプログラムを確認するくらいなら充分でしょう。
今回Android-x86の起動設定ファイル(正確にはブートローダーGRUBの設定ファイル)に加えた修正では、(HDPI)を選ぶと800×600・240dpiの解像度で、(MDPI)を選ぶと640×480・160dpiの解像度で、それぞれAndroidが起動します。kernelの行の"DPI="がそのままDPI値に、"vga="が画面モード(VESAの画面モード番号でLinuxのブートローダーでは一般的な数字らしい)になっているので、viを駆使して書き換えれば、色々な解像度の環境を設定することができます。GRUBの機能を利用して起動時に一時的にパラメータを変更する事もできるので、試すだけならもうちょっと楽に出来るでしょう。
ちなみに、Android-x86ではキーボードで色々と操作が出来るので、うまく利用すれば便利です。[Esc]キーで戻るボタン相当なのは今回の説明でも多用してますし、アプリケーションキーでMENU、左[Windows]キーでホーム、[F3]キーで通話、[F4]キーで終話、[F6]キーで電源というのは確認できました。あと、マウスの右クリックにも戻る機能があるので、マウスを使っている場合にはサクサクと行き来ができます。スクロールホイールは動きからすると多分、トラックボール扱いなんじゃないかなと。
今回設定した環境では、SDカード相当のハードディスクを分離してあるので、.vdiファイルの中身にアクセスするツールを使えば、エミュレータに関係なくファイルを出し入れできます。イメージはFAT32でフォーマットされているので、Android-x86以外にWindowsの動く仮想マシンがあれば、その仮想マシンにハードディスクイメージを繋ぎ替えることで、中身にアクセスすることもできるでしょう。
2012年9月27日木曜日
106SHのroot取得まとめ
※この作業は自己責任でお願いします。俺が成功しただけであってあなたが成功するとは限りませんのであしからず。
ISW16SHのrootスレの手順で問題なく進められる。
1．goroh_kun氏のsystem権限でシェルスクリプトを動かすツール実験版
/dataと/cacheのパーミッションが777になる。
2．goroh_kun氏のほぼすべての端末でsystem権限⇒root取得できてしまうすごい(ひどい？)やつ
※readmeには書かれていないがonload.sh実行前に
adb shell chmod 777 /data/local/tmp/mkdevsh
でmkdevshのパーミッションを777にしておく。
onload.shでroot取得(/dev/sh)
3．ISW16SHのrootスレ71氏のrootkit
isw16sh_unlock実行直前までは問題ない(/dev/suでのroot)。
現状ではここまで。
素人なのでStickyBitとかmmapとかよくわからない。
でもその辺分かる人がISW16SHのrootスレ眺めればこの先は簡単なのだとは思ってる。
あと、onload.shのsystem権限での実行はエラーが出ていないときは処理前だと思った方がいい。
エラーが出た後は望んだ結果になってるはず（環境によっては時間がかかる）。
※onload.shのsystem権限での実行＝設定アプリからSDカードのアンマウント
神降臨待ち。
2012/8/21追記
goroh_kun氏の協力によりMIYABI解除成功。アップデート後もroot1維持できてる。
まとめるのでしばし待たれよ皆の衆。
2012/8/21更に追記
このファイルを3のファイルと差し替える。
めでたくMIYABI解除してreadme通り作業できるはず。
goroh_kun氏ならびにISW16SHrootスレの71氏に感謝！
環境作りに協力してくれたレゴの人にも感謝！
Android ICSをVirtualBoxで動かす
1. SDカードが利用できるAndroid ICSのVirtualBox向けイメージのダウンロード
Testing Android-x86 Ice Cream Sandwich-Image from VMLiteのページで、for free downloadのリンクをクリックして、Android-v4.7zをダウンロード。これに含まれるVirtualBox向けハードディスクイメージは、マウス、ネットワーク、SDカードが利用できます。
2. 展開
Ubuntuでは
$ 7z x Android-v4.7z
3. VirtualBoxで仮想マシン作成
OSタイプで、オペレーティングシステムをLinux、バージョンをOther Linuxにして、次へボタンを押す。メモリは適宜設定。仮想ハードディスク作成画面のときに、仮想マシンを置くディレクトリに、2で展開して得られたAndroid-v4ディレクトリの中身のうち、拡張子がvdiのVirtualBox仮想ディスクイメージファイルをコピー。起動ディスクの設定で、既存のハードディスクを使用をチェックして、Android-v4.vdiを選択。次へボタンを押して、Createボタンを押す。
4. 設定
仮想マシンを右クリックして、設定を開く。左のリストで、ストレージを選択して、右に現れるストレージツリーのIDEコントローラの「ハードディスクの追加」アイコンをクリック。既存のディスクにおける選択ボタンをクリックして、sdcard.vdiを選択。
左のリストで、ネットワークを選択して、アダプタ1の割り当てをNATからブリッジアダプタに変更して、OKボタンを押す。
5. 起動、IPアドレスを調べる
起動して、ウェブブラウザでLAN内にあるWebサーバにアクセスし、Webサーバのアクセスログから仮想マシンのIPアドレスを調べる。Webサーバを用意できない人は、9に飛んでほしい。
6. asbで接続
$ export ADBHOST=仮想マシンのIPアドレス
$ adb kill-server
$ adb start-server
$ adb devices
仮想マシンが表示されていたら、adbでアクセスでできる。
7. ターミナルエミュレータのインストール
別のAndroid ICSのVirtualBox向けインストーラandroidx86_ics.7zで、仮想マシンにインストールしたものから、Term.apkを引っこ抜いた。これをここに置いておく。これをPCでダウンロードして、
$ adb install Term.apk
すれば、ターミナルエミュレータが使えるようになる。なお、ググって、Android 2.3以前のターミナルエミュレータのapkをダウンロードして、インストールしてみたが、エラーで強制終了した。
8. 次回以降、仮想マシンを起動したときIPアドレスを調べるには
Terminal Emulatorを起動して、
$ ifconfig eth0
で仮想マシンのIPアドレスを調べられる。
9. WebサーバでIPアドレスを調べることができない人は
5、6、7をすっ飛ばして、Androidのブラウザから、ここにアクセスして、Termial.apkをダウンロードして、インストールすることもできる。ただし、設定 - セキュリティ - 提供元不明のアプリにチェックを入れる必要がある。Androidのブラウザから上記urlにアクセスするときは、Google検索で、sarl + tokyoで検索してヒットする「LangDroid - Linux、Java、Android、デジタルガジェット技術ノート」を開いて、トップページから、本記事のページをたどって欲しい。
10. 開発しているアプリをインストールするには
8の方法でAndroid ICSのIPアドレスを調べ、6の方法でadb接続する。
Testing Android-x86 Ice Cream Sandwich-Image from VMLiteのページで、for free downloadのリンクをクリックして、Android-v4.7zをダウンロード。これに含まれるVirtualBox向けハードディスクイメージは、マウス、ネットワーク、SDカードが利用できます。
2. 展開
Ubuntuでは
$ 7z x Android-v4.7z
3. VirtualBoxで仮想マシン作成
OSタイプで、オペレーティングシステムをLinux、バージョンをOther Linuxにして、次へボタンを押す。メモリは適宜設定。仮想ハードディスク作成画面のときに、仮想マシンを置くディレクトリに、2で展開して得られたAndroid-v4ディレクトリの中身のうち、拡張子がvdiのVirtualBox仮想ディスクイメージファイルをコピー。起動ディスクの設定で、既存のハードディスクを使用をチェックして、Android-v4.vdiを選択。次へボタンを押して、Createボタンを押す。
4. 設定
仮想マシンを右クリックして、設定を開く。左のリストで、ストレージを選択して、右に現れるストレージツリーのIDEコントローラの「ハードディスクの追加」アイコンをクリック。既存のディスクにおける選択ボタンをクリックして、sdcard.vdiを選択。
左のリストで、ネットワークを選択して、アダプタ1の割り当てをNATからブリッジアダプタに変更して、OKボタンを押す。
5. 起動、IPアドレスを調べる
起動して、ウェブブラウザでLAN内にあるWebサーバにアクセスし、Webサーバのアクセスログから仮想マシンのIPアドレスを調べる。Webサーバを用意できない人は、9に飛んでほしい。
6. asbで接続
$ export ADBHOST=仮想マシンのIPアドレス
$ adb kill-server
$ adb start-server
$ adb devices
仮想マシンが表示されていたら、adbでアクセスでできる。
7. ターミナルエミュレータのインストール
別のAndroid ICSのVirtualBox向けインストーラandroidx86_ics.7zで、仮想マシンにインストールしたものから、Term.apkを引っこ抜いた。これをここに置いておく。これをPCでダウンロードして、
$ adb install Term.apk
すれば、ターミナルエミュレータが使えるようになる。なお、ググって、Android 2.3以前のターミナルエミュレータのapkをダウンロードして、インストールしてみたが、エラーで強制終了した。
8. 次回以降、仮想マシンを起動したときIPアドレスを調べるには
Terminal Emulatorを起動して、
$ ifconfig eth0
で仮想マシンのIPアドレスを調べられる。
9. WebサーバでIPアドレスを調べることができない人は
5、6、7をすっ飛ばして、Androidのブラウザから、ここにアクセスして、Termial.apkをダウンロードして、インストールすることもできる。ただし、設定 - セキュリティ - 提供元不明のアプリにチェックを入れる必要がある。Androidのブラウザから上記urlにアクセスするときは、Google検索で、sarl + tokyoで検索してヒットする「LangDroid - Linux、Java、Android、デジタルガジェット技術ノート」を開いて、トップページから、本記事のページをたどって欲しい。
10. 開発しているアプリをインストールするには
8の方法でAndroid ICSのIPアドレスを調べ、6の方法でadb接続する。
how to use adb and gdbserver with VirtualBox
1. use adb:
In the VirtualBox network configuration, it is simplest to configure it for Host-Only or Bridged.
boot up Android iso image on the VirtualBox.
setup ethernet (normally, it will do DHCP by default)
find the IP address of the android VM, by going to the console <Alt-F1> and then typing: netcfg
you can go back to the UI by pressing <Alt-F7>
on you host machine, cd <android source code root directory>/out/host/linux-x86/bin/
./adb kill-server
./adb connect <VirtualBox IP address>:5555, after this command, you should see something like below
* daemon not running. starting it now *
* daemon started successfully *
connected to <VirtualBox IP address>:5555
./adb logcat to dump the debug log
2. using adb with a NAT'ed VM
The steps above work nicely if you have a VM which is set up to use Bridged or Host-Only adapters
However, if you have a NAT'ed VM you cannot connect to the VM IP from the host
You will need to set up port forwarding for a host port to be forwarded to the VM port 5555 (which is adb)
VBoxManage modifyvm <VMName> --natpf1 adb,tcp,*,<localport>,*,5555
Example from one machine:
VBoxManage modifyvm froyo --natpf1 adb,tcp,*,5555,*,5555
Once this is done, you should see the local port (i.e. 5555 in this case) bound on the host via netstat -a
You can now connect to the VM by adb localhost:5555
3. how to use gdb with gdbserver:
Android-x86 comes with a preinstalled gdbserver. And you can find it in /sbin/gdbserver. To use gdb to debug your process, you need to:
set up host-only network as mentioned earlier
in the terminal emulator, run su
in the terminal emulator, run gdbserver <VirtualBox ip address>:1234 [application binary name with the path] or [--attach pid]
on your host machine, run gdb [path of your application binary]
gdb > target remote <VirtualBox ip address>:1234
gdb > set solib-search-path <the path to all the shared library binaries>
gdb > c
4. Stop zygote to run automatically:
in the vendor/asus/eeepc/init.rc, change following lines
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
socket zygote stream 666
onrestart write /sys/android_power/request_state wake
onrestart write /sys/power/state on
to:
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
socket zygote stream 666
onrestart write /sys/android_power/request_state wake
onrestart write /sys/power/state on
disabled
oneshot
To start zygote manually just do "start zygote" from the command line.
In the VirtualBox network configuration, it is simplest to configure it for Host-Only or Bridged.
boot up Android iso image on the VirtualBox.
setup ethernet (normally, it will do DHCP by default)
find the IP address of the android VM, by going to the console <Alt-F1> and then typing: netcfg
you can go back to the UI by pressing <Alt-F7>
on you host machine, cd <android source code root directory>/out/host/linux-x86/bin/
./adb kill-server
./adb connect <VirtualBox IP address>:5555, after this command, you should see something like below
* daemon not running. starting it now *
* daemon started successfully *
connected to <VirtualBox IP address>:5555
./adb logcat to dump the debug log
2. using adb with a NAT'ed VM
The steps above work nicely if you have a VM which is set up to use Bridged or Host-Only adapters
However, if you have a NAT'ed VM you cannot connect to the VM IP from the host
You will need to set up port forwarding for a host port to be forwarded to the VM port 5555 (which is adb)
VBoxManage modifyvm <VMName> --natpf1 adb,tcp,*,<localport>,*,5555
Example from one machine:
VBoxManage modifyvm froyo --natpf1 adb,tcp,*,5555,*,5555
Once this is done, you should see the local port (i.e. 5555 in this case) bound on the host via netstat -a
You can now connect to the VM by adb localhost:5555
3. how to use gdb with gdbserver:
Android-x86 comes with a preinstalled gdbserver. And you can find it in /sbin/gdbserver. To use gdb to debug your process, you need to:
set up host-only network as mentioned earlier
in the terminal emulator, run su
in the terminal emulator, run gdbserver <VirtualBox ip address>:1234 [application binary name with the path] or [--attach pid]
on your host machine, run gdb [path of your application binary]
gdb > target remote <VirtualBox ip address>:1234
gdb > set solib-search-path <the path to all the shared library binaries>
gdb > c
4. Stop zygote to run automatically:
in the vendor/asus/eeepc/init.rc, change following lines
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
socket zygote stream 666
onrestart write /sys/android_power/request_state wake
onrestart write /sys/power/state on
to:
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
socket zygote stream 666
onrestart write /sys/android_power/request_state wake
onrestart write /sys/power/state on
disabled
oneshot
To start zygote manually just do "start zygote" from the command line.
2012年9月26日水曜日
Androidのadbのメモ(12) adbdをTCPモードに切り替える
システムプロパティの値を直接書き直したりもしましたが、今のところ一番よいと思われる手順は以下です。
まずUSBでつながっている状態で、ネットワークのIPアドレスを確認します。
$ adb shell netcfg lo UP 127.0.0.1 255.0.0.0 0x00000049 eth0 UP 192.168.1.56 255.255.255.0 0x00001043
TCPモードへの切り替えコマンドを実行します。指定するポート番号は5555から5585までの奇数です。
$ adb tcpip 5555 restarting in TCP mode port: 5555 $ adb devices List of devices attached $
ここでadb deviceとしてUSBでの接続が切れたことを確認します。もしこれで切れない場合はTCPモードへの切り替えがうまくいっていません。そうなる原因については後述。
新たにTCP経由で接続するためには、まずadb serverを終了させ、環境変数ADBHOSTにさきほど調べたIPアドレスをセットしてadb serverを起動します。そのあとは通常通り使えるはずです。
$ adb kill-server $ ADBHOST=192.168.1.56 adb start-server * daemon not running. starting it now on port 5037 * * daemon started successfully * $ adb devices List of devices attached emulator-5554 device $
TCP経由で接続している場合は、emulatorであってもなくても"emulator-" + (ポート番号 - 1)の名前で認識されます。
"adb tcpip"を実行したときのadbdの動作
system/core/adb/services.c: restart_tcp_service を見てください。
property_set("service.adb.tcp.port", value);
でシステムプロパティを書き換えた後に、exit(1)で自分でプロセスを終了させます。するとinitがadbdを再起動するので、そのときに"service.adb.tcp.port"の値を見てTCPモードになります。
Android 4.0ではadbdがsecureモードでも問題なくTCPモードに切り替えることができますが、Android 2.3までだとadbdがroot権限で動いていないと"service.adb.tcp.port"のシステムプロパティの書き換えがPermission deniedで失敗します。その結果、adbdが再起動してもUSBモードのままです。
注意
adbdをTCPモードにしたときは、セキュリティ的には無防備です。誰でもパスワード無しでshellが使えてしまいますし、通信経路も暗号化されていません。公衆無線LANなどで使うべきではないですね。
Android 2.3でsecureモードでもadbをTCPに切り替え可能にするパッチ
initのソースコードの以下の一行を追加してリビルドしたものに置き換えることができれば、Android 2.3でsecureモードでもadbをTCPに切り替え可能になります。
system/core/init/property_service.c
$ diff -u property_service.c.2 property_service.c --- property_service.c.2 2012-02-07 18:40:34.472414791 +0900 +++ property_service.c 2012-02-07 18:41:24.782801630 +0900 @@ -79,6 +79,7 @@ { "debug.", AID_SHELL, 0 }, { "log.", AID_SHELL, 0 }, { "service.adb.root", AID_SHELL, 0 }, + { "service.adb.tcp.port", AID_SHELL, 0 }, { "persist.sys.", AID_SYSTEM, 0 }, { "persist.service.", AID_SYSTEM, 0 }, { "persist.security.", AID_SYSTEM, 0 }, KZM-A9-Dualボードで動作確認ずみ。
Android 4.1.1のソースを取得してemulatorをビルドする
Android 4.1.1 (Jelly Bean)のソースコードが公開されたので、それをとってきてemulatorのビルドをしてみました。
0. 前準備
あらかじめmasterのリポジトリでrepo syncしておきます。これはJBのソース公開の前にやっておきます。
$ cd android-master $ repo sync
さて、JBのソースが公開されたときに全部をとってくるのはネットワーク資源の無駄。
masterのディレクトリにある .repo を再利用します。
$ cd .. $ mkdir android-4.1 $ cp -a android-master/.repo/ android-4.1/
1. ソースコードの取得
これで以下のように repo initからrepo syncすれば、転送されるのはmasterからの差分だけなのですぐに終わります。
$ cd android-4.1/ $ repo init -u https://android.googlesource.com/platform/manifest -b android-4.1.1_r1 $ repo sync
repo sync に -jオプションはつけなくても並列化して処理してくれるようです。
2. ビルド
開発環境にはUbuntu 12.04 (x86_64)を使用しています。
$ export ANDROID_JAVA_HOME=/usr/lib/jvm/jdk1.6.0_31 $ export JAVA_HOME=$ANDROID_JAVA_HOME $ export PATH=$JAVA_HOME/bin:$PATH $ . build/envsetup.sh $ lunch full-eng $ time make -j8 2>&1 |tee make.log
ビルドにかかったのは40～50分。仕事で別のビルドもやってたので正確な時間ではありません。
3. emulatorの起動
$ emulator -show-kernel -shell
2012年9月23日日曜日
Google I/O App for Android
Google I/O is a developer conference held each year with two days of deep technical content featuring technical sessions and hundreds of demonstrations from developers showcasing their technologies.
This project is the Android app for the conference. The app supports devices running Android 2.2+, and is optimized for phones and tablets of all shapes and sizes.
With the app, users can:
- View the conference agenda and edit your personal schedule
- View detailed session, code lab, and speaker information, including speaker bios, photos, and Google+ profiles
- +1 sessions right from the app
- Participate in public #io12 conversations on Google+
- Guide yourself using the conference map
- Get a reminder a few minutes before sessions in your schedule are due to start
- View information about companies in the Developer Sandbox
- Keep up with announcements from the I/O team during the conference
- View your schedule on your Android 3.0+ device's home screen using an app widget
- Play "I/O Live" session video streams on your Android 3.0+ and Google TV devices
- Automatically sync sessions in your schedule to your Android 4.0 device's calendar
- Beam session details from your Android 4.0, NFC-enabled device to another using Android Beam