🤲🏽 🚮 🐂 Androidの仕組み、パート1 🙋 🥄 😁

このシリーズの記事では、Androidの内部デバイスについて説明します-ブートプロセス、ファイルシステムのコンテンツ、バインダーとAndroidランタイム、アプリケーションの構成、インストール、実行、相互作用、Androidフレームワーク、 Androidのセキュリティ保護方法。

シリーズ記事：

いくつかの事実

Androidは、 20億人以上のアクティブユーザーがいる最も人気のあるオペレーティングシステムおよびアプリケーションプラットフォームです。「モノのインターネット」やスマートウォッチからテレビ、ラップトップ、車まで、まったく異なるデバイスを使用していますが、ほとんどの場合、Androidはスマートフォンやタブレットで使用されています。

Androidは無料のオープンソースプロジェクトです。ほとんどのソースコード（ https://source.android.comにあります）は、無料のApache 2.0ライセンスの下で配布されています。

Android Inc. 2003年に設立され、2005年にGoogleによって購入されました。 Androidパブリックベータは 2007年にリリースされ、最初の安定バージョンは2008年にリリースされました。それ以降、メジャーリリースは年に約1回リリースされます。執筆時点でのAndroidの最新の安定バージョンは7.1.2 Nougatです。

AndroidはLinux

この言い回しについて多くの論争があったので、このフレーズの意味をすぐに説明します。AndroidはLinuxカーネルに基づいていますが、他のほとんどのLinuxシステムとは大きく異なります。

元のAndroid開発チームの中には、Linuxカーネルの最も有名な開発者の1人であるRobert Loveがいましたが、今でもGoogleはカーネルへの最も積極的な貢献者の1つであるため、AndroidがLinux上に構築されていることは驚くことではありません。

他のLinuxシステムと同様に、Linuxカーネルは、メモリ管理、データ保護、マルチプロセッシングとマルチスレッドのサポートなどの低レベルのものを提供します。ただし、いくつかの例外を除いて、Androidには他の使い慣れたGNU / Linuxシステムコンポーネントはありません。GNUプロジェクトには何もありません。X.Orgは使用されず、systemdでさえありません。これらのコンポーネントはすべて、メモリが限られ、プロセッサの速度が遅く、消費電力が最小の条件での使用に適したアナログに置き換えられます。したがって、AndroidはGNU / Linuxよりも組み込みLinuxシステムに似ています。

AndroidがGNUソフトウェアを使用しないもう1つの理由は、よく知られている「ユーザー空間にGPLを使用しない」ポリシーです。

Apache Software License 2.0がAndroidの優先ライセンスである理由を尋ねられることがあります。ユーザースペース（つまり、非カーネル）ソフトウェアの場合、実際にはLGPLなどの他のライセンスよりもASL 2.0（およびBSD、MITなどの同様のライセンス）を優先します。

Androidは自由と選択の問題です。 Androidの目的は、モバイルの世界でオープン性を促進することであり、ユーザーがソフトウェアを使用するすべての用途を予測または指示することは不可能だと考えています。そのため、すべての人にオープンで変更可能なデバイスを作成することをお勧めしますが、そうすることを強制するのは私たちの場所ではないと考えています。 LGPLライブラリを使用すると、多くの場合、それらを強制的に実行します。

AndroidのLinuxカーネル自体も若干変更されています。ashmem （匿名共有メモリ）、Binderドライバー（以下で説明する大規模で重要なBinderフレームワークの一部）、wakelocks（スリープ管理）、lowなど、いくつかの小さなコンポーネントが追加されましたメモリキラー。最初は、カーネルへのパッチでしたが、コードはすぐにアップストリームカーネルに追加されました。ただし、「通常のLinux」ではこれらを見つけることができません。他のほとんどのディストリビューションでは、アセンブリ中にこれらのコンポーネントが無効になります。

AndroidはGNU Cライブラリ（ glibc ）をlibc（標準C言語ライブラリ）として使用しませんが、組み込みシステム向けに最適化されたbionicと呼ばれる独自の最小限の実装です。互換性の多くの層で大きくなりすぎています。

Androidにはコマンドラインシェルと、多くの標準的なUnixライクなコマンド/プログラムシステムがあります。組み込みシステムでは、通常Busyboxパッケージがこれに使用され、1つの実行可能ファイルで多くのコマンドの機能を実装します。 AndroidはToyboxと呼ばれる対応物を使用します。「通常の」Linuxディストリビューション（組み込みシステムとは異なります）と同様に、システムと対話する主な方法は、コマンドラインではなくグラフィカルインターフェイスを使用することです。それでも、コマンドラインにアクセスするのは非常に簡単です。ターミナルエミュレータアプリケーションを実行するだけです。デフォルトでは、通常はインストールされませんが、たとえばPlayストア（ Androidのターミナルエミュレーター、マテリアルターミナル、 Termux ）から簡単にダウンロードできます。 LineageOS （以前のCyanogenMod）など、多くの「高度な」Androidディストリビューションでは、ターミナルエミュレータがプリインストールされています。

2番目のオプションは、 Android Debug Bridge （adb）を介してコンピューターからAndroidデバイスに接続することです。これは、SSHを介した接続に非常に似ています。

user@desktop-linux$ adb shell android$ uname Linux

他の馴染みのあるコンポーネントのうち、AndroidはFreeTypeライブラリ（テキストの表示用）、 OpenGL ES 、EGL、およびVulkanグラフィックスAPI、および軽量のSQLite DBMSを使用します。

さらに、 WebKitブラウザーエンジンは以前にWebViewの実装に使用されていましたが、バージョン7.0以降では、インストールされたChromeアプリケーションが代わりに使用されます（または別の; WebViewプロバイダーとして機能することが許可されているアプリケーションのリストは、システムのコンパイルの段階で構成されます）。内部では、ChromeはWebKitベースのBlinkエンジンも使用しますが、システムライブラリとは異なり、ChromeはPlayストアを通じて更新されます。したがって、WebViewを使用するすべてのアプリケーションは自動的に最新の改善とバグ修正を受け取ります。

Androidテクノロジータタック

アプリがすべて

ご覧のとおり、Androidの使用は「通常のLinux」の使用とは根本的に異なります。アプリケーションを開いたり閉じたりする必要はなく、すべてのアプリケーションが常に実行されているかのように切り替えるだけです。実際、Androidのユニークな機能の1つは、アプリケーションが実行中のプロセスを直接制御しないことです。これについて詳しく説明しましょう。

Unixライクシステムの基本単位はプロセスです。また、低レベルのシステムサービス、シェル内の個々のコマンド、およびグラフィックスアプリケーションはプロセスです。ほとんどの場合、プロセスはシステムの残りの部分のブラックボックスです-システムの他のコンポーネントは、その状態を認識せず、気にしません。プロセスはmain()

関数main()

実際は_start

）を呼び出すことで開始し、独自のロジックを実装し、システムコールと単純なプロセス間通信（IPC）を介してシステムの残りの部分と対話します。

AndroidもUnixに似ているため、これもすべて当てはまりますが、低レベルの部分（Unixレベル）はプロセスの概念で動作し、より高いレベル（Androidフレームワークレベル）でメインユニットはアプリケーションです 。このアプリケーションはブラックボックスではありません。システムの他の部分によく知られている個々のコンポーネントで構成されています。

Androidアプリケーションにはmain()

関数がありません。1つのエントリポイントはありません。一般に、Androidは、ユーザーと開発者の両方から実行されるアプリケーションの概念を可能な限り抽象化します。もちろん、アプリケーションプロセスを開始および停止する必要がありますが、Androidはこれを自動的に実行します（これについては、以下の記事で詳しく説明します）。開発者は、それぞれ独自のライフサイクルを持ついくつかの個別のコンポーネントを実装するように招待されています。

ただし、Androidでは、プラットフォームでアプリの実行方法をより詳細に制御する必要があるため、main（）関数を使用しないことを明示的に決定しました。特に、ユーザーがアプリの起動と停止について考える必要がまったくないシステムを構築したかったのですが、むしろシステムがそれらの面倒を見てくれました...そのため、システムは各アプリ内で何が起こっているかについての情報をさらに持っていなければなりませんでしたアプリ、および現在実行されていなくても、必要なときにいつでもアプリをさまざまな方法で起動できます。

このようなシステムを実装するには、アプリケーションが相互に、またシステムサービスと通信できる必要があります。つまり、非常に高度で高速なIPCメカニズムが必要です。

このメカニズムはバインダーです。

バインダー

バインダーは、高速で便利でオブジェクト指向のプロセス間通信のためのプラットフォームです。

Be Inc.でバインダー開発が開始されました（BeOSの場合）、Linuxに移植されて開かれました。 Binderの主要な開発者であるDianne Hackbornは、Androidの主要な開発者の1人です。開発中に、Androidバインダーは完全に書き直されました。

BinderはSystem V IPC（bionicでもサポートされていない）上では動作しませんが、ユーザー空間が「仮想デバイス」 /dev/binder

システムコール（主にioctl

）を通じて対話する独自の小さなカーネルモジュールを使用します。ユーザースペース側から、 /dev/binder

との相互作用やデータのマーシャリング/アンマーシャリングなど、Binderの低レベルの作業がlibbinderライブラリに実装されています。

バインダーの低レベル部分は、プロセス間で転送できるオブジェクトの観点から動作します。この場合、参照カウントを使用して、未使用の共有リソースとリモートプロセスの完了通知（死へのリンク）を自動的に解放し、プロセス内のリソースを解放します。

バインダーの高レベルの部分は、インターフェイス、サービス、およびプロキシオブジェクトの観点から機能します。プログラムが他のプログラムに提供するインターフェースの説明は、Javaのインターフェースの宣言と非常によく似た特別な言語AIDL （Android Interface Definition Language）で記述されています。この説明によると、実際のJavaインターフェースが自動的に生成され、クライアントとサービス自体の両方で使用できます。さらに、このインターフェイスを実装するプロキシ（クライアント側で使用）とスタブ（サービス側）の2つの特別なクラスが.aidl

によって自動的に生成されます。

クライアントプロセスのJavaコードの場合、プロキシオブジェクトはインターフェイスを実装する通常のJavaオブジェクトのように見え、このコードはそのメソッドを単純に呼び出すことができます。この場合、生成されたプロキシオブジェクトの実装は、渡された引数を自動的にシリアル化し、libbinderを介してサービスプロセスと通信し、渡された呼び出しの結果を逆シリアル化し、Javaメソッドから返します。

スタブは別の方法で動作します。libbinderを介して着信呼び出しを受け入れ、引数を逆シリアル化し、メソッドの抽象実装を呼び出し、戻り値をシリアル化し、クライアントプロセスに渡します。したがって、サービスを実装するには、プログラマーがスタブから継承したクラスに抽象メソッドを実装するだけで十分です。

Javaレベルでのこのバインダーの実装により、ほとんどのコードは、その機能が別のプロセスで実装されているという事実を考慮することなく、プロキシオブジェクトを使用できます。完全な透明性を確保するために、Binderはネストされた再帰的なプロセス間呼び出しをサポートしています。さらに、使用されるサービスの実装が同じプロセスにあるか別のプロセスにあるかに関係なく、クライアント側でのバインダーの使用はまったく同じに見えます。

異なるプロセスが互いのサービスを「見つける」ために、Androidには、他のすべてのサービスのトークンを保存、登録、および発行する特別なServiceManagerサービスがあります。

バインダーはシステムサービス（パッケージマネージャーやクリップボードなど）を実装するためにAndroidで広く使用されていますが、この詳細はActivity 、 Intent 、 ContextなどのAndroidフレームワークの高レベルクラスによってアプリケーション開発者から隠されています。また、アプリケーションはバインダーを使用して相互に独自のサービスを提供できます。たとえば、 Google Play Servicesアプリケーションには独自のグラフィカルユーザーインターフェイスはありませんが、他のアプリケーションの開発者にGoogle Playサービスを使用する機会を提供します。

これらのリンクでバインダーについて詳しく知ることができます：

次の記事では、Androidの高レベル部分、その前身のいくつか、および基本的なセキュリティメカニズムを構築するいくつかのアイデアについて説明します。

Androidの仕組み、パート1

いくつかの事実

AndroidはLinux

アプリがすべて

バインダー

More articles: