質問の履歴はここで確認できます:
1)スマートフォン (ARM または x86) に lxc 用の Ubuntu サーバーをインストールするにはどうすればいいですか?
2)Ubuntu Touch (UBports) と LXC/LXD コンテナ (Ubuntu 実行用) の Android サポート: 現在の状態
サブ質問:
1) どのような SDK コンポーネントを使用する必要がありますか?
2) ロード用に起動可能なイメージを準備/変換するにはどうすればよいですか?
3) 元のブートローダーを置き換えて別のカーネルを起動するにはどうすればよいでしょうか (新しいパスを指定するにはどうすればよいでしょうか)?
4) 他にどのような手順を実行する必要がありますか?
私自身でこの質問に答えようと思いますが、一般的には、すでにこの道をたどった人からのガイダンスや情報の方が好ましいです。以前の試みへのリンクを見つけましたが、かなり古いものです。Linuxサーバーのインストールプロセスは非常によく文書化されています（私はDebianとUbuntuのドキュメントに依存しています）。スマートフォンベンダー（Asusなど）は、自社のサイトでブートローダーのロックを解除するためのツールを提供していますが、タスクを完了するには十分ではありません。このツールはブートローダーのロックを解除するだけで、起動メニューを変更しないため、外部のSDKツールを使用する必要があります（SDカードまたはネットワークから起動するオプションがメニューにまったくありません）。つまり、SDKによってブートローダー自体を変更する必要があります。リンクや情報があれば幸いです。
答え1
解決策の調査が少し進みました:
1) 実験に使用するデバイスからすべてのユーザーデータを消去しました（リカバリモードで起動 > キャッシュの消去 / データの消去 / 工場出荷時設定へのリセット）
2) 非公式の情報源を調べた
ネットには数多くの記事やフォーラム投稿があります。その中には役に立つものもありますが、ほとんどはかなり古く、最後に更新されたのはずっと前です。残念なことに、それらのほとんどには、デバイスのルート化に関する情報 (つまり、既知の脆弱性を悪用して権限を昇格するルートキットを意図的にインストールして OS のセキュリティを破る) や、そのようなルートキットを含む信頼できない/評判の低いスクリプトへのリンクが含まれています。この潜在的に有害な情報は、利用可能なオプションの概要を示す有用な部分と混在しています。
多くの記事がxda-developers.comサイトに掲載されており、フォーラムセクションとウィキ。
役に立つウィキ記事:
これらの Wiki 記事は、一般的にメンテナンスが不十分です (最終編集は 2015 年です)。
3) プラットフォームを選択 (x86、ASUS Zenfone2)
私の場合、私は自分の中古 Android デバイスのプールから選択していました。それらのほとんどは ARM ベースの CPU を搭載しています。最新で最も強力なのは、x86 Intel CPU (64 ビット命令セット) を搭載した ASUS でした。x86 を選択したもう 1 つの理由は、Linux サポートが優れていることと、x86/AMD64 ベースの lxc コンテナーを実行する必要があることです。ARM を選択するには、別のコンテナー ブランチを開発するか、何らかのエミュレーション/変換ツールを使用する必要があります (そのようなツールが効率的で、適切に保守/サポートされているかどうかはわかりません)。
4) 公式（ベンダーがサポートする）ツールでは目標に到達できない可能性があることを認識
私は、ASUS のテクニカル サポートに、ブートローダー ロック解除ツールの使用についてメールを送りました。しかし、回答はシンプルでした。「このツールはブートローダーのロックを解除するだけで、それ以上の手順についてはサポートできません。このツールを使用すると何が起こるかさえもお伝えできません」。つまり、このツールは役に立たないということです (私のケースではうまくいったかどうか、また とどう違うのかさえわかりませんfastboot oem unlock)。このツールを有効にするには、まず Android 5.0 にダウングレードする必要がありました。これは、新しいバージョンの ROM ではサポートされていなかったためです。ブートローダーの変更や他のイメージの起動に関するすべてのことは、非公式、サポートされていない、推奨されていない、保証違反などです。
5) [オプション: 注1] リカバリを選択してインストールします (電話または OS ベンダーによって正式にサポートされていません)
'回復'- は、ブートローダ/BIOS (デバイス メモリ内の別のパーティションで、最初に起動して「バックアップ」、「キャッシュの消去」、「工場出荷時設定へのリセット」、「カスタム ROM のロード」などの利用可能なツールを含むブートローダ メニューを表示する軽量の Linux ベースのシステムを保持する) の Android 専門用語です。オリジナルの OEM リカバリでは、カスタム ROM をフラッシュしたり、カスタム OS を起動したりすることはできません。
このプロジェクトは成熟しており、構造がしっかりしており、積極的に維持管理されており、一般的に価値のあるグローバルオープンソースプロジェクトという印象を与えます。サポートされているデバイスとベンダーの数は非常に多く、顕著もちろん、携帯電話ベンダーが保守および承認し、公式サイト (私の場合は ASUS) からダウンロードしたリカバリ バージョンを使用することを好みます。
注1:TWRP をインストールし、SDK ツールに関する詳細情報を取得した後、カスタム リカバリをインストールせずにカスタム ROM をフラッシュできる可能性があることに気付きました (SDK プラットフォーム ツール パッケージの adb および fastboot ツールを利用することにより)。
注2:インストール プロセスは、モデルごとに詳しく説明されています。私は「Fastboot インストール メソッド」を使用しました。メソッドの簡単な説明 (お使いのデバイスに関連する TWRP サイトのページを参照してください): 1) Android SDK ツールをインストールします (platform-tools パッケージの adb および fastboot コンポーネントのみが必要です)、2) 設定 > バージョン情報メニューの「ビルド番号」の行を 7 回タップして、デバイスの「開発者モード」をアクティブにします、3) 設定 > 開発者向けオプションで「USB デバッグ」を有効にします、4) USB 経由で PC に接続します、5) PC で、コマンド を渡してデバイスが接続されていることを確認しますadb devices、6) を実行してadb reboot bootloaderfastboot モードに入ります、7) TWRP サイトからダウンロードして「twrp.img」に名前を変更した正しいイメージ ファイルを、adb および fastboot バイナリを含むフォルダー (通常は「platform-tools」フォルダー) に配置します、8) を実行しますfastboot flash recovery twrp.img。私の場合、adbがエラーを報告したにもかかわらず、イメージは正常にフラッシュされましたFAILED (remote: Permission denied)、9) を実行しますfastboot reboot。TWRP メニューからデバイスを再起動することもできます。重要なのは、TWRP がストック ROM (Android OS のパーティション) にパッチを適用して、起動後に TWRP が消去され、ストック リカバリに置き換えられないようにすることです。そうしないと、プロセスを繰り返す必要があります。はい、それは怖かったので、ステップ 1 を実行しました。
6) 公式AOSPドキュメントを詳しく調べた
目標を達成するために Android OS にブラックボックス アプローチを使用するという希望を失った後、私は Android OS アーキテクチャとサポート対象デバイスに対する要件に関する一般的なセクションを確認し始めました。
良い写真（建築）:
ブートローダーとセキュリティ情報:
主な結論:Android は、ハードウェア標準が緩いさまざまな独自仕様 (FMCG の世界) デバイスで縮小版 Linux カーネルを実行するための便利な OS 機能を確実に導入しました。主流の Linux で採用できる、そしておそらく採用すべき最も便利な機能の 1 つは、HAL 抽象化レイヤーです。これにより、さまざまな独自仕様のドライバーを合理的な方法で処理できます。カーネルを SoC 依存部分とボード依存部分に分割するモジュラー カーネル、省電力機能、セキュリティ機能も注目に値します。
良いニュース:Linuxカーネル開発者といくつかのディストリビューションベンダーはこれらの良い部分をすべてよく理解しており、対応する変更を導入するために最善を尽くしています。公式統計（対応するAOSPドキュメントセクション) は、AOSP コードと主流の Linux の収束のよい証拠を示しています。収束は、双方 (AOSP と Linux コミュニティ) に明確な経済効果をもたらします。投資を保護している Google やハードウェア メーカーなどの利害関係者に関しては、反対方向に引っ張っているように見えます。Google はエコシステムとユーザー ベースへの投資を保護し、ハードウェア メーカーはハイエンド ハードウェアの開発と製造への投資を保護しています。これら 2 つの力の間の摩擦は、ある種のプラスのベクトルを生み出します。私の意見では、Google とハードウェア メーカーの間で、この摩擦を賢明に調整する何らかの合意が締結されている必要があります。たとえば、ハードウェア メーカーは、ボード固有のドライバー ブロブを Linux カーネルにコミットするのを 2 ～ 3 年遅らせることができます (SoC 固有のドライバー ブロブの場合、この期間はおそらくもっと短くする必要があります)。これにより、Android エコシステムが市場からすべての利益 (すべての新しい最新のハイエンド ハードウェア デバイスの購入、広告収入、ハイエンド ユーザーからの有料ソフトウェアとサービス) をすくい取っていることが Google と AOSP 開発者に保証されます。 2～3 年が経過すると、デバイス (もはやハイエンドとは見なされなくなります) は、ドライバー ブロブを Linux にコミットすることでフリーにリリースされます (最高級のハードウェア ベンダーは、もちろんソース コードのコミットを好みます)。この期間の長さは、ほとんどのデバイスに対してハードウェア ベンダーが設定する通常の保証期間と、それらのベンダーが配布する公式 Android アップデート (セキュリティ アップデートを含む) の期間にかなり近いです。まあ、いいでしょう。
悪いニュース：このような取引を交渉するのは本当に難しいようです（以下、「本取引」）賢明かつ明確な方法で。主な問題は、そのグローバルな性質にあります。考えられる法的考慮事項（さまざまな管轄区域の独占禁止法、国境を越えた課税問題など）、ハードウェアベンダーの数（OEM、ODM、SoCプロデューサーなど）、および関連するその他の利害関係者（Google、AOSP、Android開発者、Linux、Linuxディストリビューションベンダー（サーバー、デスクトップ、場合によってはモバイル）、その他のLinuxベースのプロジェクト、GNU、FSFなど、エンドユーザーまで）について考えてください。合意がないことで、私たち（ユーザー）共通の残念なことに、LinuxとAOSPの融合が確実に遅れています。ハードウェアの観点からは、主流の[マルチコアx86 CPU / > 2Gb RAM / > 16Gbフラッシュドライブ]デバイスが市場に登場した数年前に完全な融合が可能でした。このハードウェアが標準のLinuxカーネル（デスクトップではなくサーバーディストリビューション）の実行に使用できない場合、問題は明らかです。インストーラーはなく、フラッシュツールはベンダーによって公式にサポートされておらず、ドキュメントは少なく分散しています。 2019 年 6 月には状況はさらに良くなるかもしれません...
7) 次のステップは、主要なコンバージョン主導型コミュニティとサポートベンダーによる取り組みと、ハードウェアベンダーと AOSP / Google が取引交渉のために講じた措置を監視することです。