いよいよ明日！「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にして接続時の波形を計測中の写真です。

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