コンテナ内のBYOD：Androidを仮想化します。 パート2

私は、 Parallels Labs で、サンクトペテルブルクアカデミック大学のMIIT学部の学生グループがマスターの仕事の一部として作成したAndroid仮想化テクノロジーについての話を続けています。 昨日の記事では、これを可能にするAndroidベースのデバイスの仮想化の一般的な概念を検討しました。 今日の投稿の目標は、電話、音声、およびユーザー入力システムの仮想化に対処することです。







オーディオとテレフォニーはユーザー空間で仮想化されました。 このような仮想化の一般的な考え方は、Androidスタック内のデバイスに依存しないインターフェイスのレベルでプロキシ（サーバーとクライアント）を実装することです。 プロキシサーバーは、物理デバイスでクライアント要求を実行するために、元のソフトウェアオペレーティングシステムスタックとは別のコンテナーに配置されます。 プロキシクライアントは、Androidユーザーと共に各コンテナでホストされます。

オーディオ機器

複数のAndroidを実行しているときにオーディオデバイスを使用する一般的なシナリオは、OSの1つで音楽を聴き、別のOSで実行中のゲームのサウンドを再生することです。 ユーザーはおそらく実行中のすべてのAndroidのサウンドを聞きたいと思うでしょうが、実際には物理的なサウンドデバイスはそのために設計されていません。 使用しようとすると、OSがエラーを報告し、次の再起動までサウンドを再生できない場合があります。 オーディオデバイスの仮想化は、すべてのAndroidのサウンドを同時に聴く機能を提供する必要があります。



また、電話通話中にオーディオデバイスがユーザーの音声を録音してセルラーネットワークに送信し、セルラーネットワークから受信した対話者の音声を再生できるように、テレフォニーサービスとの対話を実装する必要があります。

プロキシクライアント

ハードウェアに依存しないオーディオデバイスへの代替インターフェイスは、Androidプラットフォーム開発者ガイドに記載されているように、AudioHardwareInterfaceインターフェイスです。 さらに、これは最も低レベルで最も単純なハードウェア独立のオーディオインターフェイスです。 実際、これは再生用のサウンドを記録するためのストリームです。 Androidで再生されるサウンドストリームに加えて、その実装では他の有用な情報を取得できます。



より高いレベルで置換を行うことができます。 たとえば、Androidオーディオフレームワークの一部を置き換える場合。 しかし、分析では、オーディオフレームワークはAudioHardwareInterfaceよりもはるかに複雑であることが示されました。 したがって、仮想化オーディオデバイスの場合のプロキシクライアントは、AudioHardwareInterfaceの実装です。



プロキシクライアントの主な役割は、Androidオーディオストリームとその他の有用な情報をプロキシサーバーに送信することです。プロキシサーバーは、すべてのAndroidのオーディオストリームを再生します。 サウンドストリームは非圧縮形式で再生されるため、プロキシサーバーへのコピーを使用した転送では、顕著なオーバーヘッドが発生する可能性があります。 オーディオストリームを送信するためにコンテナ間共有メモリを使用しているため、これらは回避されます。 情報および制御メッセージは、コンテナ間メッセージングのメカニズムを使用して送信されます。

プロキシサーバー

プロキシサーバーの主なタスクは、プロキシクライアントから受信したサウンドストリームをミックスし、結果のサウンドストリームを物理的なオーディオデバイスで再生することです。 プロキシサーバーの移植性を最大限に確保するには、サウンドのミキシングと再生がデバイスに依存しないようにする必要があります。 Androidオーディオフレームワークインターフェイスはハードウェアに依存しません。 さらに、オーディオフレームワークには既にサウンドストリームをミックスする機能があります。 Androidオーディオフレームワークは、外部からミキサーへのアクセスを提供しないため、使用するには、オーディオフレームワークに統合するか、暗黙的にミキサーを使用する必要があります。 健全な仮想化ソリューションのアーキテクチャを図に示します。







Androidでサウンドをミックスして再生できる最も簡単なソリューションは、Android SDKのオーディオクラスを使用することです。 このソリューションでは、各ユーザーのサウンドストリームは、Android SDKのAudioTrackクラスの個別のオブジェクトによって再生されます。 クラスを使用すると、Androidオーディオフレームワークは再生されたすべてのオーディオストリームをミックスし、結果のオーディオストリームをデバイスのスピーカーまたはヘッドフォン出力に送信できます。



Android SDKのクラスはJavaで記述されており、使用するにはDalvik仮想Javaマシンを実行する必要があることに注意してください。 Androidの場合にDalvikを実行するということは、ブートストラップなどのメカニズムを使用してOS全体を起動することを意味します。 ここで問題に直面しています。Androidを実行すると200〜250 MBのRAMを占有し、コンピューティングリソースを消費します。 これらは、サウンドストリームの再生とミキシングのタスクには許容できないオーバーヘッドですが、この作業では回避されました。 実際、Android SDKのJavaクラスではなく、C ++で記述されたネイティブバックエンドを使用しています。 これが、完全なAndroidコンテナの起動を意味するDalvikを起動する必要がない理由です。



プロキシサーバーなどの完全にネイティブなアプリケーションは、Androidの権利管理システムに登録できません。 同時に、プロキシサーバーによってアクセスされるサービスは、権限がないため静かにリクエストを無視しました。 これらのサービスの権利チェックを削除することですべてが決定されました。 この削除はセキュリティに影響を与えないため、このトリックは冷静に行いました。 無関係なアプリケーションは、プロキシサーバーを備えたコンテナで実行されることはありません。完全に仮想化テクノロジーの制御下にあります。

サウンドレベルコントロール

ユーザーはおそらく、さまざまなAndroidの音量を調整したいと考えています。 Android 2.xでは、ハードウェアミキサーの抽象化は行われていないことがわかりました。 混合はCPUを介して行われます。 各Android内のサウンドストリームのミキシングは完全に独立しているため（共通の共有ハードウェアミキサーはありません）、各Androidの全体的な音量レベルはAndroid自体で調整できます。 プロキシサーバーは単に各OSのサウンドレベルを変更せず、ユーザーはユーザーインターフェイスで各Androidのサウンドレベルを設定します。これは、電話に仮想化が存在しないかのようです。

音声出力デバイス

通常、モバイルデバイスには複数のオーディオ出力デバイスがあります。 たとえば、大きなスピーカー、ハンドセット、ヘッドフォン、Bluetoothヘッドセット。 起動したオペレーティングシステムでは、異なる出力デバイスでサウンドストリームを同時に再生する必要があります。 場合によっては、要件に互換性がありません。 たとえば、1つのサウンドを大きなスピーカーで再生し、もう1つのサウンドをヘッドフォンまたはハンドセットで再生することは意味がありません。 また、通話中に、通話者の声が受信機で聞こえるだけでなく、通話前に再生される音楽も聞こえます。



そのため、オーディオストリームをさまざまな出力デバイスにルーティングするためのポリシーが開発され、ユーザーの「最小限の驚き」の戦略が実装されました。 この戦略の一部として、特に、Androidのサウンドをシミュレートしたい場合があります。 これを行うには、プロキシクライアントを架空の再生モードにします。このモードでは、オーディオストリームの再生部分の間、同期機能がブロックされます。したがって、Androidは、実際には再生のためにプロキシサーバーに移動しませんでしたが、サウンドを再生したと見なします。

テレフォニーサービスとの相互作用

AudioHardwareInterfaceの実装であるプロキシクライアントでは、会話が現在電話中かどうかに関する情報を取得できます。 会話が進行中の場合、音声を録音および再生し、テレフォニーサービスと対話するようにオーディオサブシステムを構成する必要があります。 実際、これには、setModeメソッド（MODE_IN_CALL）を呼び出してデバイスに付属するAudioHardwareInterface実装を呼び出しモードにし、ハンドセットへのサウンドルーティングを設定するだけで十分です。そうしないと、対話者の音声が現在のサウンド出力デバイスで再生されます したがって、デバイスのサプライヤは、テレフォニーサービスとの対話の実装を担当します。

テレフォニー

最も興味深い複雑な技術は、コンテナ間の電話の発信でした。 Androidのモバイルネットワークにアクセスするためのソフトウェア機器管理スタックには、次のコンポーネントが含まれています。



1. APIパッケージcom.android.internal.telephony。

2. rildデーモン。モバイルネットワークアクセス機器でユーザーアプリケーション要求を多重化します。

3.独自の機器アクセスライブラリ。

4. GSMモデムドライバー。



コンポーネント（2）と（3）間のインターフェースは文書化されており、Radio Interface Layer（RIL）と呼ばれます。 ファイルdevelopment / pdk / docs / porting / telephony.jdで説明されています。



仮想化のために、RILは次の問題を解決する必要がありました。

さまざまなAndroidでの独自のRIL実装は、機器の再初期化を試みます。

どのAndroidが着信呼び出しとSMSを受信する必要があるかは明確ではありません。

さまざまな「Android」からの通話とSMSを管理する方法は不明です。



また、GSMモデムのドライバーの実装はデバイスによって大きく異なるため、カーネルでこのデバイスを仮想化するためのユニバーサルソリューションの存在は不可能です。 さらに、独自のRILライブラリは、ドキュメント化されていないプロトコルを使用してGSMモデムと対話します。これは、特定のスマートフォンモデルでも仮想化の障害となります。

クライアント部

電話でのRILライブラリの具体的な実装は不明ですが、そのインターフェイスは既知です。 仮想RILプロキシおよびRILクライアントとして抽象化レイヤーを作成しました。 クライアント側では、元のRILライブラリの代わりにrildデーモンが、実装したRILクライアントをロードします。 RILクライアントは、インターフェイスへの呼び出しをインターセプトし、コンテナー間の相互作用RILプロキシのメカニズムを使用して呼び出しを送信します。これにより、メインインターフェイスが仮想化され、元のRILライブラリを使用してテレフォニーにアクセスします。

サーバー側

サーバー部分は、RILの独自の実装をダウンロードするシングルスレッドアプリケーションとして実装され、コンテナー間の相互作用のメカニズムを使用して、ユーザーコンテナーで動作するプロキシクライアントからメッセージを受信します。 OnRequestCompleteハンドラーでは、リクエストのタイプはわかりませんが、独自のRIL実装のレスポンスをパックする方法はそれに依存するため、リクエストが到着すると、サーバーはこのハンドラーで必要なレスポンスマーシャラーを呼び出すためにリクエスト番号に一致するトークンを記憶します。RILプロキシサーバーは、クライアントは同じトークンのリクエストを受信するため、次のリクエストが到着すると、プロキシサーバーはRIL独自のライブラリによって処理されたリクエストトークンのリストをスキャンします。 このようなトークンを含むリクエストは現在処理されているため、サーバーは着信リクエストに対して新しいトークンを生成します。 したがって、すべての着信要求のプロキシサーバーは、実際のトークンとダミートークンを格納します。

ルーティングポリシーのリクエスト

OnRequestが受信するリクエストのタイプごとに、処理ポリシーが定義されます。 現在、3つのポリシーが定義されています。

• 無条件のリクエストのブロック。 このポリシーは、プロキシサーバーの開発中に検出されたことのないすべての要求に対して設定されます。
• 独自のライブラリへのリクエストの無条件転送。 このポリシーは、独自のライブラリとGSMモデムの状態を変更しないすべての要求に適用されます。
• アクティブなコンテナから独自のライブラリにリクエストを転送します。 SMSの送信と電話の発信に関連するリクエストを処理します。

非同期通知のタイプごとに、そのルーティングポリシーも定義されます。

• 通知の無条件のブロック。
• アクティブなコンテナへのルーティング。 このポリシーは、SMSおよび通話の受け入れに関連する通知に対して設定されます。
• すべてのコンテナへのルーティング。 サービス通知「ハードウェア」の場合-たとえば、セルラーネットワークの信号レベルの変化について。

入力サブシステム

Androidはevdevサブシステムを使用して、カーネル入力イベントを収集します。 ファイル/ dev / input / eventXを開くプロセスごとに、このドライバーは入力サブシステムのカーネルからのイベントのキューを作成します。







このようにして、着信入力イベントをすべてのコンテナに配信できます。 evdev_event（）関数は入力イベントディスパッチャーであるため、非アクティブなコンテナーへの入力メッセージの配信を防ぐために、この関数が変更され、すべての入力イベントがアクティブなコンテナーのプロセスキューにのみ追加されるようになりました。

テストについて少し

スマートフォンでソリューションを起動した後、ソリューションの特性を定量化するために一連の実験を行いました。 最適化に取り組んでいなかったとすぐに言わなければなりません-この作業はまだ行われていません。



テストの主な目的は次のとおりです。

• 開発された技術の準備状況のデモンストレーション;
• 仮想化された電話のメモリ消費量の測定。
• 開発された技術のエネルギー消費の決定。

次のスマートフォン使用シナリオに従って、Samsung Galaxy S IIスマートフォンでテストを実施しました。



1.シンプル（電話をオンにして何もしません）;

2.画面のバックライトをオンにして音楽を再生します。

3. Angry Birds（それらがない場合）および同時音楽再生。



テストスクリプトは、3つの構成で実行されました。

1. Samsung Galaxy S II用のCyanogenMod 7の元の環境（1）;

2. CyanogenMod 7（2）を含む1つのコンテナ。

3. CyanogenMod 7の2つのコンテナ：音楽は1つのコンテナで再生され、ゲームは他のコンテナで起動されました（3）



各テスト実行で、次のパラメーターが測定されました。

1.空きメモリの量とファイルシステムキャッシュのサイズ（情報/ proc / memrinfoによる）。

2.バッテリーの充電（/ sys / class / power_supply / battery /容量による）。



各テスト実行は30分間続き、測定は2秒の頻度で行われました。 取得したものは次のとおりです。







コンテナの場合のメモリ消費が実際の環境よりも少ないのは奇妙に思えるかもしれません。 正確な理由は確立されていません（まだ解明しようとしませんでした）が、同じ効果がCellsプロジェクトでも観察されています 。



テストでは、開発されたソリューションの許容性が示され、開発されたテクノロジーによるメモリとスマートフォンのバッテリーのわずかな消費が示されました。ただし、ケース（テーブルの最後の行）は例外です。 現在、この動作の理由を調べる作業が進行中です。



メモリ消費量の値からわかるように、2番目のコンテナーを起動すると、2倍以上増加します。これは、1つのスマートフォンで複数のコンテナーを起動する際の障害です。実験により、380 MBのGoogle Nexus Sスマートフォンは、ページングファイルのアクティブ化。

おわりに

現在、技術ニュースの大部分はモバイルデバイスを中心に生成されています。 学生グループの修士（または卒業証書）プロジェクトは、モバイルデバイスでの仮想化テクノロジの実行可能性を示し、このテクノロジを使用して製品を作成する方法のアイデアを示しました。



ソリューションの作成に関するいくつかの興味深い事実と数字：

• このプロジェクトの主な開発者は3人で、そのうち2人は作業時のサンクトペテルブルクのアカデミック大学の学生で、1人は卒業プロジェクトを主導しました。
• プロジェクトは11か月続きました。
• このプロジェクトは、Parallelsモスクワオフィスのエンジニアからのアドバイスによって支援されました。
• このプロジェクトには3つのAndroidデバイスが関係していました。

重要なことが舞台裏に残っている場合は、コメントで質問してください。 私はそれらに答えようとします。