GDKでHelloWorldを作ってみる

Google Glass

Google からGlass Development Kit（以後GDK）が発表されてしばらく経ちました。

合わせて開発者用Glassの販売も行われ、今後市場投入に向けての動きが活発になることが予想されます。

しかしこの開発者用Glass、2014年1月時点で日本からは購入することができません。

USAでも開発者向けの招待メールでしか購入ができないようになっています。

弊社は現地支社がある為、いくつか購入することができました。

Glassを使った開発ノウハウが徐々に溜まってきたので、GDKでHelloWorldを書く方法をお伝えします。

さて、まず一言。

HelloWorld を書くのにこんなに苦労したのは久しぶりでした

完成されたSDKであれば普通、HelloWorldというのはプロジェクトを新規作成すると自動的に生成されるスケルトンプロジェクトに、ちょちょいと追記するだけで簡単に作れるものなのですが、現在のGDK（Rev.2）にはスケルトンコードを出力する機能がありません。

従って今回は、GDKの中に含まれるサンプルコードをリファクタリングしながらHelloWorldを作ります。

Google Glassの開発環境

Glassの開発環境は基本的にAndroidと同じで、IDEはEclipseを使うのが最も簡単でしょう。

Android SDK Managerから Android 4.0.3 > GDK を選択して開発環境をインストールします。


HelloWorldを作ってみる

それではGDKに含まれるサンプルコードをリファクタリングしながらHelloWorldを作ってみます。

新規プロジェクト > Android Sample Project > GDK > Timer を選択します。最後の画面でプロジェクト名をHelloWorldに変えておきます。



このサンプルはその名の通りタイマーアプリで、設定した時間をカウントダウンすることができます。

まず、アプリがどのような動作をするか確認します。

遷移図を作りました。

Glassはタップによる文字入力ができませんので入力項目は全て選択式になります。従って、シンプルなアプリですが画面数はとても多くなる傾向にあります。

Timerサンプルを解析してみる

次はTimerサンプルのコードを見て行きます。

まずはManifestから。

AndroidManifest.xml

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.google.android.glass.sample.timer"
    android:versionCode="2"
    android:versionName="1.0" >

    <uses-sdk
        android:minSdkVersion="15"
        android:targetSdkVersion="15" />

    <application
        android:allowBackup="true"
        android:icon="@drawable/ic_timer"
        android:label="@string/app_name" >

        <activity
            android:name="com.google.android.glass.sample.timer.MenuActivity"
            android:label="@string/app_name"
            android:theme="@style/MenuTheme"
            android:enabled="true" >
        </activity>

        <activity
            android:name="com.google.android.glass.sample.timer.SetTimerActivity"
            android:label="@string/app_name"
            android:enabled="true" >
        </activity>

        <activity
            android:name="com.google.android.glass.sample.timer.SelectValueActivity"
            android:label="@string/app_name"
            android:enabled="true" >
        </activity>

        <service
            android:name="com.google.android.glass.sample.timer.TimerService"
            android:icon="@drawable/ic_timer"
            android:label="@string/app_name"
            android:enabled="true"
            android:exported="true">
            <intent-filter>
                <action android:name="com.google.android.glass.action.VOICE_TRIGGER" />
            </intent-filter>
            <meta-data
                android:name="com.google.android.glass.VoiceTrigger"
                android:resource="@xml/voice_trigger_start" />
        </service>

    </application>

</manifest>

Activity が三つにServiceが一つ宣言されています。

こんなに小さなアプリでActivityが三つもあるのは何故か？

Glassでは基本的にActivityはコンテンツを描画する目的では無くメニューを表示する目的で使われます。従って、メニュー（設定項目や選択項目）が増えるとActivityがどんどん増えていく傾向があります。

Service内のmeta-dataは音声認識によるアプリ起動をサポートします。

次はソースコードを見て行きます。

  • MenuActivity.java
  • SelectValueActivity.java
  • SelectValueScrollAdapter.java
  • SetTimerActivity.java
  • SetTimerScrollAdapter.java
  • Timer.java
  • TimerDrawer.java
  • TimerService.java
  • TimerView.java

この中で最低限必要なクラスは以下です。

一つのGlassアプリには必ず一つのサービスが必要です。
サービスである為、アプリを終了する為のメニューが必要となるでしょう。必然的にメニューを表示するActivityも一つは必要となります。

さっき、Activityはメニューを表示する為に使うと説明しました。では、肝心のコンテンツはどのように描画するか？

GlassではCardというAndroidには無い仕組みが有ります。

Cardとは

Androidでは一つのActivityで一画面を表現しますが、Glassでは一つのCardで一つの画面を表現することができます。

CardにはStatic CardとLive Cardの二種類があり、画面の更新頻度に応じて使い分けるとDocには書かれています。

TimerサンプルはLive Cardを利用している為、今回はLive Cardを使うことにします。

Live Cardは以下のような仕組みになっています。

http://developers.google.com/glass/images/diagrams/live-card-service.png

Glassではアプリ一覧が並ぶUIの事をTimelineと呼びます。

Timeline からアプリのサービスが起動し、サービスでLive Cardを生成しコンテンツの描画を行います。

HelloWorldを作ってみた

Timerサンプルを元に作成したHelloWorldのプロジェクト一式はこちら。


重要なのはTimerServiceのonStartCommand()で、それ以外はAndroidと全く同じです。

TimerService.java

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    if (mLiveCard == null) {
        //LiveCardを生成したい
        mLiveCard = mTimelineManager.createLiveCard(LIVE_CARD_TAG);

        //レンダリング用Drawerを追加したい
        mLiveCard.setDirectRenderingEnabled(true).getSurfaceHolder().addCallback(mTimerDrawer);
        
        //Menu用Activityの生成と追加をしたい
        Intent menuIntent = new Intent(this, MenuActivity.class);
        menuIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TASK);
        mLiveCard.setAction(PendingIntent.getActivity(this, 0, menuIntent, 0));

        //LiveCardを表示したい
        mLiveCard.publish(PublishMode.REVEAL);
    } else {
        // TODO(alainv): Jump to the LiveCard when API is available.
    }

    return START_STICKY;
}

尚、Cardを使わずAndroidと同様にActivityのみでアプリを構築する方法もあります。

しかしこの場合、そのままではTimelineからアプリを起動することができない為、アプリを起動する為だけのGlassアプリを用意する必要があります。これに関してはまた別の機会に書きます。

Glassの開発難易度

残念ながら現時点ではGlass用のシミュレータはありません。実機が無いとアプリのテストができない為、早急なシミュレータ環境の提供を期待するばかりです。

コードを書く事だけを見れば、Cardの概念さえ理解すれば後はAndroidとほとんど同じである為、Androidアプリ開発経験者はスムーズに開発を行うことができるでしょう。

しかし、実際にGlassを身につけるとよくわかるのですが、この最低限のアプリケーションでも、起動すると本体が非常に熱くなり、継続した装着が困難になります。

Glassで実用的なアプリケーションを構築する為には高度な省エネのスキルが要求されることでしょう。

しかし、Glassはソースコードが公開されていません。その為、基本的に Java 層で省エネを実現する必要があります。

実験的なアプリケーションはAndroidの延長線上で作れるものの、現時点のGlassの性能で実用的なアプリケーションをFixする為には非常に高度な開発スキルが求められると考えます。

Java で省エネって、アメ車に低燃費を求めるようなもんですよね

Google Glassの新機能をハックする

Glass Google Glass


はじめに
GoogleGlassの新型(V2)の目玉の一つにイヤホン(Earbud)のサポートがあります。
このイヤホン、実は両耳タイプも存在しているのですが、Explore招待プログラムの時期には発売されておらず、なんとか新型の入手に成功できたものの、同時購入することができずに悔しい思いをされている方も多いのではないかと思います。また標準添付のイヤホンもGlassのロゴをあしらったお洒落なデザインで見た目はかなりクールなのですが、実際に使ってみると装着感がいまひとつで常時着けて使うのには残念な品物でした。

そこでGlassに自分好みのイヤホンを付けられるようにしてみましたので、その方法についてレポートいたします。

免責事項
この記事に書かれている内容は技術的な参考資料として記載しています。
端末等の破損や作業上の事故について弊社および記事作成者は責任を持ちません。
実施にあたっては各自の判断において行うようにしてください。

1.イヤホンをサポートする仕掛け
Glassにイヤホンを差し込む場所は充電やUSBデバッグを行うための端子で、もともとは通信を行うためのものです。同じような使い方ができるものにスマートフォンがありますが、新型Glass(V2)にも同様にUSB回路をアナログ的に切り替えられるスイッチが入っており、USB通信とイヤホンの信号を切り替えられるようになりました。

またカーネルソースを調べるとUSB機能を切り替えるコードが見つかりました。

arch/arm/mach-omap2/notel-usb-mux.c

static void sync_usb_mux_mode(struct usb_mux_device_info *di)
{
　　enum usb_mux_mode mode;

~~~~~~
~~~~~~
　　if (di->force_usb || di->usb_online)
　　　　mode = USB_MUX_MODE_USB;
　　else
　　　　mode = di->req_mode;

　　dev_warn(di->dev, "Setting MUX mode to %s\n", str_for_mode(mode));
　　switch (mode) {
　　　　case USB_MUX_MODE_FLOATING:
　　　　　　gpio_set_value(di->gpio_cb1, 0);
　　　　　　gpio_set_value(di->gpio_cb0, 0);
　　　　　　break;

　　　　case USB_MUX_MODE_USB:
　　　　　　gpio_set_value(di->gpio_cb1, 0);
　　　　　　gpio_set_value(di->gpio_cb0, 1);
　　　　　　break;

　　　　case USB_MUX_MODE_TTY:
　　　　　　gpio_set_value(di->gpio_cb1, 1);
　　　　　　gpio_set_value(di->gpio_cb0, 0);
　　　　　　break;

　　　　case USB_MUX_MODE_AUDIO:
　　　　　　gpio_set_value(di->gpio_cb1, 1);
　　　　　　gpio_set_value(di->gpio_cb0, 1);
　　　　　　break;

　　　　default:
　　　　　　dev_err(di->dev, "Invalid USB MUX mode requested: %d\n", mode);
　　　　　　goto error;
　　}

　　di->cur_mode = mode;

error:
return;
}

この部分はsysfsから設定されるようになっていてフレームワーク側から切り替えを行っているようです。
もうお気づきかと思いますが、上記コードからGlassにはイヤホン以外にもシリアルポートも付くことが見て取れます。もしシリアルポートへの切り替えができればカーネルのデバッグに役立つはずですが、しかし切り替えはフレームワーク側で行っているためこの部分からは推察することができません。今後の調査が必要かと思います。


2.市販のアダプタは使えるか？
ちょうど手元に愛用PHSに添付されていた変換アダプタがあり、機能的に類似していることから試しに接続してみましたが、標準添付イヤホンのように音声が切り替わらず骨伝導スピーカから音声が出続けました。また近所の百均で売っている変換アダプタも同様でした。どうやら日本国内で流通している規格とは違うもののようです。


3.解析してみる
コネクタ部分はUSBのMicro-Bタイプなので変換アダプタに繋いで回路を調べてみました。
標準添付のイヤホンはD+とGND間の抵抗が40Ωだったのでここがダイナミックスピーカを使った音声系だと判ります。それ以外にIDとGND間にも回路抵抗があり、この部分が外付けアクセサリを識別する仕掛けのようです。


今度は日本国内で入手できる変換アダプタです。


同じようにD+/D-とGNDがヘッドホン端子に繋がっているのでこの部分は等価の回路です。
ところがIDとGND間の抵抗値が異なります。

標準添付のイヤホン 1MΩ
国内のもの 287K-303KΩ

USB関連の文献を探してみるとGlassの添付品は"Audio Type 1"、日本国内で流通しているものは"Audio Cradle"に準拠したものであることが判りました。

3. 改造
標準添付品との差異が判ればあとは改造するのみです。
今回は百均のSeriaさんで売っている変換アダプタを使いました。このシリーズの変換アダプタはUSB側のコネクタが分解できるようになっていていまして、百均USBハッカー御用達の商品となっています。

慎重にピンセットでUSBコネクタ側のケースを開けるとコネクタ部分に抵抗が付いているのを見ることができます。
この抵抗を1MΩに交換します。端子部分が細かいのでショートしないように気を付けてください。

交換が終わったらステレオヘッドホンを繋いでGlassと接続します。
今まで鳴っていた骨伝導スピーカからの音が止まりヘッドホンの両耳から操作音が出ていれば成功です。
なお必ずステレオヘッドホンを使用してください、モノラルタイプは右側の回路が短絡して故障の原因となります。またGlassは外部マイクをサポートしないのでマイク付きのものを使用してもマイクは動作しません。

まとめ
今後、音楽再生アプリが使えるようになればGlassで快適に音楽が楽しめるようになるでしょう。
1500ドルもする開発デバイスが百均の商品でハックできるなんて面白いですね。
次回はGlassをAndroidっぽく使う方法についてレポートする予定です。


おまけ: Glassの隠しモード
カーネルコードを追っていると次のような保守用コードが見つかりました。
USBコネクタのID端子とVBUSを短絡したケーブルを接続すると強制的にfastbootに移行するようです。
通常動作中でもお構いなしに強制的シャットダウンしてしまうので恐ろしくて実験できませんが、たぶん文鎮化したGlassを復旧する目的のために実装されたものとだ思われます。

arch/arm/mach-omap2/notel-usb-mux.c

#define FACTORY_CABLE_VOLTAGE_THRESHOLD　4200 /* millivolts */
#define CABLE_SHUTDOWN_INTERVAL　　　　　30000 /* msec */

static void sync_usb_mux_mode(struct usb_mux_device_info *di)
{
　enum usb_mux_mode mode;
　int id_voltage;

　/* check for factory cable */
　id_voltage = voltage_id(0, 0);
　if (notle_factorycable_bootmode) {
　　/* schedule a shutdown if factory cable removed */
　　if (id_voltage < FACTORY_CABLE_VOLTAGE_THRESHOLD) {
　　　　　schedule_delayed_work(&di->shutdown_work, msecs_to_jiffies(CABLE_SHUTDOWN_INTERVAL));
　　}
　} else {
　　if (id_voltage > FACTORY_CABLE_VOLTAGE_THRESHOLD) {
　　　　kernel_restart("bootloader");
　　}
　}

ブランド戦略部 中村和貴

NFC Hacks発売中です！


弊社で取りまとめを担当した書籍「NFC Hacks」がオライリー・ジャパン様から発売中です。

http://www.oreilly.co.jp/books/9784873116242/

1章　NFCを知る
1.　RFIDと非接触ICカード
2.　NFCの利点
3.　「NFCタグ」を知る
4.　NFCデバイスの3つのモード
5.　Reader/Writerモード
6.　Peer-to-Peerモード
7.　Card Emulationモード
8.　NFCを利用した国内のサービス
9.　NFCを利用した海外のサービス
10.　NFC対応デバイス
11.　対応チップ
12.　NFCの物理学的基礎
13.　電磁誘導の結合強度


2章　NFCの規格を知る
14.　NFC Forum Type 1 Tag
15.　NFC Forum Type 2 Tag
16.　NFC Forum Type 3 Tag
17.　NFC Forum Type 4 Tag
18.　ISO-DEPについて学ぶ
19.　NFC-DEPについて学ぶ
20.　LLCPについて学ぶ
21.　SNEPについて学ぶ
22.　NDEF
23.　RTD（Record Type Definition）


3章　AndroidでNFCをHackする
24.　SettingからNFCを設定する
25.　NFCタグを読み取るためのクラス群（android.nfcパッケージ）
26.　NFCタグのタイプ別機能のためのクラス群（android.nfc.techパッケージ）
27.　Android 2.3で使えるNFC機能
28.　Android 4.0で使えるAndroid Beam
29.　Android 4.1/4.2/4.3で使えるNFC機能
30.　Android端末をReaderモードで使う
31.　アプリケーションでNFCタグを読む方法
32.　NDEFを読み込むアプリを作成する
33.　Android端末をWriterモードで使う
34.　アプリケーションでNFCタグを書く方法
35.　NDEFを書き込むアプリを作成する
36.　Android Beamを知る
37.　Android Beamを送受信するアプリを作る
38.　Android Beam送信時にデフォルトのNDEFメッセージを送信しないようにする
39.　Bluetooth Handoverについて
40.　タグ情報を使いBluetoothデバイスに接続切断する
41.　Secure Elementを使用するCard Emulation機能について


4章　WindowsでNFCをHackする
42.　NFP機能を使う
43.　PC/SC
44.　PC/SCによるNDEFタグアクセス
45.　PC/SCによるNFCデバイスアクセス
46.　Proximity APIの利用
47.　Proximity APIでのNDEFアクセス
48.　Windows環境でのP2P通信


5章　セキュリティに配慮したNFC応用サービス
49.　キーポイントを押さえてセキュリティモデルを検討する
50.　非暗号化領域を利用しつつネットワーク連動サービスを構築する

NFCの基礎から、規格の詳細、Android/Win8での実装方法、NFCを応用したサービスについての考察など、幅広い内容になっています。
NFCについて一から勉強してみたい方、何となく知っているけど分からないことがある方、仕様を確認したい上級者の方にお勧めです。
ぜひ読んでみてください。

Android 4.4 Kitkat詳細（開発者向けハイライト・その４）

Android

原文：http://developer.android.com/intl/ja/about/versions/kitkat.html

New Types of Connectivity

新しいBluetooth Profile

Android 4.4では、省電力とメディア相互作用を広い範囲でアプリをサポートするため、2つの新しいBluetooth Profileに対応しました。Bluetooth HID over GATT(HOGP)はマウス、ジョイスティック、キーボードのような低消費電力の周辺機器とアプリ間で遅延の少ない接続を提供します。Bluetooth MAPは、アプリとその付近にあるデバイス、例えばハンズフリー用の車載端末や、その他のモバイル端末と、メッセージを交換することができます。Bluetooth AVRCP 1.3の拡張として、ユーザーはBluetoothデバイスから、システム音量を設定することができます。

赤外線ブラスター

Android 4,4 では、組み込み用の赤外線ブラスターのためのプラットフォームを導入し、新しいAPIやシステムサービスをアプリで活用することができます。

新しいAPIを使うと、近くにあるテレビ、ラジオ、スイッチ、その他の電子機器を遠隔でコントロールできるアプリを構築することができます。APIは、携帯電話やタブレットが赤外線通信に対応しているかどうかをチェックし、そのキャリア周波数を照会した後、赤外線信号を送信することができます。

APIはAndroid 4.4以上が動作するデバイスでは標準となるため、ソースコードのカスタマイズなしに、広い範囲でのベンダーをサポートできます。

Wi-Fi TDLSのサポート

Android 4.4ではWi-Fi Tunneling Direct Link Setup(TDLS)のサポートにより、同じWi-Fiネットワーク上にあるデバイス間で、メディアやその他のデータの高速でシームレスな送受信を提供します。

Accessibility

字幕のシステム全体設定

Android 4.4では字幕のシステム全体設定が追加され、アプリ全体でより良いアクセシビリティ体験をサポートします。字幕のグローバル設定には、Settings -> Accessbility -> Captionsからアクセスでき、字幕の表示/非表示、言語設定、テキストサイズ、テキストスタイルが設定可能です。

動画を取り扱うアプリでは、ユーザーの字幕設定にアクセスすることができ、ユーザーの好みに合わせた調整が可能です。新しい字幕管理APIではユーザーの字幕設定を監視できます。字幕管理では、ユーザーの好みに合わせた字幕設定と同様に、優先ロケール、スケーリング係数、テキストスタイルを提供します。テキストスタイルには、前景色と背景色、エッジのプロパティ、書体が含まれます。

加えて、VideoViewを使用するアプリは、動画表示とともに字幕表示を行う新しいAPIを使用できます。ユーザーのシステム設定に応じて、システムは自動的に動画フレーム上の字幕表示を処理します。現在、VideoViewでは、WebTTVフォーマットのみ字幕の自動表示をサポートしています。

字幕を表示する全てのアプリは、ユーザーのシステム全体の字幕設定を確認し、それらの設定にできるだけ近づけた字幕をレンダリングすべきです。設定の組み合わせによって字幕がどのように表示されるかを確認できるように、Settingsアプリでは言語、サイズ、スタイル設定に応じた字幕プレビューを見ることができます。

強化されたアクセシビリティAPI

Android 4.4では、より正確な構造で、意味的な記述、画面上の要素監視をサポートするアクセシビリティAPIを拡張しました。新しいAPIによって、画面要素の詳細な情報へのアクセシビリティサービスが提供され、開発者はアクセス可能なフィードバックの品質を向上できます。

アクセシビリティのノードでは、開発者はノードがポップアップしているかどうか確認でき、入力タイプなどを取得できます。リストやテーブルのような碁盤上の情報を含んでいるノードを動作させる新しいAPIを使用することもできます。例えば、新しくサポートされるアクション、コレクション、インフォメーション、ライブリージョンモードを指定することができます。

新しいアクセシビリティイベントによって開発者は、ウィンドウコンテンツの位置変更をより密接に追従させることができ、デバイス上のタッチモードの変更を取得できます。

国際的なユーザーへのサポート

RTLロケール用Drawableのミラーリング

もしあなたのアプリがRTLスクリプトを使用するユーザーをターゲットにしている場合、ユーザーのロケール設定にRTL言語が含まれていれば、自動ミラーリングを行うべきDrawableを宣言した新しいAPIを使用することができます。

自動ミラーリングされたDrawableの宣言は、リソースの重複を防ぎ、あなたのアプリのAPKサイズを減少させます。もしLTRとRTLプレゼンテーションの両方に再利用可能なDrawableを持っている場合は、自動ミラーリングされたデフォルトのバージョンを宣言することができ、RTLリソースからDrawableを省略できます。

ビットマップ、NINE Patch、レイヤー、状態リストなど、自動ミラーリングされた様々なタイプのDrawableをアプリで宣言することができます。また、新しい属性を使用して、リソースファイルに自動ミラーリングされたDrawableを宣言することも可能です。

RTLレイアウトの強制

RTL言語へのスイッチなしで、レイアウトミラーリングの問題を簡単にデバッグ、テストするために、Androidでは開発者用オプションに、全てのアプリのRTLレイアウトディレクションの強制設定を含んでいます。

RTLレイアウトの強制オプションでは、全てのロケール向けのRTLレイアウトにデバイスを切り替え、あなたの現在の言語設定でテキストを表示できます。これによりRTL言語でアプリを表示しなくても、アプリ全体のレイアウト問題を見つけるのに役立ちます。オプションには、Settings -> Developer Option -> Force RTL layout direction、からアクセスできます。

セキュリティ強化

SELinux(強制モード)

Android 4.4では、SELinuxのpermissiveからenforcingへの設定に対応しました。これにより、enforcingポリシーを持っているSELinuxのドメイン内で、潜在的なポリシー違反はブロックされます。

改良された暗号アルゴリズム

Androidでは、さらに2つの暗号化アルゴリズムのサポートが追加され、セキュリティをさらに向上させました。デジタル署名アルゴリズム（ECDSA）のサポートでは、デジタル署名のセキュリティを向上させるキーストアプロバイダを追加しました。データ接続やアプリケーションの署名時など際に最適です。スクリプトキー生成関数は、ディスク全体の暗号化に使用される暗号鍵を保護するために実装されています。

その他の機能強化

マルチデバイス上では、VPNはユーザーごとに適用されます。これによりデバイス上の他のユーザーに影響を与えることなく、ユーザがVPN上の全てのネットワークを使用することが許可されます。また、AndroidはFORTIFY_SOURCE level2をサポートし、すべてのコードは、これらの保護されてコンパイルされています。FORTIFY_SOURCEはClangで動作するように強化されています。

メモリ使用状況の分析ツール

Procstats

新しいツールProcstatsは、あなたのアプリが使用するメモリリソースだけでなく、システム上で実行されている他のアプリやサービスによって使用されるリソースを分析するのに役立ちます。

Procstatsは、アプリの動作を追跡し続け、実行時間とメモリ使用量に関するデータを提供し、アプリが効率良く実行できるよう判断するのに役立ちます。バックグラウンドで動作するサービスを起動するアプリにとって、動作している時間とRAMの使用量を監視できることは非常に重要です。Procstatsは、アプリがメモリを使用して、アプリ全体のメモリプロファイルを決定するための時間について、フォアグラウンドアプリ向けにデータ収集します。

Procstatsは、あなたのアプリによって起動されたバックグランドサービスを識別するのに役立ちます。それらのサービスが実行中のあいだ、どれくらいRAMを使用するか追跡することができます。またProcstatsは、全体のメモリプロファイルを決定するまでのメモリ使用量を使って、フォアグラウンドにいるアプリをプロファイリングできます。


Procstatsには、Android SDKに含まれるadbツールからアクセスできます。デバイス上のプロファイリングについては、プロセス統計開発オプションを参照してください。

デバイス上のメモリの状態とプロファイリング

Android 4.4には、任意のデバイスまたはエミュレータが実行中、あなたのアプリのメモリプロファイルを簡単に分析するための、新しい開発者オプションが含まれています。あなたのアプリのどれくらいメモリを使い、RAMの少ないデバイス上でどう動作するのかを確認するのに役立ちます。開発者オプションには、Settings -> Developer options -> Process statsからアクセスできます。

プロセス統計オプションでは、新しいProcstatsサービスを使用して収集されたデータに基づいて、アプリのメモリ使用に関する詳細なメトリクスを見ることができます。メイン画面ではシステムメモリ状態の概要を確認できます。緑色はRAMの使用量が低かった期間、黄色はRAMの使用量が適切だった期間、赤色はRAMの使用量が(クリティカルに)高かった期間を指しています。

概要以下では、システム上にロードされている各アプリのメモリ使用量を表示しています。各アプリについて、青いバーはそのプロセスでロードされた相対的なメモリ負荷を示し、パーセンテージはバックグラウンドで消費される相対的な時間を示します。フォアグランド、バックグラウンド、またはキャッシュされたプロセスのみをフィルタリングしたり、システムプロセスを含める／含めないを切り替えることが可能です。データ収集期間を３、６、１２，２４時間の中から変更したり、USSメモリの有無を切り替えることも可能です。

特定のアプリのメモリ消費量について見る場合は、アプリ名をタップします。消費メモリの概要と、アプリが実行されている収集間隔の割合を各アプリごとに確認できます。また、収集中のメモリ最大使用量と平均、アプリのサービスや実行時間の割合も見ることができます。

プロセス統計データを使用したアプリ分析では、問題点を明確にし、あなたのアプリ向けに可能な限りの最適化を提案できます。例えば、もしあなたのアプリが必要以上の時間で動作し、一定期間に渡って大量のメモリを使用している場合、特にRAMの少ないデバイス上では、アプリのパフォーマンスを向上させるために解決可能なソースコードのバグがあるかもしれません。

Except as noted, this content is licensed under Creative Commons Attribution 2.5. For details and restrictions, see the Content License.

Android 4.4 Kitkat詳細（開発者向けハイライト・その３）

Android

原文：Android KitKat  |  Android Developers

New media capabilities

スクリーン録画

アプリの高品質な動画を、あなたのAndroidデバイスから直接、簡単に作成することができます。Android 4.4ではスクリーン録画のサポートが追加され、デバイス上で動画をキャプチャーしてMP4ファイルとして保存する、スクリーン録画ユーティリティが提供されます。あなたのアプリのチュートリアルやウォークスルー、テスト材料、販促動画などを作るのに、最適です。

動画は、あなたが望み、デバイスがサポートする解像度とビットレートで録画することができ、ディスプレイ上のアスペクト比を保持して出力されます。このユーティリティはデフォルトで、その時点の向きで、デバイスのディスプレイの解像度と同等またはそれに近い解像度を選択します。録画が完了すると、あなたのデバイスから直接動画を共有したり、ポストプロダクション用にあなたのホストコンピュータへMP4ファイルを引き出すことができます。

もしあなたのアプリで、スクリーン録画でキャプチャーしたくない動画やその他の保護コンテンツを再生する場合、SurfaceView.setSecure()を使用することで、コンテンツにセキュアを設定できます。

Android SDKに含まれているadbツールから、"screenrecord"のシェルコマンドを使うことで、スクリーン録画にアクセスすることができます。また、Android StudioのDDMSパネルから起動することもできます。

Adaptive playbackを通じた解像度の切り替え

Android 4.4ではAndroid Media framework上でのAdaptive playbackが正式にサポートされました。Adaptive playbackとは、MPEG-DASHやその他のフォーマット向けビデオデコーダーのオプション機能で、動画再生中にシームレスな解像度変更を可能にします。クライアントは、新しい解像度や自動的に変更された出力バッファの解像度に応じた動画フレームを、遅延なく入力するデコーダーを提供できます。

Android 4.4での解像度切り替えは、大きく向上したストリーミング再生をMediaアプリに提供します。アプリでは、Adaptive playbackが既存APIを使ったランタイムでサポートされているかどうか確認し、Android 4.4で提供された新しいAPIを使うことで解像度切り替えを実装することができます。

DASH向けの共通暗号化

MPEG-DASH向けの共通暗号化(CENC)を新たにサポートしました。CENCは標準的で、コンテンツ保護を管理するためのマルチプラットフォームのDRMスキームを提供します。アプリは、AndroidのモジュラーDRMフレームワークと、DASHをサポートしたプラットフォームAPIを通じて、CENCを活用することができます。

HTTPライブストリーミング

Android 4.4では、プラットフォームのHTTPライブストリーミング(HLS)がHLS仕様Ver.7(プロトコルVer.4)の上位セットをサポートするよう更新されました。詳細はIETFドラフトをご確認ください。

DSPへのオーディオトンネリング

高品質で省電力のオーディオ再生向けに、Android 4.4では、デバイスチップセットのDigital Signal Processor(DSP)をトンネリングしたオーディオ再生がサポートされました。オーディオトンネリングによって、オーディオのデコーディングと出力効果をDSPに任せることができ、アプリケーションプロセッサーの起動を減らすことで、バッテリー消費が抑えられます。

オーディオトンネリングは、画面OFFでヘッドセットで音楽を聴いているようなケース時に、劇的にバッテリー消費を改善します。例えばオーディオトンネリングを使用したNexus 5では、オフラインでのオーディオ再生時間が60時間まで提供でき、オーディオトンネリングを使用しない場合に比べて50%以上増加します。

メディアアプリケーションは、ソースコードを変更することなく、デバイスがサポートしているオーディオトンネリングを活用することができます。システムは、デバイス上で可能な場合いつでも、オーディオ再生を最適化するトンネリングを提供します。

オーディオトンネリングはデバイスのハードウェアのサポートが必要です。現在、オーディオトンネリングはNexus 5で動作可能で、可能な限り多くのデバイスで動作できるように、チップセットのパートナーと協力して作業をしています。

オーディオモニタリング

アプリは、現在再生しているオーディオのピークとRMSレベルの値を取得し、ビジュアライザー効果上での監視ツールを使用することができます。例えば、独創的なミュージックビジュアライザーや、メディアプレイヤーでの再生メーターの実装で使用することができます。


ラウドネスエンハンサー

メディア再生アプリケーションは、新しいラウドネスエンハンサー効果を使用することで、音声コンテンツの音量を上げることができます。ラウドネスエンハンサーは、特に音声の調整向けの時定数コンプレッサーとして動作します。

改善されたAV同期用のオーディオタイムスタンプ

オーディオフレームワークは、最善のAV同期のために、オーディオ出力からアプリへのタイムスタンプを通知します。オーディオタイムスタンプは、特定のオーディオフレームが現れる(または現れた)のをいつユーザーに通知するか、アプリに決定させます。タイムスタンプ情報は、オーディオとビデオフレームを正確に同期させるために使用することができます。

Wi-Fi公認のMiracast™

Android 4.4のデバイスは、Miracast互換のWi-Fiアライアンス表示仕様の認定を受けることができます。テスト支援用に、新しいワイヤレス表示開発機能は、ワイヤレス表示認証のための高度なコンフィグレーション操作と設定が提供されています。Settings内のDeveloper options > Wireless display certificationから、アクセスすることができます。Nexus 5はMiracastの認定を受けたワイヤレス表示デバイスです。

RendorScript Compute

継続的なパフォーマンスの向上

あなたのアプリがレンダースクリプトを使用するとき、再コンパイルする必要もなく、レンダースクリプトランタイムの継続的なパフォーマンス調整の恩恵を受けることができます。右のグラフは、よく知られている2つのチップセット上でのAndroid 4.4のパフォーマンス向上を示しています。

GPUアクセラレーション

GPUアクセラレーションがサポートされているデバイス上で、レンダースクリプトを使用するどんなアプリでは、コードの変更や再コンパイルは不要です。初めてレンダースクリプトGPUをサポートしたNexus10以降、様々なハードウェアパートナーがサポートを追加しました。

現在のAndroid 4.4において、GPUアクセラレーションはNexus 4、Nexus 7(2013)、Nexus 10と同様にはNexus 5に使用できます。私たちはできるだけ早く多くのデバイスで動作できるように、パートナーと協力して作業をしています。

Android NDKでのレンダースクリプト

ネイティブコードから直接レンダースクリプトを活用することもできます。Android NDKの新しいC++のAPIでは、スクリプトの組み込み関数、カスタムカーネルを含むframework APIを介して、同じようなレンダースクリプトの機能を使用できます。
もしあなたがネイティブコードで大規模なパフォーマンス集中型のタスクを持っている場合は、レンダースクリプトを使用したタスクを実行することで、ネイティブコードの中でそれらを統合できます。レンダースクリプトは、マルチコアCPU、GPU、そのほかのCPUの自動的なサポートによって、多くのデバイスで優れたパフォーマンスを提供します。

NDKを介したレンダースクリプトを使用するアプリをビルドするとき、framework API向けのレンダースクリプトサポートライブラリと同じように、Android 2.2以上が動作するデバイスに配布することができます。

Graphics

GLES 2.0 Surface Flinger

Android 4.4ではSurface FlingerがOpen GL ES 1.0からES 2.0にアップグレードしました。マルチテクスチャリングを使用することでパフォーマンスが向上し、カラーキャリブレーションを改善し、より高度な特殊効果をサポートしました。

仮想ディスプレイ向けの新しいHardware Composer

AndroidのHardware Composerの最新バージョン1.3では、プライマリな外部ディスプレイ(HDMIのような)に加えて、仮想ディスプレイのハードウェア構成をサポートし、Open GL ESの相互運用性を向上しました。

Except as noted, this content is licensed under Creative Commons Attribution 2.5. For details and restrictions, see the Content License.

Android 4.4 Kitkat詳細（開発者向けハイライト・その２）

Android

原文：Android KitKat  |  Android Developers

ストレージアクセスフレームワーク


新しいストレージアクセスフレームワークは、ユーザーが推奨されているドキュメントストレージプロパイダーの全てでドキュメント・画像・その他のファイルを閲覧、開くことが簡単になります。標準の利用しやすいUIは、ユーザーにアプリやプロバイダーを一貫した方法で、ファイルや最近のアクセスを閲覧させます。

クラウドやローカルストレージサービスは、サービスをカプセル化する新しいドキュメントプロバイダークラスを実装することによって、このエコシステムに関わることができます。プロバイダークラスには、プロバイダーをシステムに登録し、プロバイダーでドキュメントを閲覧、読み込み、書き込みに使う、必要とされるAPIの全てがあります。ドキュメントプロバイダーは、テキスト、写真、壁紙からビデオ、オーディオ、その他色々まで、ファイルとして表されることができるどんなリモートデータ・ローカルデータでもユーザーが利用できる機会を与えます。

クラウドもしくはローカルサービスに対してドキュメントプロバイダーを構築するなら、存在するアンドロイドアプリの一部として、ユーザーへ配信できます。アプリをダウンロードそしてインストールした後、ユーザーはフレームワークを共有するあらゆるアプリからサービスに、すぐにアクセスできるでしょう。ユーザーがより簡単にあなたのサービスを見つけやすくできます。

ファイルやドキュメントを管理するクライアントアプリを開発するなら、ファイルを開いたり作るときに、新しいCREATE_DOCUMENTもしくはOPEN_DOCUMENTインテントを使うことで、ストレージアクセスフレームワークを一体化させることができます。そのシステムはドキュメントプロバイダーを全て使用することも含め、自動的にドキュメントを閲覧するための標準ＵＩを表示します。

ベンダー独自のコードなしで、全てのプロバイダー用に、クライアントアプリを一回統合できます。ユーザーはプロバイダーを追加または削除するにつれて、コードで必要とされる変更もしくは更新なしで、アプリから推奨されるサービスにアクセスし続けられるでしょう

ストレージアクセスフレームワークは、存在するGET_CONTENTインテントと統合されます。そして、ユーザーもまた閲覧するための新しいシステムＵＩから以前の内容もしくはデータソースの全てにアクセスします。データをユーザーに取りこませる手段として、アプリはGET_CONTENTを使用し続けます。ストレージアクセスフレームワークと閲覧するためのシステムＵＩは　広範囲のソースの領域から、のデータを見つけ取り込むことを、ユーザーにとって簡単にさせます。

ほとんどのAndroid4.4が動作するデバイスには、グーグルドライブとドキュメントプロバイダーとしてのあらかじめ統合されたローカルストレージが含まれており、ファイルと連携するグーグルアプリもまた新しいフレームワークを使います。

低電力センサー

センサーバッチ処理

Android 4.4はハードウェアセンサーの一括処理を行うためのプラットフォームのサポートが導入されました。劇的に起動中のセンサーによって消費される電力を削減する事ができます。

センサーバッチ処理では、Androidはバッチ処理で効率的にセンサーイベントを収集、提供するために、デバイスのハードウェアで動作します。これはバッチ処理が配信されるまで、デバイスのアプリケーションプロセッサが低電力アイドル状態に留まることができます。

あなたは、標準的なイベントリスナーを使用して、任意のセンサーからバッチイベントを要求することができます、そしてあなたはバッチを受信する間隔を制御することができます。また、バッチサイクル間のイベントの即時配信を要求することができます。

センサーバッチ処理は、フィットネス、位置追跡、監視、および多くのような低消費電力、長時間実行されているユースケースに最適です。それはあなたのアプリケーションがより効率的にすることができ、継続的にセンサーのイベントを追跡することができます。-- 画面がオフになっている間、システムが眠っている間も。

センサーバッチ処理は現在Nexus 5 利用可能です。我々はできるだけ早く、より多くのデバイスに搭載するためにチップセットのパートナーと協力しています。

歩行検知 と 歩数計




Android 4.4 には2つの新しい複合センサー用のプラットフォームのサポートが追加されます。- 歩行検知と歩数計 - ユーザーがウォーキングランニング、または階段を登っているときにあなたのアプリケーションで歩みを検知してみましょう。これらの新しいセンサーは、低電力化のためにハードウェアに実装されています。

歩行検知は、ユーザが一歩を踏み出した事を認識するために加速度計入力を解析して、その後、一歩一歩でイベントをトリガします。歩数計は、最後のデバイスのリブート以降の歩数の合計数を追跡し、歩数の変化でイベントをトリガします。ロジックとセンサ管理、プラットフォームおよび基礎となるハードウェアに組み込まれているので、 あなたのアプリで、独自の検出アルゴリズムを実現する必要はありません。

歩行検知と歩数計はNexus 5で利用可能です。我々はできるだけ早く、新しいデバイスに搭載するためにチップセットのパートナーと協力しています。

SMSプロバイダ

もしSMSやMMSを利用するアプリケーションを開発する場合は、共有SMSプロバイダ および 新しいAPIをアプリケーションのメッセージストレージおよび検索の為に使用することができます。新しいSMSプロバイダと新APIは全てのSMSおよびMMSアプリケーションをハンドルする標準的なインターアクションモデルとして定義されています。

新しいプロバイダおよびAPIに沿ったAndroid 4.4は、新プロバイダ用のメッセージ受信・書き込み用の新セマンティックスを紹介しています。メッセージを受信した際、システムはそれを直接ユーザのデフォルトに設定されているSMS_DELIVERインテントを使用しているアプリケーションに送ります。

また、システムはデフォルトのアプリケーションのみに、プロバイダにメッセージデータを書き込むことを許容します。しかしながら、他のアプリケーションからでも読み込みは常に可能です。ユーザーがデフォルトと設定していないアプリケーションもメッセージを送信することが可能です。システムがメッセージの書き込みを、プロバイダがアプリの代理としてハンドリングし、ユーザはそれをデフォルトのアプリケーションで見ることができます。

新プロバイダとセマンティクスは、複数のメッセージングアプリケーションがインストールされていたときにユーザエクスペリエンスを向上させ、フルサポート、フォワードコンパチブルAPIといった新しいメッセージング機能を組み立てるのを助けてくれるでしょう。

美しいアプリケーションを構築するための新しい方法

フルスクリーン没入モード


今、あなたのアプリはデバイスの画面上のすべてのピクセルを使用してコンテンツを表示したり、タッチイベントをキャプチャすることができます。Android4.4を使用すると、、携帯電話やタブレットで端から端まで達する、ステータスバーやナビゲーションバーなど、すべてのシステムのUIを非表示にした、フルブリードUIを作成できる新しいフルスクリーン没入モードが追加されます。それは、そのような写真、ビデオ、地図、書籍、ゲームなどの豊富なビジュアルコンテンツのために理想的です。

新しいモードでは、ユーザーがアプリやゲームと対話している間でも、システムのUIは、隠されたままです - システムバーによって占有される領域であっても、画面上のどこからでもタッチイベントをキャプチャすることができます。これは、あなたのアプリやゲームが大きく、よりリッチで没入型のUIを作成し、視覚的な散漫を軽減するための素晴らしい方法を提供します。

ユーザーがフルスクリーン没入モードからシステムUIへの一貫したアクセスを容易に行えるように、Android4.4は新しいジェスチャーをサポートしています。-没入モードでは、画面の上部または下部の端をスワイプすると、システムUIが表示されます。

バーの外側をタッチするか、自動的に非表示されるまで短時間待つことで没入モードに戻ります。一貫したユーザーエクスペリエンスのために、新しいジェスチャーもまたステータスバーを隠す従来の方法でも動作します。

アニメーションシーン遷移フレームワーク

ほとんどのアプリケーションが異なった動作を現すいくつかの主要なUI周りで、それらのフローを構造化します。多くのアプリケーションが、進捗状態及びその時に可能なアクションをユーザーが理解するのを助ける為にアニメーションを使用します。あなたのアプリに高品質なアニメーションをより簡単に作成することができるように、Android4.4は新しい遷移フレームワークを導入します。

遷移フレームワークを使用すると、ユーザーがそれらを開始または終了した時に、シーンをアニメーション化または変換する方法を説明する一般的な表示階層や推移について、あなたがシーンを定義出来ます。
このようなレイアウトの境界、または可視性などの特定の特性に基づいてあなたのシーンをアニメーション化するいくつかの定義済みのトランジションタイプを使用することができます。自動トランジションタイプは、シーンチェンジ時に自動的にフェード、移動し、サイズを変更します。また、あなたは、あなたのアプリケーションに最も重要なプロパティをアニメーション化するカスタムトランジションを定義することができます。必要に応じて、あなた自身のアニメーションのスタイルでプラグインすることができます。

遷移フレームワークを使用すると、シーンを定義することなく、その場であなたのUIの変更をアニメーション化することができます。例えば、トランジションマネージャに表示階層への一連の変更を実行し、次に遅れた遷移をそれらの変化に自動的に実行させることができます。

あなたはトランジションを設定したら、アプリから簡単にそれらを呼び出すことができます。たとえば、あなたの表示階層内の様々な変更を行い、移行を開始するために単一のメソッドを呼び出すことができ、次のフレームのアニメーションで自動的に指定された変更がアニメーション化されます。

独自のアプリケーションフローでの特定のシーンとシーンの遷移のカスタムコントロールの為にTransitionManagerを使用することが出来ます。TransitionManagerは、あなたがシーンと特定のシーンの変更を実行する遷移の間の関係を定義することができます。

半透明のシステムUIスタイリング


あなたのコンテンツに最大のインパクトを与える為、半透明のシステムUIを用性する為、最新のウィンドウのスタイルとテーマを使うことができます。ナビゲーションバーまたはステータスバーの情報を読みやすくする為に、絶妙なグラデーションをシステムバーの背景に表示します。典型的な使用例としては、壁紙が透けて見える必要のあるアプリです。

強化された通知のアクセス

通知リスナーサービスは、通知ビルダーAPIを使用して構築された着信通知の詳細情報を参照することができます。リスナーサービスは、通知の行動だけでなく、新たなエクストラフィールドにアクセスすることができます。 - テキスト、アイコン、画像、進歩、クロノメーター、その他諸々 - 通知に関するきれいな情報を抽出し、別の方法で情報を提示します。

Chromium WebView


Android4.4は、完全に新しいChromiumベースのWebViewが実装されています。新しいChromium WebViewは、標準のサポート、パフォーマンス、およびWebベースのコンテンツを作成および表示するための互換性の最新情報を提供します。Chromium WebViewは、HTML5、CSS3、およびJavaScriptのための広範なサポートを提供します。これは、Chrome for Android 30で利用できるHTML5の機能のほとんどをサポートしています。また、JavaScriptエンジン（V8）の更新版をもたらし、それが劇的に改善されたJavaScriptのパフォーマンスを提供します。

さらに、Chromium WebViewはChrome DevToolsを使用してリモートデバッグをサポートしています。例えば、開発マシン上でChrome DevToolsを使用し、検査、デバッグや解析を実際の端末のWebView上で行うことができます。

新しいChromium WebViewは、Android4.4以降を実行するすべての互換性のあるデバイスに含まれています。あなたは、既存のアプリケーションやコンテンツへの最小限の変更で、すぐに新しいWebViewを活用することができます。ほとんどの場合、あなたのコンテンツがシームレスに新しい実装に移行します。

Except as noted, this content is licensed under Creative Commons Attribution 2.5. For details and restrictions, see the Content License.

Android 4.4 Kitkat詳細（開発者向けハイライト・その１）

Android

原文：Android KitKat  |  Android Developers

全ての人にAndroidを


Android 4.4は速く滑らかに、そして反応しやすいように、512MB RAMと同じくらいの小ささを持つ、世界各国の無数の初心者向けの端末を含む、従来の端末よりもより広い範囲で動作することを目指しています。KitKatは、メモリ使用を縮小するためすべての主要コンポーネントを無駄をなくして合理化し、新しいAPIと革新的で、反応が早く、省メモリなアプリケーションを作り出すのに役立つツールを導入します。

Android端末の次世代を築くOEMは、目標とされた長所やオプションを、ローメモリ装置上でさえも、効率的にAndroid4.4を動作するためにうまく利用することができます。Dalvik JITコード・キャッシュ・チューニング、Kernel Samepage Merging（KSM)、zRAM用のスワップおよび他の最適化は、メモリの管理に役立ちます。新しい構成オプションは、プロセスに関してのメモリ不足レベル、画像キャッシュサイズの設定、メモリ再要求の制御、その他色々、をOEMに調整させます。

アンドロイド自体では、システムの変更はメモリ管理を改善し、メモリ領域を縮小します。コアシステムプロセスはより少ないヒープを使うために調整され、そして、大量のRAMを消耗させるアプリから、より積極的にシステムメモリを保護します。多数のサービスが同時にスタートする時（例えば、ネットワーク接続が変わる場合）、アンドロイドは最大メモリ要求を回避するために、小さなグループで、順次にサービスを起動します。

デベロッパーにとって、Android 4.4 は全ての端末で効率的で反応の早いアプリの提供に役立ちます。新しいAPI（ActivityManager.isLowRamDevice()）はデバイスのメモリ構成を一致させるためにアプリの動作を調整させます。デベロッパーは、必要に応じ大容量メモリの特徴を変更および無効にすることができます。ローメモリ装置のためにアプリを最適化することについては、他の節を参照してください。

新しいツールはアプリのメモリ使用に対する強力な洞察力を与えます。procstatsツールは徐々にメモリ使用を、フォアグランドサービスとバックグラウンドサービスに関して実行時間とメモリ領域とともに、詳しく記述します。
さらに、on-device viewもまた新しい開発者オプションとして利用できます。meminfoツールはメモリの傾向や結果に気づくことが容易になることが強化され、それは、あらかじめ明白だった追加のメモリーオーバーヘッドを公開します。

NFCの新機能としてHostCardエミュレーション機能が搭載されます


Android 4.4は、セキュアNFCベースのHost Card Emulation(HCE)のトランザクション処理をサポートする新しいプラットフォームを紹介しています。
これらはpayments,loyality programs,card access,transit passesやその他のカスタムサービスに使用できます。
HCEを使用すれば、Androidデバイス上で動くどんなアプリケーションでもNFC smart cardをエミュレートすることができ、ユーザはタッチすることで選択したアプリケーションのトランザクションを開始することができます。secure element(SE)を搭載した端末でなくても可能です。アプリケーションはHCEカードや他のNFCベースのトランザクションのReaderとしてReader Modeを使用する事もできます。

Android HCEは、contactless ISO/IEC 14443-4 (ISO-DEP) protocolを使用しているISO/IEC 7816をベースとしたSmart Cardをエミュレートします。昨今では、これらのカードは多くのシステムで使用されており、EMVCO NFC決済環境を搭載しています。Android uses Application Identifiers (AIDs) では、ISO/IEC 7816-4をAndroidアプリケーションのトランザクション処理の基準として定義しています。

アプリケーションはマニフェストファイル中で、対応しているカテゴリー("payments"など)の識別子をAIDsとして宣言します。複数のアプリケーションが同一のAIDかつ同一のカテゴリをサポートしていた場合、Androidはダイアログ画面を表示し、ユーザに使用するアプリケーションを選択させます。

ユーザが、POS端末を支払い目的でタッチした場合、システムは推奨するAIDやRouteを正しいアプリケーションにトランザクションするために引用してきます。アプリケーションはトランザクションデータを読み、全てのローカルもしくはネットワークベースのサービスを検証することができ、その後トランザクションを完了します。

Android HCEは、NFC ControllerをPresentとするデバイスを必要とします。HCEのサポートはすでに広く主なNFC Controllerで可能となっており、HCE・SEトランザクションの両方に動的なサポートが提供されています。NFCがサポートされたAndroid4.4デバイスは、HCEを使用した簡易決済の為に、タッチおよび支払い機能を含むこととなります。

印刷フレームワーク


Androidアプリから、Wi-FiやGoogleクラウドプリントなどのクラウドでホストされるサービスを介して、任意の様々な形式のコンテンツの印刷が可能となります。
印刷対応のアプリケーションでは、ユーザーは利用可能なプリンタを発見し、用紙サイズの変更や特定のページ選択ができ、文書、画像、または、ほとんどすべての種類のファイルを印刷することができます。

Android4.4は、印刷をサポートするネイティブプラットフォームが導入され、印刷の管理とプリンタサポートの為の新しいAPIが追加されました。プラットフォームは、アプリケーション間の印刷要求を仲介するプリントマネージャと、印刷要求をハンドルするプリントサービスが提供されます。プリントマネージャは、印刷の為の共有サービス及びシステムUIが提供され、ユーザーに様々なアプリケーションから一貫性のあるコントロールが可能となります。

また、プリントマネージャは、プリントサービスを通じてプロセス間で渡されたコンテンツのセキュリティを確保します。プリンタメーカーは、独自のプリントサービス-ベンダー固有のロジックや特定のタイプのプリンタと通信するためのサービスを追加するプラグイン可能なコンポーネント-を開発するために新しいAPIを使用することができます。彼らは、簡単にユーザーが検索しデバイスにインストール出来るように、Google Playを介してそれらを配布することが出来ます。他のアプリと同じように、いつでもOTAでプリントサービスを更新することが出来ます。

クライアントアプリケーションは、最小限のコード変更で自分のアプリに印刷機能を追加するために新しいAPIを使用することができます。ほとんどの場合、印刷実行と印刷する項目を選択するUIをアクションバーに追加するでしょう。

また、印刷ジョブを作成したり、ステータスをプリントマネージャに問い合わせたり、ジョブをキャンセルするAPIを実装するでしょう。これは、ほぼ全てのタイプのコンテンツを印刷できます。ローカル画像やネットワークからのドキュメント、キャンバスにレンダリングされたビューなど。

広い互換性のために、Androidは印刷用のプライマリファイル形式としてPDFを使用しています。アプリは、印刷前に適切にページ設定されたPDF版を生成する必要があります。便宜上、印刷APIを使用すると、標準的なAndroidの描画APIを使用してPDFを作成できるように、ネイティブとWebViewのヘルパークラスが用意されています。アプリがコンテンツを描画する方法を知っている場合、それはすぐに印刷用PDFを作成することができます。

Android4.4が動作するほとんでのデバイスでは、Googleクラウドプリントプリントサービスだけでなく、Google Chrome、Google Drive、ギャラリーやQuickOfficeなどいくつかのGoogleのアプリとしてプリインストールされているアプリが印刷をサポートしています。

Except as noted, this content is licensed under Creative Commons Attribution 2.5. For details and restrictions, see the Content License.