トリミングセクションアンドロイドとは何ですか？ Androidシステムの内部デバイス

早い段階やADBがどのように機能するのか疑問に思ったことはありますか？それとも、なぜAndroidを搭載したスマートフォンがレンガに変わることはほとんど不可能ですか？あるいは、Xposedフレームワークの魔法がどこにあるのか、なぜ/system/etc/init.dブートスクリプトが必要なのかを長い間知りたがっていますか？回復コンソールはどうですか？それはAndroidの一部であるのか、それともそれ自体であり、なぜサードパーティのファームウェアをインストールするのに適していないのでしょうか？これらのすべて、そしてこの記事で見つける他の多くの質問に答えます。
Androidの仕組み

どのように動作するのかを理解することで、ソフトウェアシステムの隠れた機能について知ることができます。場合によっては、システムコードを閉じることができるので、これを行うのは難しいですが、Androidの場合、システム全体を上下に調べることができます。この記事では、Androidの作業のすべてのニュアンスについては話しませんが、電源ボタンを押してデスクトップの外観を表示するまでの間に、OSがどのように起動し、イベントが発生するかだけに注目します。
この一連のイベントで私たちが何を変えることができるのか、OSのチューニング、アプリケーションの格納スペースの拡大、スワップの接続、さまざまなカスタマイズなど、カスタムファームウェア開発者がこれらの機能をどのように使用するのかを説明します。このすべての情報は、独自のファームウェアを作成し、さまざまなハックや変更を実装するために使用できます。
ステップ1。 ABOOTとパーティションテーブル

それはすべて主ローダーで始まります。電源投入後、システムはデバイスの永久メモリに記録されたブートローダーコードを実行します。その後、彼はfastbootプロトコルのサポートを内蔵したブートローダーに制御を移しますが、モバイルチップやスマートフォン/タブレットの製造元は、他のブートローダーを好みに合わせて選択する権利があります。たとえば、Rockchipは、独自のツールを使用しなければならないプログラムを再プログラミングおよび制御するために、fastbootブートローダと互換性のない独自のものを使用します。
高速ブートプロトコルは、ブートローダのロック解除、新しいカーネルとリカバリのフラッシュ、ファームウェアのインストールなど多くの機能を実行できるようにするPCブートローダ管理システムです。ファストブートの存在の意味は、他のすべての手段が動作しない状況でスマートフォンを初期状態に戻すことができることです。実験の結果、スマートフォンからアンドロイドとリカバリを含むNANDメモリのすべてのセクションが消去されても、Fastbootはそのまま残ります。
制御を受け取った後、abootはパーティションテーブルをチェックし、bootという名前のパーティションに貼り付けられたカーネルに制御を移し、その後カーネルは同じパーティションからRAMイメージをメモリに抽出し、Androidまたは回復コンソールのダウンロードを開始します。 AndroidデバイスのNANDメモリは、6つの条件付き必須セクションに分かれています。
boot - 通常約16 MBのサイズのカーネルとRAMディスクを含みます。

リカバリ - リカバリコンソール。カーネル、一連のコンソールアプリケーション、および構成ファイル（16 MB）で構成されています。

システム - Androidを搭載し、最新のデバイスでは少なくとも1 GBのサイズです。

キャッシュ - キャッシュされたデータを格納するように設計されており、OTA更新中にファームウェアを保存するためにも使用されるため、システムパーティションのサイズに似たサイズです。

userdata - 設定、アプリケーション、ユーザデータを含んでいますが、残りのすべてのNANDメモリ空間が与えられます。

misc - システムを起動するモードを決定するフラグ（Androidまたは回復）を含みます。

それに加えて、他のセクションもあるかもしれませんが、全体のマークアップはスマートフォンの設計段階で決定され、暴走の場合にはローダーコードに縫い付けられます。つまり、1）パーティションテーブルは、fastboot oem formatコマンドを使用していつも復元できるので、削除できません。 2）パーティションテーブルを変更するには、新しいパラメータでブートローダのロックを解除し、再起動する必要があります。しかし、このルールから例外があります。たとえば、同じRockchipブートローダは、NANDメモリの最初のブロックにパーティションに関する情報を格納するので、ブートローダを変更してフラッシュメモリを変更する必要はありません。
パーティションテーブルを定義するローダーコードの一部

特に興味深いセクションの雑最初は、メインシステムに関係なくさまざまな設定を保存するように作成されていたが、現時点では1つの目的にのみ使用されているという前提があります。ブートローダーにシステムをロードするパーティションをブートまたは回復から指示します。この機能は、特にROMマネージャーアプリケーションを使用して、ファームウェアの自動インストールでシステムを自動的に再起動します。 Ubuntu Touchのデュアルブート機構が組み込まれており、Ubuntuブートローダを復旧時にフラッシュし、次回にロードするシステムを制御することができます。 Stehrその他のセクション - Androidが読み込まれ、データでいっぱいになっています - 回復がロードされています...つまり、Ubuntu Touchです。
ステップ2。ブートセクション

miscセクションに回復時にブートフラグがない場合、abootはブートセクションにあるコードに制御を移します。これはLinuxカーネルのようなものではありません。それはセクションの始めに位置し、すぐにAndroid、init initシステム、および他のツールに必要なディレクトリを含むcpioとgzipアーカイバが入ったRAMディスクイメージが続きます。ブートパーティションにはファイルシステムはなく、カーネルとRAMディスクは単純に互いに後続しています。 RAMディスクの内容は次のとおりです。
data - 同じ名前のセクションをマウントするディレクトリ。

dev - デバイスファイル。

proc - procfsがここにマウントされています。

res - 充電器の画像のセット（下記参照）。

sbin - ユーティリティツールとデーモンのセット（例えば、adbd）。

sys - sysfsはここにマウントされます。

system - システムパーティションをマウントするディレクトリ。

charger - 課金処理を表示するアプリケーション。

build.prop - システム設定。

init - 初期化システム。

init.rc - 初期化システム設定。

ueventd.rc - initの一部であるuventdデーモンの設定。

これは、私がそう言うかもしれないが、システムの骨格である：NANDメモリパーティションからファイルシステムを接続するための一連のディレクトリと、システムのロード時に残りの作業を行う初期化システム。ここでの中心的な要素は、initアプリケーションとそのinit.rcの設定です。これについては後で詳しく説明します。その間、私は、ファイルchargerとueventd.rcだけでなく、ディレクトリsbin、proc、およびsysにも注目したいと思います。
充電器ファイルは、バッテリアイコンを表示することのみが目的の小さなアプリケーションです。 Androidとは何の関係もなく、デバイスがオフ状態の充電器に接続されているときに使用されます。この場合、Androidは起動せず、システムは単にカーネルを読み込み、RAMディスクを接続して充電器を起動します。後者はバッテリアイコンを表示し、画像は可能なすべての状態でresディレクトリ内の通常のPNGファイルに保存されます。
ueventd.rcファイルは、システムブートフェーズでsysディレクトリ内のどのデバイスファイルを作成するかを決定する設定ファイルです。 Linuxベースのシステムでは、ハードウェアはdevディレクトリ内の特殊ファイルを介してアクセスされ、initの一部であるueventdデーモンはAndroidでそれらを作成する役割を担います。通常の状況では、自動的に動作し、カーネルからファイルを作成するコマンドを受け取りますが、いくつかのファイルは独立して作成する必要があります。それらはueventd.rcにリストされています。
Androidの在庫のsbinディレクトリには通常、adbd以外のもの、つまりPCからシステムをデバッグするADBデーモンが含まれています。 OS起動の初期段階から開始され、OSの初期化段階で発生する可能性のある問題を特定することができます。このディレクトリのカスタムファームウェアでは、パーティションをext3 / 4に再フォーマットする必要がある場合に必要な、mke2fsなどの他のファイルを見つけることができます。また、moderyはしばしばそこにBusyBoxを置いて、数百のLinuxコマンドを呼び出すことができます。
Linux用のprocディレクトリは標準であり、initをロードする次の段階で、システムのすべてのプロセスに関する情報にアクセスできる仮想ファイルシステムprocfsに接続します。システムはsysディレクトリsysfsに接続し、ハードウェアとその設定に関する情報にアクセスします。 sysfsを使用すると、たとえば、デバイスをスリープ状態にしたり、使用されている省電力アルゴリズムを変更したりすることができます。
build.propファイルは、Androidの低レベル設定を保存するように設計されています。その後、システムはこれらの設定をリセットし、現在利用できないsystem / build.propファイルの値で上書きします。
セットトップボックスOUYAのルートセクション

ステップ2、代替。リカバリセクション

miscセクションの回復ブートフラグが設定されているか、ユーザーがボリュームダウンキーを押しながらスマートフォンをオンにした場合、abootは回復セクションの先頭にあるコードに制御を移します。ブートセクションと同様に、カーネルとRAMディスクを含み、メモリに展開され、ファイルシステムのルートになります。ただし、ここではRAMディスクの内容が若干異なります。
OSブートのさまざまな段階間の移行リンクとして機能するブートセクションとは異なり、リカバリセクションは完全に自己完結しており、Androidに関係のない小型のオペレーティングシステムが含まれています。リカバリには、独自のカーネル、独自の一連のアプリケーション（コマンド）、および独自のインタフェースがあり、ユーザがサービス機能をアクティブにすることができます。
標準的な（ストック）リカバリには、スマートフォンの製造元が署名したファームウェア署名キーのインストール、ワイプ、リブートという3つの機能しかありません。 ClockworkModやTWRPなどの修正されたサードパーティの復旧機能は、はるかに機能します。ファイルシステムのフォーマット、任意のキーで署名されたファームウェアのインストール（カスタム：読み込み）、他のパーティションへのファイルシステムのマウント（OSデバッグ用）、ファームウェアプロセスやその他の多くの機能を自動化するスクリプトサポートが含まれます。
たとえば、スクリプトを使用すると、リカバリ後にメモリカードに必要なファームウェアが自動的に検出され、インストールされ、Androidに再起動されます。この機能は、ROM ROMマネージャー、自動フラッシャー、CyanogenModや他のファームウェアの自動更新メカニズムで使用されます。
カスタムリカバリは、/system/addon.d/ディレクトリにあるバックアップスクリプトもサポートしています。フラッシュする前に、回復はスクリプトをチェックし、フラッシュする前に実行します。これらのスクリプトのおかげで、新しいファームウェアバージョンをインストールした後にgappsは消えません。
ステップ3。初期化

したがって、制御を受けた後、カーネルはRAMディスクを接続し、すべてのサブシステムとドライバの初期化が完了した後、initプロセスを開始し、そこからAndroidの初期化が開始されます。前にも述べたように、initは設定ファイルinit.rcを持っています。このファイルから、システムはシステムを呼び出すために何をすべきかを知ります。現代のスマートフォンでは、この設定は数百行に及ぶ印象的な長さを持ち、輸入指令の助けを借りて主要なものに接続されているいくつかの娘構成のトレーラーも備えています。それにもかかわらず、その形式は非常に単純であり、実際にはブロックに分割された一連のコマンドです。
各ブロックは、Android開発者の言葉で言えば、アクションのロードの段階を決定します。ブロックはonディレクティブの後にactionの名前が続くように（たとえば、early-initまたはpost-fsの場合）互いに分けられます。コマンドブロックは、同じ名前のトリガが起動した場合にのみ実行されます。起動時に、initはearly-init、init、early-fs、fs、post-fs、early-boot、bootトリガを順番に有効にし、適切なコマンドブロックを開始します。
CyanogenModのinit.rc設定の一部

設定ファイルが最初にリストされたいくつかのconfigsをプルすると（ほとんどの場合そうです）、その中の同じ名前のコマンドブロックがメインの設定とマージされるので、トリガトリガinitがすべてのファイルの対応するブロックからコマンドを実行します。これは、メインコンフィギュレーションにすべてのデバイスに共通のコマンドが含まれていて、各デバイス固有のコマンドが別々のファイルに書き込まれている場合に、いくつかのデバイス用のコンフィギュレーションファイルを生成するために便利です。
追加の設定の中で最も顕著な名前はinitrc.name_device.rcです。デバイス名はro.hardwareシステム変数の内容に基づいて自動的に決定されます。これは、特定のデバイスに固有のコマンドブロックを含むプラットフォーム固有の構成ファイルです。カーネルのチューニングを担当するコマンドに加えて、次のコマンドも含まれています。
mount_all ./fstab.device_name
つまり、initは./fstab.device_nameにリストされているすべてのファイルシステムをマウントする必要があります。これは次の構造を持ちます：
device_name（セクションの）mount_point file_system option_fsその他のオプション
通常は、内部のNANDパーティションから/ system（OS）、/ data（アプリケーション設定）、/ cache（キャッシュされたデータ）ディレクトリにファイルシステムを接続するための説明が含まれています。しかし、このファイルを少し変更するだけで、initはメモリカードからシステムを起動させることができます。メモリカードを1Gb / ext4,2Gb / ext4,1Gb / ext4の3つのセクションと残りのスペースfat32の3つのセクションに分割するだけで十分です。次に、/ devディレクトリ内のメモリカードのパーティション名を（異なるデバイスの場合）決定し、それらをfstabファイル内の元のデバイス名に置き換える必要があります。
典型的なfstabファイルの内容

boot initブロックの最後には、class_start defaultコマンドがあります。これは、デフォルトクラスに関連するconfig内のすべてのサービスを開始する必要があることを通知します。サービスの説明はserviceディレクティブで始まり、その後にサービスの名前とそれを開始するために実行する必要のあるコマンドが続きます。ブロックに列挙されているコマンドとは異なり、サービスは常に動作するはずなので、スマートフォンの寿命を通して、initはバックグラウンドでハングアップし、それを監視します。
現代のAndroidには数多くのサービスが含まれていますが、そのうちの2つは特別なステータスを持ち、システムのライフサイクル全体を定義します。
ステップ4。接合子とapp_process

ローディングのある段階で、initはconfigの最後にこのユニットのようなものを見つけます：
サービスzygote / system / bin / app_process -Xzygote / system / bin --zygote --start-system-server
   クラスデフォルト
   ソケット結合ストリーム660ルートシステム
   onrestart write / sys / android_power / request_stateウェイクアップ
   onrestart write / sys / power / state on
   onrestart restartメディア
   onrestart restart netd
これは、初期化、システムサービスの開始、ユーザーアプリケーションの開始と停止、およびその他多くのタスクを担当するAndroidシステムの主要コンポーネントであるZygoteサービスの説明です。 Zygoteは、小さなアプリケーション/ system / bin / app_processを使って起動されます。これは上記の設定で非常によく見られます。 app_proccessタスクは、コードが/system/lib/libandroid_runtime.so共有ライブラリにあるDalvik仮想マシンを起動し、その上にZygoteを実行することです。
これがすべて完了し、Zygoteが制御を取得すると、フレームワークのJavaクラス（すべて2000以上）がロードされ、Javaアプリケーションの実行環境が構築されます。その後、ウィンドウマネージャー、ステータスバー、パッケージマネージャー、そして最も重要なことに、開始および終了信号の受信を担当するアクティビティーマネージャーを含む、ハイレベル（Javaで書かれた）システムサービスのほとんどを含むsystem_serverを開始しますアプリケーション。
その後、Zygoteはソケット/ dev / socket / zygoteを開き、データを待ってスリープ状態になります。この時点で、以前に起動したActivity Managerは、ブロードキャストインテントIntent.CATEGORY_HOMEを送信して、デスクトップの作成を担当するアプリケーションを検索し、ソケットを介してZygoteという名前を付けます。後者は、仮想マシン上でアプリケーションをフォークして実行します。私たちは画面上にデスクトップ、アクティビティマネージャーと実行中のZygote、ステータスバーサービス内でsystem_serverによって起動されたステータスバーを持っています。アイコンをタップすると、デスクトップはこのアプリケーションの名前でインテントを送信し、それがアクティビティマネージャによって受け入れられ、アプリケーションをZygoteデーモンに開始するコマンドを送信します
すべてこれはやや理解しにくいかもしれませんが、最も重要なことは3つの簡単なことを覚えておくことです：
システムサービスとカーネルスレッド

結論

多くの点で、Androidは他のオペレーティングシステムと非常に異なるため、それを理解することは不可能です。しかし、すべての仕組みが理解できれば、無限の可能性があります。 Googleのオペレーティングシステムは、iOSやWindows Phoneとは異なり、非常に柔軟なアーキテクチャを採用しているため、コードを記述することなく動作を大幅に変更することができます。ほとんどの場合、必要な設定とスクリプトを調整するだけで十分です。

ミドルウェア高効率を必要とする一般的な問題を解決するために設計された一連のライブラリ（ライブラリ）です。すなわち、より高いレベル、ファイルフォーマットのサポート、情報のエンコードとデコード（例えば、マルチメディアコーデック）、グラフィックスの描画など、実装されたアルゴリズムを提供するのはこのレベルです。ライブラリはC / C ++で実装され、特定の目的でコンパイルされますハードウェア装置が予め設置された形で製造業者によって供給される装置。

いくつかの低レベルライブラリがあります：

Surface Manager - AndroidはCompiz（Linux）のような複合ウィンドウマネージャを使用しますが、よりプリミティブです。グラフィックスをディスプレイバッファに直接描画するのではなく、受信した描画コマンドをボイスオーバーバッファに送ります。ボイスオーバーバッファは、他のものと共に蓄積され、あるコンポジションを構成し、画面上でユーザに表示されます。これにより、システムは興味深いシームレスなエフェクトを作成し、ウィンドウの透過性を実現し、スムーズなトランジションを実現します
Media Framework - PacketVideo OpenCOREに基づいて実装されたライブラリ。彼らの助けを借りて、システムは、静止画像を出力するだけでなく、オーディオおよびビデオデータを記録および再生することができます。 MPEG4、H.264、MP3、AAC、AMR、JPG、PNGなど、多くの一般的なフォーマットがサポートされています。将来、OpenCOREはより単純なフレームワーク、Stagefrightに置き換えられます。
SQLiteは軽量で生産的なリレーショナルデータベースエンジンで、主なデータベースエンジンとしてAndroidに使用されています。
3Dライブラリ - 高度に最適化された描画用3Dグラフィックスで、ハードウェアアクセラレーションを可能な限り使用します。それらの実装は、OpenGL ES 1.0 APIに基づいています。
FreeTypeは、ビットマップ、フォントのラスタライズ、およびそれらに対する操作を行うためのライブラリです。これは、フォントやテキスト表示のための高品質なエンジンです。
LibWebCoreはよく知られているブラウザエンジンWebKitのライブラリで、Google ChromeやApple Safariのデスクトップブラウザでも使用されています。
SGL（Skia Graphics Engine） - 2Dグラフィックスを扱うためのオープンエンジンです。グラフィックライブラリはGoogleの製品であり、他のプログラムで頻繁に使用されています。
SSL - OpenSSLに基づく同じ暗号プロトコルをサポートするライブラリ。
libcは標準的なC言語の呼び出しのライブラリで、glibc（LinuxのGNU libc）のアナログ版で、小さなデバイス用です。それはバイオニックと呼ばれています。

図1 1.5。

同じレベルではAndroid Runtime - アプリケーションランタイム環境があります。その主要なコンポーネントは、一連の標準ライブラリと仮想マシン Dalvik。 Android OSの各アプリケーションは、Dalvik仮想マシンの独自のコピーで動作します。したがって、実行中のすべてのプロセスは、オペレーティングシステムと互いに分離されています。 Android Runtimeのアーキテクチャは、プログラムの作業が仮想マシン環境のフレームワーク内で厳密に実行されるようなものです。このため、オペレーティングシステムのコアは他のコンポーネントからの害から保護されます。したがって、エラーやマルウェアのコードは、それに基づいてAndroid OSとデバイスを台無しにすることはできません。このような保護機能は、コードの実行とともに、Android Runtimeの鍵の1つです。

上記のレベルはアプリケーションフレームワークです。アプリケーションフレームワークレベルと呼ばれることもあります。開発者が下位レベルのシステムコンポーネントによって提供されるAPIにアクセスできるのは、アプリケーションフレームワークによるものです。さらに、フレームワークアーキテクチャのおかげで、どのアプリケーションも、アクセスが許可されている他のアプリケーションの既に実装されている機能を提供します。各アプリケーションの基礎となる、フレームワークの一部である基本的な一連のサービスとシステムは次のとおりです。

リスト、テキストフィールド、テーブル、ボタン、または埋め込みWebブラウザなどのアプリケーションのビジュアルコンポーネントを作成するために使用できる豊富で拡張可能な一連のビュー（ビュー）。
コンテンツ一部のアプリケーションが他のユーザーに公開しているデータを管理し、仕事に使用できるようにするプロバイダー。
文字列データ、グラフィックス、ファイルなどのコードを持たないリソースへのアクセスを提供するリソースマネージャ（リソースマネージャ）。
通知マネージャーを使用して、すべてのアプリケーションがユーザーのための独自の通知をステータスバーに表示することができます。
アクティビティマネージャは、アプリケーションのライフサイクルを管理し、アクティビティに関する履歴のデータを格納し、それらのためのナビゲーションシステムも提供します。
ロケーションマネージャー（ロケーションマネージャー）。これにより、アプリケーションは、デバイスの現在の地理的位置に関する更新されたデータを定期的に受信することができます。

Androidソフトウェアスタックの一番上には、アプリケーションレベル（アプリケーション）があります。これには、Android OSにプリインストールされている一連の基本アプリケーションが含まれます。たとえば、ブラウザ、電子メールクライアント、SMS送信用プログラム、マップ、カレンダー、連絡先マネージャーなどが含まれます。統合アプリケーションのリストは、デバイスのモデルとAndroidのバージョンによって異なる場合があります。この基本セットに加えて、アプリケーションのレベルには、Androidプラットフォームのすべてのアプリケーション（ユーザーがインストールしたアプリケーションを含む）が含まれます。

原則として、AndroidアプリケーションはJavaで書かれていますが、C / C ++（Native Development Kitを使用）でプログラムを開発する機会があります。 Exoticsは、Basic（シンプルを使用）と他の言語を使用して呼び出すことができます。また、App Inventorなどのアプリケーションデザイナを使用して独自のプログラムを作成することもできます。

1.6。カーネルの機能

カーネルはLinux OSの中で最も重要な部分であり、他の部分とは異なり、ほぼ完全にAndroid OSに移行しています。しかし、転送の過程で約250パッチがコアに適用されました。

Android OSカーネルでは、Linux OSのプロセス間通信手段を放棄し、代わりにBinderという単一のメカニズムを作成することに決めました。バインダーを使用すると、同じプロセス内でメソッドが呼び出されたときと同じように、別のプロセスから1つのプロセスのメソッドを呼び出し、引数を渡して結果を取得することができます。バインダーは最小のメモリ使用でこのジョブを行います。

小さなデバイスでデバッグを有効にするために、デバッグ情報がカーネルに追加されました。シリアルポート logcatコマンドのサポートを実装しました。

大きな変化はメモリを使った作業に触れました。従来のLinux共有メモリshmemはashmemに置き換えられました。同じ問題が、物理メモリのレベルでは、pmemドライバを使用して解決されます。 Viking Killerという特別なメモリ不足のハンドラが追加されました。最も単純なケースではプロセスを殺すだけですが、より複雑なルールを設定することができます。

新しいセキュリティ設定がネットワークスタックに追加され、YAFFS2フラッシュドライブのファイルシステムサポートがカーネルに含まれています。

1.7。 JavaマシンDalvik

Dalvik Virtual MachineはAndroidモバイルプラットフォームの一部です。それは仮想マシンダンブロンシュタインが後援した。それはのように広がるフリーソフトウェア BSD互換のApache 2.0ライセンスの下で動作します。多くの点で、この事実はGoogleのJME（Java Micro Edition）放棄の決定において重要な役割を果たしました.SMEからライセンスを取得する必要があります。したがって、オープンなオペレーティングシステムを作成することを目標としていた企業は、独自の仮想マシンを開発しました。

スタック指向のほとんどの仮想マシン（同じJava仮想マシン）とは異なり、Dalvikはレジスタ指向であり、標準ソリューションとは言えません。一方、ARMプロセッサを搭載したRISCアーキテクチャのプロセッサでは、モバイルデバイスで非常に幅広く使用されています。

DalvikはAndroidプラットフォーム向けに特別に設計されました。プラットフォームが独立したすべてのプロセスを構築し、それぞれが独自のアドレス空間で実行されているという事実が考慮されました。仮想マシン低メモリ消費に最適化され、モバイルハードウェアで動作します。 Android 2.2以降、DalvikはJIT（Just-In-Time）コンパイルを使用します。これらの機能の結果として、迅速かつ生産的な仮想マシンアプリケーション全体の動作に影響を与えることはできません。

Dalvikは独自のバイトコードを使用します。 Androidアプリケーションを開発するとき、それらはコンパイラによって特別なマシンに依存しない低レベルのコードに変換されます。プラットフォーム上で実行されると、Dalvikはそのようなプログラムを解釈して実行します。

さらに、Dalvikは、Javaバイトコードをネイティブフォーマットコードに変換し、仮想環境で実行することもできます。プログラムコードは、Javaで書かれており、コンパイル後はすべてです。クラスファイルは、Android SDKに含まれている特殊ユーティリティdxを使用して、.dex形式（Dalvikでの解釈に適しています）に変換されます。

1.8。バイオニック

BionicはBSDライセンス（教育機関間の経験を共有するために作成されたソースコードソフトウェア配布システム）でBSDライセンスに基づいて配布され、Google for Androidで開発された標準的なC言語の呼び出しライブラリです。バイオニックでは、完全なglibc実装で利用可能な非Android POSIX関数がいくつかあります。

主な違いはバイオニックです：

BSDライセンス：AndroidはGNU一般公衆利用許諾（GPL）に基づいているLinuxカーネルを使用しますが、GoogleはAndroidアプリケーションをGPLの影響から分離したいと考えました。 Linuxカーネルでよく使用されるGNU libcは、uClibcの代わりにGNU LGPLライセンスの下にあります。
小さなサイズ：バイオニックオブジェクトコードはglibcよりもずっと小さく（約2倍）、uclibcよりもわずかに小さい。
bionicは、比較的低クロック速度のプロセッサ向けに設計されています。
pOSIXスレッドの切り詰められたが効果的な実装。

1.9。 Javaアプリケーション・プログラマー・インターフェースの概要

Androidアプリケーションプログラマー向け - Java言語のインターフェースセット。どのように構成されているかを検討してくださいスイートの中核には、java.util、java.lang、java.ioなどの標準Java言語の一部であるパッケージがあります。それらは、Javaアプリケーションが実行できる任意のプラットフォーム上にあり、Android用ではありません。言語の標準には含まれていないが、実際には長い間スタンダードになっている拡張モジュール - javax.net packages、javax.xml。

Androidにはあまり一般的でないJava拡張も含まれています - org.apache.httpパッケージは、HTTPプロトコルの最も堅実な実装です。 org.jsonパッケージは、JavaScriptオブジェクトのシリアライズとAJAX技術のサポートを担当します。 org.w3c.domパッケージは、ドキュメントオブジェクトモデルを提供します

Androidプラットフォームに基づくタブレットの一部のモデルでは、上記のリストの一部が欠落している可能性があります。

すべての「アンドロイド」タブレットは、Googleのモバイルオペレーティングシステムのいずれかのバージョンで管理されています。しかし、古いバージョンでは、最新のアプリケーションの一部をサポートしていない可能性があります。

最も一般的なモバイルオペレーティングシステムのすべてのバージョンは、共通の基礎を持っています。私たちは、Androidオペレーティングシステムを多層構造として想像することができます。コンピュータエンジニアはこれをソフトウェアスタックと呼びます。スタックの最上位にある要素は、ユーザーがオペレーティングシステムとやりとりしているときに表示される要素です。スタックの最下部には、オペレーティングシステムのうち、デバイスのハードウェアと直接対話する部分があります。

つまり、プロセッサ、センサー、ワイヤー、プリント回路基板など、ハードウェアコンポーネント自体が最も低いレベルにあります。次のレイヤーは、オペレーティングシステムのコアです。カーネルは、組み込み（または独自の）ソフトウェアとも呼ばれることがあります。「ファームウェア」の英語の定義は、よりよく知られています。このソフトウェアは、デバイスのハードウェアリソースを制御し、デバイスのハードウェアリソースを制御します。

オペレーティングシステムのこの部分は、ユーザが便利なグラフィカルインタフェースを介して与えるコマンドを、ハードウェアコンポーネントの言語に「翻訳」する。 Androidのカーネルの例は、オープンソースオペレーティングシステムのLinux 2.6です。

Androidライブラリは、オペレーティングシステムカーネルの上にあります。これらは、さまざまなタイプのデータを処理する際にデバイスが従う一連の命令です。一例は3次元空間における方向ライブラリである。そこには、Androidデバイスが宇宙での位置の変化を認識し、それに応答するために必要なすべての命令が含まれています。

ソフトウェア・スタックと同じレベルには、Java言語で書かれたアプリケーションをサポートするために必要なルート・ライブラリーがあります。 JavaはSun Microsystemsのプログラミング言語です。最近では、Java対応の電話機が非常に一般的です。現在、彼らはますますスマートフォンに取って代わられています。

Android仮想マシンは、オペレーティングシステムソフトウェアスタックと同じレベルにあります。このソフトウェアは、仮想オペレーティング環境を作成しています。これは、仮想オペレーティング環境とも呼ばれます。仮想マシンは、別個のオペレーティングシステムを備えた物理デバイスをシミュレートします。 Googleでは、Androidオペレーティングシステム上で動作する各アプリケーションが別々のプロセスとして機能するように、このレイヤーを設計しました。したがって、実行中のプロセスの1つが失敗すると、残りの部分は影響を受けません。仮想マシンはメモリマネージャの役割も果たします。

次のレベルはアプリケーションフレームワークです。それはすべてのアプリケーション "アンドロイド"デバイスの基礎です。アプリケーションインフラストラクチャは、アプリケーションと他のオペレーティングシステムとの間のリンクです。

開発者は、検索エンジンのオペレーティングシステムによって開発されたアプリケーションプログラミングインターフェイス（）の一部として、このレイヤとやりとりするアプリケーションを作成することをお勧めします。開発者は、これらのAPI関連のルールに慣れるだけで十分です。彼らはそれぞれの "アンドロイド"タブレットの技術的特徴について考える必要はありません。

ソフトウェアスタックの最上位には、ユーザーインターフェイスとAndroidタブレットのすべてのアプリケーションが含まれています。オペレーティングシステムのこの部分は、常にユーザーに表示されます。しかし、この魅力的でカラフルな層の後ろには、コードの専門家だけが退屈で興味深いものがあります。

他のオペレーティングシステムやタブレットの他のハードウェアリソースと同様です。

computer.howstuffworks.comに基づいて

＃ファクト| Androidはどのように機能しますか？オレグDovbnya

印刷