いよいよ明日！「NFC QUEST 公式ページ」を公開しました

11/1(火)にパシフィコ横浜で開催される『Google Developer Day 2011 Japan』に出展予定の「NFC QUEST」公式ページを公開しました！

「NFC QUEST公式ページ」

現在公式ページではイベント概要資料などを公開していますが

イベント当日には登録ゲームキャラクターなどを確認できるゲームサイトも公開されます！

当日の実況や攻略情報など見逃せない情報も流れますので

参加を予定されている方は是非ブックマークしてください。

明日は皆様と会場でお会いすることを楽しみにしています！

　～NFC QUEST制作チームより～

公式twitterアカウントNFC QUEST の 魔王も随時更新しています。フォローよろしく！

【お願い】

「NFC QUEST」では、キャラクターの名前とアイコンを『Google+』のプロフィールから取得します。

もしくはgoogleアカウントの 公開プロフィール からの取得も可能です。

当日は会場内の混雑が予想されますので、事前の設定をお願いします（公開情報ですので、お気をつけて！）。

『Google Developer Day 2011 Japan』でNFCを使ったスタンプラリーゲームを実施します！

おやおや？ブリリアントサービスのようすが・・・？

カードタッチでLVアップ！

君の持ってるICカードがゲームキャラクターになるぞ！

会場に隠されたチェックポイントを見つけ出し己を鍛えよ！

ゲームブースに待ち構える魔王に、君は勝てるか？




11/1(火)にパシフィコ横浜（横浜市西区）で開催される『Google Developer Day 2011 Japan』に、NFCを使ったゲーム「NFC QUEST」を出展します。






「NFC QUEST」はNFCとクラウドを使った全く新しいイベント参加型ゲームです。

会場ではオリジナルのICカードを2000枚無償配布します。

また、皆さんが既に持っているSuica・PASMOやEdyカード、Taspoなどのカードや、おさいふケータイでも参加頂けます。







【会場内のチェックポイントにカードをタッチしてレベルアップ！】

会場内にはICカードでのタッチが可能なチェックポイントが多数設置されています。

スタンプラリーのように数多くのチェックポイントを探し、レベルを十分に上げて、魔王に挑戦して下さい。




【チームを作ろう！】

バトルブースでは３人１組のチームでゲームにチャレンジすることなります。

参加者同士でチームを組んで、ゲームブースに来て下さい




ランキング上位チームには豪華景品をご用意しております！（参加賞もあります）

皆様の挑戦をお待ちしております！




詳細は「NFC QUEST公式ページ」でご覧下さい。

Support Package (for Android 4.0) の変更点

この記事は Android Developers サイトの Support Package,r14 の翻訳です。

v4 サポートライブラリの変更点：

• アクセシビリティ API のサポート：
  
  
  
  
  • View.AccessibilityDelegate をサポートする AccessibilityDelegateCompat が追加されました。
  
  
  • AccessibilityEvent をサポートする AccessibilityEventCompat が追加されました。
  
  
  • AccessibilityManager をサポートする AccessibilityManagerCompat が追加されました。
  
  
  • AccessibilityNodeInfo をサポートする AccessibilityNodeInfoCompat が追加されました。
  
  
  • AccessibilityRecord をサポートする AccessibilityRecordCompat が追加されました。
  
  
  • AccessibilityServiceInfo をサポートする AccessibilityServiceInfoCompat が追加されました。
  
  
  • ViewGroup のアクセシビリティ機能をサポートする ViewGroupCompat が追加されました。
  
  
  • View のアクセシビリティ機能をサポートする ViewCompat が変更されました。
  
  
  
  


• EdgeEffect をサポートする EdgeEffectCompat が追加されました。


• グローバルにブロードキャストせず、単一アプリケーション中で容易に登録と受信が行える LocalBroadcastManager を追加しました。


• Android 2.3 以降のビュー用のオーバースクロールモードの確認と設定のための ViewCompat サポートを追加しました。


• フラグメントAPIの変更：
  
  
  
  
  • 新しいメニューの可視性制御を行う新しい API を追加しました。
  
  
  • カスタムアニメーション API を追加しました。
  
  
  • カスタム, 非設定インスタンスデータを保持するため、FragmentActivity に API を追加しました。
  
  
  • 様々なバグの修正。
  
  
  
  


• ViewPager の変更：
  
  
  
  
  • ページ間のマージンのサポートを追加しました。オプションの Drawable はマージンを埋めるようにすることができます。
  
  
  • EdgeEffect のサポートを追加しました。
  
  
  • キーボードナビゲーションのサポートを追加しました。
  
  
  • 現在のページの両側にどれくらいのページを保持するかを制御する、サポートを追加しました。
  
  
  • touch physics の改良。
  
  
  
  


• Froyo より以前のバージョンで動作している AsyncTasks のキャンセルで不具合が発生するローダーのバグを修正しました。サポートコードは、全てのプラットフォームで同じ振る舞いをする 自身の AsyncTask のバージョンを使用しています。

文責：技術部　瀬戸 直喜　Tweet

Android Beam の基本

この記事は Android Developers サイトの Android 4.0 Platform の一部及び NFC Basics/Beaming NDEF Messages to Other Devices の翻訳をまとめたものです。

Android Beam とは

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 を有効にするために：

1. 他のデバイスへプッシュしたい NdefRecords を含んだ NdefMessage を生成します。


2. 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 レコードの共通タイプの作成を御覧ください。

文責：技術部　瀬戸 直喜　Tweet

GPS設定ON/OFFの違いを確認する

GPS設定を切り替えて、Home画面とスクリーンOFF中の計測を行いました。

条件：
・壁紙設定：壁紙
・Wi-Fi設定：OFF
・Bluetooth設定：OFF
・GPS設定：ON/OFF
・バックグラウンドシンク設定：OFF

1.Home画面

GPS設定OFFの波形です。
約0.10Aでした。

GPS設定ONの波形です。

設定OFFよりも値が跳ね上がっている回数が多いですが、
思った以上に上昇していません。

2.スクリーンOFF中

Home画面で電源キー短押下しスクリーンOFFした状態で計測しました
GPS設定OFFの波形です。
約2秒間隔で0.05Aを超えていますが、ほぼ0Aまで落ちています。

GPS設定ONの波形です。

設定OFFの波形と変化が見られませんでした。

3.まとめ

GPS設定ONの状態では、消費電流はあまり上昇しないことがわかりました。
ただし、これは一定の場所にとどまって計測を行ったためかもしれません。
移動中に計測すると、結果は異なると思います。

SDK Tools (for Android 4.0) の変更点

この記事は Android Developers サイトの SDK Tools,r14 の翻訳です。

重要： Android SDK マネージャから 新しい Android 4.0 のシステムコンポーネントをダウンロードするためには、初めに SDK ツールをリビジョン14にアップデートして、Android SDK マネージャを再起動する必要があります。これらを実施していない場合、Android 4.0 システムコンポーネントをダウンロードすることができません。

依存関係：

• Android SDK Platform-tools リビジョン8以降が必要です。


• Eclipse で ADT を使って開発している場合、SDK ツール r14は ADT 14.0.0以降を使用するようにデザインされていることに注意してください。ADT 14.0.0 を使用していないのであれば、ADT プラグインを 14.0.0 へアップデートすることを強く推奨します。


• Eclipse以外で開発している場合、Apache Ant 1.8以降が必要です。

一般的な注意点：

• Android 4.0 以降のプラットフォームで、1つの webcam がある場合は背面カメラ、2つの webcam がある場合は背面と全面の両方のカメラをシミュレートする webcam サポートが追加されました。webcam は Windows と Linux のみでサポートされています。Mac のサポートは今後のリリースでサポートされる予定です。


• default.properties は project.properties へ、build.properties は ant.propertiesへ変更されました。Ant でビルドした既存のプロジェクトは、android update project コマンドで更新する必要があります。


• ビルドシステムの改良をサポートするために build.xml が変更されました。また、Ant コマンドが追加、変更されました。Ant コマンドのリストは、Ant コマンドリファレンスを参照してください。


• ライブラリプロジェクトのビルド方法が変更されました。


• リソースのコンパイルが頻発しないようにインクリメンタルビルドが改善されました。文字列やレイアウトを編集した際（新しいidの追加が伴わない限り）に、もはやビルドする必要はなく、個々のライブラリプロジェクトを先にビルドする必要もありません。


• 常に存在する全てのPNGファイルのcrunch（PNGの圧縮）を行う代わりに、編集されたPNGに対してだけ動作する"PNG crunch cache"を導入しました。


• SDK マネージャの UI が改良されました（詳細）。

ビルドシステムの変更点の完全な概要とサポートが必要な場合は、Android Tools Project サイトをご覧下さい。

文責：技術部　瀬戸 直喜　Tweet

ADT 14.0.0 (for Android4.0) の変更点 [ADT Plugin for Eclipse 翻訳]

この記事は Android Developers サイトの ADT Plugin for Eclipse の翻訳です。

依存性

• ADT 14.0.0 は SDK Tools r14用にデザインされています。まだ SDK Tools r14をインストールしていない場合は、Android SDK と AVD マネージャを使用して下さい。

ビルドシステム

• default.properties は project.properties に、build.properties は ant.properties に変更されました。Eclipse のプロジェクトが開かれた時に、必要があればADT は自動的にこれらのファイルをリネームします。


• Eclipse で、ライブラリプロジェクトのビルド方法が変更されました。


• Eclipseで、javacの出力先が bin/ から bin/classes に変更されました。


• リソースのコンパイルが頻発しないようにインクリメンタルビルドが改善されました。文字列やレイアウトを編集した際（新しいidの追加が伴わない限り）に、もはやビルドする必要はなく、個々のライブラリプロジェクトを先にビルドする必要もありません。


• 常に、存在する全てのPNGファイルのcrunch（PNGの圧縮）を行う代わりに、編集されたPNGに対してだけ動作する"PNG crunch cache"を導入しました。


• 通常の保存によってリソースのコンパイルが起こらないように修正しました。これらは実行時またはデバッグ時のみに発生します。（ADT12 によって導入されたパッケージングステップを無効にするビルドオプションは、現在はデフォルトになっています。）

ビルドシステムの変更点の完全な概要とサポートが必要な場合は、Android Tools Project サイトをご覧下さい。

一般的な改善

• Android 開発環境の初期セットアップを助けるために ウェルカムウィザードを追加しました（詳細）。


• ランチャーやメニューやタブのようなアイコンを作成を手助けする Android Asset Studio が統合されました（詳細）。


• Logcat ビューが改良され、PIDと同様にアプリケーション名でログの表示とフィルタリングがサポートされました（詳細）。


• SDK マネージャの UI が改良されました（詳細）。


• 新しいプロジェクトと新しいXMLファイルウィザードが複数のページを持つように改良されました。サンプルプロジェクトはワークスペース内にコピーされるようになり、マスターコピーに影響を及ぼすことなく編集や削除が可能となりました（詳細）。


• Eclipse GEFの依存性を改善しました。

XML と Java エディタ

• Android のコーディングスタイルに準拠した全ての XML ファイルを整形する、新しい XML フォーマッターが追加されました。このフォーマッターは属性を推奨される順番で並び替えができ、レイアウトエディタで変更されたものを処理することが可能です。


• XMLファイルの開いたタグと閉じたタグの間をジャンプすることができる、"Go to Matching"(CTRL+SHIFT+P) 機能を追加しました。


• Macで "エンクロージング要素の選択" をサポートしました。


• 文字列の中にキャレットが入っている時、文字列を抽出するクイックフィックスを追加しました（詳細）。


• XML エディタのリターンキーを押す時に、自動インデント・アンインデントを自動的に行うことができる "スマートインデント" を改良しました（詳細）。

レイアウトエディタ

• ドラッグとリサイズ操作のツールチップフィードバックを追加しました。例えば、relative レイアウト中をドラッグする時に、提案された制約が表示されます。リサイズの際は新しい範囲が表示されます（詳細）。


• 厳密な警告を抑制する機能を追加しました（詳細）。


• 子供のコンテナを削除してトップレベルまで移動し、ネームスペースとレイアウトの属性を必要に応じて変換する "Remove Container"（コンテナの削除）と呼ばれる視覚的なリファクタリングツールを追加しました。（詳細）


• 子供が親を完全に覆ってしまい選択することが難しい場合に、親のプロパティにアクセスするためのコンテキストメニューをプル－ライトメニューに追加しました。


• コンテキストメニューのプロパティ操作を改善しました。それぞれのビューの属性でよく設定されるものをメニューのトップにリストします。プロパティのメニューは最も最近設定された属性へのアクセスを提供し、属性は定義されたビューやレイアウトの属性のみ、または、全ての属性がアルファベット順で構成されます（詳細）。

バグ修正

• 多くのバグの修正とマイナーな改善を行いました、特にいくつかのクリティカルなLinuxのバグを修正しました。

文責：技術部　瀬戸 直喜　Tweet

Bluetooth設定ON/OFFの違いを確認する

Bluetooth設定を切り替えて、Home画面とスクリーンOFF中の計測を行いました。

条件：
・壁紙設定：壁紙
・Wi-Fi設定：OFF
・Bluetooth設定：ON/OFF
・GPS設定：OFF
・バックグラウンドシンク設定：OFF
・Bluetooth設定"ON"の場合は、ペアリング確立後に計測

1.Home画面

Bluetooth設定OFFの波形です。
約0.10Aでした。

Bluetooth設定ONの波形です。
OFFの波形とあまり変わりませんでした。

2.スクリーンOFF中

Home画面で電源キー短押下しスクリーンOFFした状態で計測しました
Bluetooth設定OFFの波形です。
約2秒間隔で0.05Aを超えていますが、ほぼ0Aまで落ちています。

Bluetooth設定ONの波形です。
一定間隔で約0.02Aの波形が現れました。

3.まとめ

Bluetoothデバイスのスキャンが動いていない状態では、消費電流はあまり上昇しないことがわかりました。
スクリーンOFF中は一定間隔で約0.02Aの波形が現れました。
CPUもしくはBluetoothチップがスリープモードで動作中かもしれません。

Wi-Fi設定ON/OFFの違いを確認する

Wi-Fi設定を切り替えて、Home画面とスクリーンOFF中の計測を行いました。

条件：
・壁紙設定：壁紙
・Wi-Fi設定：ON/OFF
・bluetooth設定：OFF
・GPS設定：OFF
・バックグラウンドシンク設定：OFF
・Wi-Fi設定"ON"の場合は、アクセスポイントと接続確立後に計測

1.Home画面

Wi-Fi設定OFFの波形です。
約0.10Aでした。

Wi-Fi設定ONの波形です。
頻繁に0.15Aを超えているのがわかります。
一定間隔でCPUもしくは何かしらのチップが動作していると思われます。

2.スクリーンOFF中

Home画面で電源キー短押下しスクリーンOFFした状態で計測しました。

まずは、Wi-Fi設定OFFの波形です。
約2秒間隔で0.05Aを超えていますが、ほぼ0Aまで落ちています。

Wi-Fi設定ONの波形です。
Home画面と同様、頻繁に0.05Aを超えているのがわかりました。
スクリーンOFF中でも、CPUもしくは何かしらのチップが動作していると思われます。

3.まとめ

Wi-Fi設定をONにすると消費電流が上昇するのは予想していましたが、
スクリーンOFF中でも頻繁に上昇していたことは驚きでした。
スクリーンOFFのIntentを受け、Wi-Fi設定をOFFにする仕組みを組み込めば節電対策になるかもしれません。

画面設定「画面の明るさ」の違いを確認する - オシロスコープの波形

1Ωの抵抗とオシロスコープの接続が行えたので、
「画面の明るさ」の波形を計測しました。

電流は以下の式から求めています。

電流（Ｉ）＝電圧（Ｖ）÷抵抗（Ｒ）
＝電圧（Ｖ）÷1Ω
＝電圧（Ｖ）


条件：
・壁紙設定：壁紙
・Wifi設定：OFF
・bluetooth設定：OFF
・GPS設定：OFF
・バックグラウンドシンク設定：OFF

「画面の明るさ」の変更方法：
・電源管理ウィジェットによる変更

1.「画面の明るさ」設定：レベル1

電源管理ウィジェットにて一番暗い設定にしました。
約0.10～0.12Aでした。

2.「画面の明るさ」設定：レベル2

電源管理ウィジェットにて1段階目の明るさ。
約0.13～0.15Aでした。

3.「画面の明るさ」設定：レベル3

電源管理ウィジェットにて2段階目の明るさ。
約0.22～0.25Aでした。

まとめ

各レベルと電流値を表にしました。

画面の明るさ	電流値
レベル1	約0.10～0.12A
レベル2	約0.13～0.15A
レベル3	約0.22～0.25A

以前、安定化電源に表示されていた値とほぼ一致しました。
画面を明るくする程、電流の値が大きくなるのがわかります。

1Ωの抵抗とオシロスコープ接続

1.1Ωの抵抗

オシロスコープで消費電力を計測するために、1Ωの抵抗をつなげました。

はんだ付けが苦手で、ちょっと雑になってしまいました。

2.オシロスコープを接続

1Ωの抵抗につづき、オシロスコープを接続しました。

電気回路図で示すと以下のようなシンプルな接続となります。

Wifi設定をONにして接続時の波形を計測中の写真です。

次回から、この機材を利用して消費電力の計測を行います。

画面設定「画面の明るさ」の違いを確認する

ダミー電池の動作と安定化電源による起動が確認できたので、
早速、簡単な動作を計測してみました。

条件：
・壁紙設定：壁紙
・Wifi設定：OFF
・bluetooth設定：OFF
・GPS設定：OFF
・バックグラウンドシンク設定：OFF

「画面の明るさ」の変更方法：
・電源管理ウィジェットによる変更

1.「画面の明るさ」設定：レベル1

電源管理ウィジェットにて一番暗い設定にしました。

2.「画面の明るさ」設定：レベル2

電源管理ウィジェットにて1段階目の明るさ。

3.「画面の明るさ」設定：レベル3

電源管理ウィジェットにて2段階目の明るさ。

まとめ

各レベルと電流値を表にしました。

画面の明るさ	電流値
レベル1	0.11A
レベル2	0.15A
レベル3	0.26A

画面を明るくする程、電流の値が大きくなるのがわかります。
次回はオシロスコープを接続して波形から計測します。

消費電力計測用のダミー電池作成 part3

3.配線

電池と端末本体と接する箇所に金具があたるように配線を行いました。

本体に嵌め込むと以下のような感じ。

安定化電源と接続して、電気を流してみました。
みごと、起動に成功！！

ようやく、計測の準備が整いました。

ADKとArduinoの使いかた

先月の記事に続きについてADK-demoボードの使いかたとAndroidAccessoryデモアプリのビルド方法についてレポートいたします。

☆ Android Accessoryとは

今年５月にgoogleから発表されたAndroidハードウェア拡張規格のことです。

詳しい情報はこちらを参照してください。

　http://developer.android.com/guide/topics/usb/adk.html

今回はgoogleで公開されているソースコードを使用しました。

　https://dl-ssl.google.com/android/adk/adk_release_0512.zip

☆ Android Accessoryの面白いところ

一般的にハードウェアの拡張といえばUSBに周辺機器を接続するというイメージがありますが

Android Accessoryは、なんと外部装置がUSBホストでAndroid端末が周辺機器として振舞います。

この方式を取るメリットとしてはスマートフォンのように電力的に非力なデバイスから

外部へ電力供給させることなく、外部から電力供給を受けながら半永久的に動作させることが

できることです。またフレームワーク層でハードウェア/ドライバを隠蔽してくれていることから

難しいドライバなどを書かなくても外部機器を接続できるメリットもあります。

１．Android Accessoryを実現するためのハードウェア

当初Android AccessoryはArduinoをベースとした実装として発表されましたが

最近になってArduinoを用いないADK対応ボードもいくつか出てきているようです。

今回はADKの基本を知るためにもArduinoをベースにしたものを用いることにしました。

Arduinoを用いたADKを実現するアプローチとして次のようなものがあります。

　a) RT-ADKボード

　b) Arduino ADKボード

　c) Arduino MEGA 256 + USB HOST Shield 2.0

d) Arduino uno + SparkFun USB HOST Shield

RT-ADKボードとサブボード

RT-ADKボードはGoogleのロゴも付いていて、持っていて嬉しい基板ではありますが

ちょっと入手が大変なこともあり、今回は本家Arduinoが出しているArduino ADKボードでの

使用方法も併せて記載いたします。

☆Arduino USBシールドとADKボードの違いについて

オリジナルのUSB HOSTはシールドという形で拡張されるようになっていますが

RT-ADKボードとArduino ADKではシールド接続用の信号を温存するために

USB回路の接続にArduino非互換の信号を使っています。

そのため本家 USB HOSTシールドのライブラリをそのまま使うことができません

ちょっと古いですが最初のうちはADK Package配布に含まれているライブラリを使うようにしてください。

どうしても新しいものを使いたい方は次のピン割り当てを書き換えれば使えるようになるはずです。

　INT GPIO_9 -> ATMEGA2560(PE6)

　RST GPIO_8 -> ATMEGA2560(PJ2)

　GPX GPIO_7 -> ATMEGA2560(PJ3)

1-1．ツールとライブラリの準備

ADKで必要となるArduinoの開発環境は次のようにインストールを行う必要があります。

・Arduinoソフトウェア

Arduinoを動かすための基本ツールは次の場所から入手することができます。

　http://arduino.cc/en/Main/Software

ここでは9/20時点で最新版であるArduino 0022 を使用しています。

arduino-0022.zipをダウンロードし、任意のフォルダに展開します。

このツールは任意のフォルダから起動できるので外部ドライブに展開しても使用することができます。

今回はG:\に展開したものとして記載しています。

・Arduino ADK追加ファイル

Arduino ADKを使うために必要な追加ファイルは次の場所に公開されています。

なおこの追加ファイルはRT-ADKやunoには必要ありません。

http://www.arduino.cc/en/Main/ArduinoBoardADK

一番下にWindowsドライバのinfファイルが入ったzipファイルがありますのでダウンロードして

Arduino MEGA ADK.infをG:\arduino-0022\driversにコピーしておきます。

・Android Accessoryライブラリ

Android Accessoryで使用するライブラリをインストールします。

adk_release_0512.zipを展開しADK_release_0512\firmware\arduino_libs以下にある

次の２つのフォルダをG:\arduino-0022\librariesにコピーします。

・Capacitive Sensingライブラリ

RT-ADKボードに載っているタッチセンサーのライブラリもインストールします。

　http://www.arduino.cc/playground/Main/CapSense

ここに公開されている CapacitiveSense003.zip をダウンロードし

展開されたCapacitiveSense003フォルダをG:\arduino-0022\librariesにコピーします。

1-2. スケッチのビルド

Arduinoの世界ではソースコードをスケッチと呼びます。

ADKで配布されているコードにはスケッチも含まれていますので、これをビルドして使用します。

まずADK_release_0512\firmwareにあるdemokitフォルダをG:\arduino-0022にコピーしておきます。

arduino.exeを起動後にFile -> Openを実行し 上記コピーしたフォルダにあるdemokit.pdeを開きます。

次にTools -> Board にて "Arduino Mega 2560"を選択します。

Sketch -> Verify Compileを実行することによりビルドが開始されます。

正常にビルドされればステータス部分に"Done compiling"と表示されます。

☆Arduino ADKのみを使う場合は

Arduino ADKには RT-ADKの付属サブボードのようなものがありませんのでブレッドボードで代用します。

今回はフルカラーLED３個とスイッチ２個を載せてみました。

RT-ADKのサブボードに比べブレッドボードに載せた回路はなかり簡素なものとなっていることから

ADKオリジナルソースから次のコードをコメントアウトする必要があります。

　JoyStick

　Temp/Light Sensor

　Relay

　ServoMoter

　CapacitiveSenser

修正済みのスケッチを次の場所に置きましたので、こちらを参考にして下さい。

https://sites.google.com/a/brilliantservice.co.jp/beagleboard/adk/demokit_ADK.pde?attredirects=0&d=1

1-3. スケッチのアップロード

ビルドが終わったスケッチをアップロードする前に、予めPCとAdruinoを接続しておきます。

Arduinoボードを最初に接続した時にはドライバを要求されますので次のドライバをインストールして下さい。

RT-ADK -> G:\arduino-0022\drivers\FTDI USB Drivers\

　Arduino ADK -> G:\arduino-0022\drivers\Arduino MEGA ADK.inf

次に Tools -> Serial Portでボードに接続しているポートを指定します。

File -> Upload to I/O board を実行すればビルドされたスケッチがボードへ転送され

ADKボードとして使用することができます。

２．AndroidAccessoryデモアプリ(DemoKit)

AndroidAccessoryを動作させるためのデモアプリはAndroid Open Accessory Development Kit

(adk_release_0512.zip)に含まれています。

今回はこのデモアプリを使って動作確認するところまで記載いたします。

なお、とりあえず動作だけという方のためにビルド済みのapkファイルも準備しました。

https://sites.google.com/a/brilliantservice.co.jp/beagleboard/adk/DemoKit_singed.apk?attredirects=0&d=1

署名付きにしましたので、そのまま adb install等でインストールできます。

☆ ネットワーク越しのデバッグ

ADKはadbで使われるUSBポートを塞いでしまうため、USB接続によるデバッグができなくなります。

そこで有線LAN経由でadbを使えるようにします。

ここではBeagleBoardのIPアドレスを192.168.1.23として記載ています。

IPアドレスは使用する環境に合わせて読み替えてください。

・BeagleBoard側の設定

adbデーモンを停止したのちにadbの設定切り替えます。

シリアルコンソールから次のように入力します。

# stop adbd
# ifconfig usb0 192.168.1.23 up
# setprop service.adb.tcp.port 5555
# start adbd

adbdはAndroid起動時にUSB接続となってしまいますので

起動ごとに上記の操作を行うようにしてください。

・ホスト側の設定

いったんadbサーバを停止してからネットワーク経由で接続を行います。

adb kill-server
adb start-server
adb connect 192.168.1.23:5555

正常に接続できれば、USB接続と同じように"adb"や"ddms"を使ってデバッグを行うことができます。

2-1. ソースコードの準備

今回は Android Open Accessory Development Kitで公開しているソースコードを用いました。

ここで配布されているADK Package(adk_release_0512.zip)をD:\workspaceに展開します。

2-2. Eclipseプロジェクトの作成

配布されているソースコードはそのままビルドすることができないことから

新規プロジェクトを作成しつつインポートさせます。

Eclipseを起動後 File -> New -> Android Projectで新規プロジェクトを作成します。

新規プロジェクトのダイアログが出ますので次の項目を入力してFinishボタンを押します。

Project nameは任意の名前でかまいません

　"Create project from existing source"を選択し

　"D:\workspace\adk_release_0512\ADK_rlease_0512\app"を指定

Build Targetは"Google APIs(2.3.3)"を選択

※Android 2.3.4の項目が無いのは2.3.4発表時に3.0のためにAPI Level 11が定義されていたため

適切なAPI Levelが割り当てられなかったためのようです。

そのため2.3.4は2.3.3＋αとして扱われています。

2-3. ビルド、デバッグ

ADBの接続ができていればそのまま動作させることができます。

Targetバージョンが一致していないため警告マークが出ますが問題ありません。

デモアプリをインストール後にADK ボードを接続すると次のような画面が出ます。

ここでOKのボタンを押すとデモアプリが動き出します。

ボタンやジョイスティック操作に合わせて画面が変化したり、R,G,Bのスライダを

動かすとLEDが点灯すれば正常に動作しています。

今回は早足ではありましたがAndroidに独自ハードウェアを付ける方法について解説いたしました。

AndroidといえばJavaアプリというイメージがありますが、Adruinoが繋がるようになれば

簡単にハードウェアを触れるようになります。

これを機にハードウェアに興味を持ってくださる方が増えれば幸いです。

次回はADKの応用編としてFarmboxのプラットフォームとそれに必要になる機能

(無線LANとWebカメラなど)の追加方法についてレポートする予定です。

消費電力計測用のダミー電池作成 part2

2.パテの流し込みと整形

流し込みもできる超低粘度のポリパテ、パテ革命「ドロドロ」を使用しました。


型取りした台に流し込み。

乾燥させること二日間、無事に固まりました。

荒々しい電池のようなモノが出来上がりました。

でこぼこしている箇所を削り取った後。

Nexus Sにぴったり嵌るようになりました。

消費電力計測用のダミー電池作成 part1

消費電力の測定用にダミー電池の作成を行いました。
工作が苦手なため、かなり四苦八苦しました。
でも、楽しかったので記事として残します。

0.はじめに

今回、使用する端末はNexus S。

新品のNexus Sです。
まだオリジナルの保護シートが張られた状態です。

1.型取りを行う

まずは電池の型取りを行います。

型取り用の粘土をコネコネ開始。
手際が悪く、なかなか上手に混ざらなかったのですが、
慣れてきたころにいきなり固まり始め、慌てて電池を押し込みました。

数10分放置して電池を取り出すと、型ができました。
(※はじめての型取りで汚くてすみません)