Androidはすべてのデバイスで使用される共通のカーネルではありませんか？たとえば、CentOSは、Dell、HP、およびその他のさまざまなハードウェアにインストールされます。確かに異なるモジュールがありますが、それでもCentOSです。
CyanogenModが常に「壊れている」理由は何ですか？フォーラムでは、このドライバーまたはそのドライバーの移植に取り組んでいます。同じカーネルを使用している場合、ドライバーはそれで動作しませんか？また、さまざまなデバイス用の無数の異なる種類のカーネルがあります。
回答:
カーネルはメーカーによって異なります。これらのカーネルの多くは、CAFにあるソースの純粋なストックカーネルラインに由来しています。これらのメーカーは、ストックソースを取得し、使用するボード/チップセットに基づいてそれらを変更し、独自のドライバーを実装しています。
あなたの周りをよく見てください、タッチスクリーンのバリエーション、wifiチップセットのバリエーション、もちろん、加速度計、センサー、バッテリー、コンパス、サウンド、グラフィックスがあります。
たとえば、HTCから1つのカーネルソースを取得しても、Samsungでは機能しません。逆の場合も同様です。
メーカーは、回路基板に組み込まれるさまざまなビットを自由に選択したり、アウトソースしたりできます。難しいルールや速いルールはありません。したがって、カーネルを適切に動作させるための多くのハッキング/変更。
PCI、PCI-Express、SATA、VGA、SVGA、USB、イーサネットを備えたデスクトップLinuxディストリビューションカーネルと比較してはいけません。まったく異なるボールパークゲームです。CentOSとAndroidのLinuxカーネルとの主な違いはこれです- すべてのドライバーはモジュールまたはビルトインのいずれかとしてコンパイルされるため、Linuxディストリビューションは単に「そのまま」動作します。繰り返しになりますが、デスクトップLinuxディストリビューションでは、アーキテクチャが1つです。x86であるため、Dell PCなどのLinuxカーネルは、ボグ標準ドライバがコンパイルされていれば、Lenovoでそのまま使用できます。
Androidの世界には、ARMv6、ARMv7などの特定のARMチップセット用に構築されたカーネルのバリエーションがあり、TEGRAがあり、EXYNOSがあり、相互にバイナリ互換性がないことを忘れないでください。したがって、カーネルがTEGRA用にコンパイルされている場合は、忘れてください。ARMv7では動作しません。
Androidの一部のカーネルが「破損」しているように見える理由は、製造業者にかかっています。一部（Zteは非常に良い例です）は、ソースからコンパイルできるが、GPLv2またはGPLv3ライセンスでカバーされていないドライバーが見つからないために起動に失敗する、屠殺されたソースをリリースします。それが問題なので、一部のハッカーは手がかりを探すためにgithubを探し回らなければなりません。すべてではないにしても、一部のメーカーは準拠しています。Zteのソースの現在の化身は2.6.35.7であると言われていますが、実際には多くの変更を加えた実際の2.6.32.9ソースベースは、2.6.35.7の真のカーネルソースを表していません！
これは、GPLv2以降に準拠していないだけでなく、オーバークロック機能を追加するなど、コミュニティがそれを変更できるようにするために、メーカーがそれぞれのソースをリリースする必要がある場所です。
したがって、そこにシーンや仕事にそれを取得しようとしているドライバーとぐちゃぐちゃに多くの背後に関与ハッキングだ、とその簡単なデバッグに...一部のドライバは、クロスライセンスを取得することができるではないのいずれか、しかし条項や条件などに応じて配布することができません交渉した。
ありがたいことに、Androidドライバーが主流のソースに統合されるようになったため、カーネル3.xxのソース行ですべてが変更されました。しかし、落とし穴があります！
約12〜18か月前の既存のハンドセットに3.xxカーネルを移植してみてください。雪だるまがうまくいかないのは、3.xxのソースが2.6.xのソースと大きく異なるため、動作させるために多くのハッキングが必要だからです。 Zte Bladeの2.6.38.6ソースを移植して失敗しました。
同様に、最新のカーネルリリース3.0.1-Modacoでics4bladeプロジェクトに取り組んでいるとき、それを移植しようと何度も試みましたが、それはZteが非常に悪いソースの混乱を引き起こし、移植を不可能にしたという事実です。
PCアーキテクチャは、特定の製品であるIBM PCのクローンとして始まったため、コモディティパーツを中心に構築されています。IBMPCは、互換性があり、したがって相互に互換性があるように特別に設計されています。一般的に言えば、プログラムまたは周辺機器をPC互換機から取り出して別のPCに入れて、動作することを期待できます。その能力は十分に有用であるため、技術が進化しても人々はそれを要求し続けています。当時のPCクローンにISAカードを挿入できるように、最新のPCにPCI Expressカードを挿入できます。
スマートフォンにはそのような歴史はありません。それらはモノリシック製品として設計されており、ハードウェアとソフトウェアで構成された完全なシステムであり、「そのままで」機能します。人々が1つの電話から部品を取り出して別の電話に入れるという期待はないため、エンジニアは製品を設計するときに相互運用性を考慮する必要はありません。
Linuxカーネルソースツリー内でも、ARMプラットフォームのドライバーには多くの断片化があります。電話機は通常密室で設計されているため、さまざまな企業のエンジニアリングチームは多くの場合、重複する作業を行い、基本的に競合他社と同じハードウェアを設計し、独自の設計用に独自のドライバーを作成します。作業が完了して製品がリリースされると、次の作業にすぐに進みます。戻って過去の製品のドライバーをリファクタリングしたり、競合他社のドライバーとマージしたりする時間はありません。その結果、似ているがまったく同じではないデバイス用の1回限りのドライバーが大量にあります。
さらに、スマートフォンは通常SOCに基づいています、プロセッサと統合された特殊なハードウェアを持つています。これの一部については、特定のドライバーをロードするかどうかの問題以上のものになる可能性があります。カーネル全体を、あるSOCで実行するための特別な構成オプションを使用して構築する必要がありますが、これは別のSOCで実行するために必要な特別なオプションと互換性がありません。
その理由は、AndroidのLinuxカーネルは通常、Android自体でコンパイルされず、代わりに別のコンピューターからクロスコンパイルする必要があったためです。これは、コンパイル時にデバイス構成が利用できないため、さまざまな問題を引き起こし、スペース制限のためにすべてのドライバーで一般的なカーネルをコンパイルすることは不可能です（ほとんどのデスクトップディストリビューションでは、すべてのドライバーがinitramfsからロードされたモジュールにコンパイルされていたため） 。そのため、開発者は特定のデバイスごとにパッケージ化するドライバーを把握する必要がありました。それだけでなく、各ドライバーには通常、さまざまなドライバー機能を切り替えるためのコンパイル時オプションが十数個あり、メーカーは通常、公式の構成をリリースしません（最悪の犯罪者はドライバーをオープンソース化しないか、アップストリームのキープを維持しませんでした）最新のドライバーのコピー）。
ドライバーのプログラミングは、特定のリアルタイムタイミング要件などを備えた気まぐれなハードウェアからユーザーを保護するカーネルがないため、アプリケーションプログラミングよりもはるかに困難です。ハードウェアからのいくつかのハードリアルタイムイベント。これらのミスは、バグまたはパフォーマンスの問題として表面化する可能性があります。
もう1つの問題は、バイナリの非互換性です。バイナリの非互換性には2つの原因があります。1つはt0mm13bで十分にカバーされているCPUタイプですが、移植に関連する他の問題はABIの非互換性（アプリケーションバイナリインターフェイス）です。メーカーがドライバーをオープンソース化しない場合、開発者はストックROMからコンパイルされたモジュールを使用する必要がありました。ドライバーモジュール自体には、たとえば、構造体レイアウトや関数呼び出しパラメーターに関する特定の期待があり、カーネルのコンパイル時には、ドライバーの時点でABIを記述するヘッダーファイルがないため、さまざまなABIの非互換性の問題が発生します。コンパイルされ、そのため、開発者はドライバーをリバースエンジニアリングしてヘッダーファイルを作成する必要がありました。または、ドライバーがコンパイルされ、開発者がドライバーのABIと再び互換性を持たせるためにそれらの変更を元に戻す必要があったため、ソースツリーのヘッダーファイルが大幅に変更された可能性があります。ソースからのコンパイルとは異なり、バイナリドライバーのコンパイルは、関数パラメーターの不一致や構造の非互換性によるコンパイルエラーを引き起こしません。実行中のデバイスを単にクラッシュさせるだけであり、これらの問題のデバッグは非常に困難です。PCの世界では、nVidiaとATiが残した混乱に慣れ親しんでいます。バイナリのみのドライバーをリリースするという彼らの主張のために、すべてのドライバーにその混乱があることを想像してください。
PCハードウェアは一般にモバイルハードウェアよりも標準化が進んでおり、ほとんどのPCはバイブレーター、加速度計、ジャイロスコープ、3Gラジオ、近接センサー、NFCなどのドライバーを必要としません。 PCMCIAやPCI-Eなどの接続。
まあ...ドライバーとカーネルはまったく同じではありません。
ドライバーは、セルアンテナ、wifi、bluetoothなどを制御します。これらは、メーカーがハードウェアと通信する方法（ドライバー）を作成する必要があるため、独自のドライバーです。
カーネルは、OS /アプリケーションと実際のドライバー（またはCPU、メモリ、またはその他のハードウェア）の間の中間レベルです。OS /アプリがこれらのハードウェアコンポーネントとインターフェイスできるようにするものです。
あなたが目にする何百万ものカーネルのすべては、実際には互いにそれほど違いはありません。通常、プログラマ/モダーは既存のカーネルを取得し、それを「微調整」して、そこから異なるパフォーマンスを引き出します。基本的には、カーネルの「構成」を（大部分）調整しているだけだと言えます。Androidの世界では、これらの改造者は主にCPUクロックのオーバークロックまたはアンダークロック（バッテリー寿命を節約するか、ビデオゲームエミュレーターやビデオ再生などのプロセス集中型アプリケーションを実行するために重要です）、またはボルティング（元の設定パラメーターの外側でCPUを実行することでバッテリー寿命を節約するために... 2つのCPUが100％まったく同じにならないため、実際には人によって異なります）。
CentOSは異なるハードウェアにインストールされますが、
2番目のポイントについては、前に投稿した回答を参照してください。