androidでadb ShellからSDカードを手動でマウントします

Question

私はAndroid 4.1電話（Lenovo 820）を持っています。内部SD ramをパーティション分割することを目的としたいくつかの変更の後（変更されたため、電話はマウントされなくなりますexternal SD私はLinuxが得意ですが、Androidシェルを今日まで見たことがありません。

次の手順を教えてください。

• SDカードを表す利用可能なデバイスのリストを取得する
• SDカードを手動でマウントします-can't read /etc/fstabのように、mountコマンドは機能しません-どのようにマウントしますか？
• 起動時にSDカードをマウントする

私の/etc/system/vold.fstabには：

dev_mount sdcard /storage/sdcard0 emmc@fat /devices/platform/goldfish_mmc.0 /devices/platform/mtk-msdc.0/mmc_Host
dev_mount sdcard2 /storage/sdcard1 auto /devices/platform/goldfish_mmc.1 /devices/platform/mtk-msdc.1/mmc_Host

マウントは今です：

rootfs on / type rootfs (ro,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt/secure type tmpfs (rw,relatime,mode=700)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/emmc@Android on /system type ext4 (ro,relatime,nobarrier,noauto_da_alloc,commit=1)
/emmc@usrdata on /data type ext4 (rw,nosuid,nodev,noatime,nodiratime,discard,nobarrier,noauto_da_alloc)
/emmc@cache on /cache type ext4 (rw,nosuid,nodev,noatime,nodiratime,discard,nobarrier,noauto_da_alloc)
/emmc@protect_f on /protect_f type ext4 (rw,nosuid,nodev,noatime,nodelalloc,noauto_da_alloc,commit=1,data=ordered)
/emmc@protect_s on /protect_s type ext4 (rw,nosuid,nodev,noatime,nodelalloc,noauto_da_alloc,commit=1,data=ordered)

Answer 1

2か月で誰もあなたに返事をくれなかったなんて信じられませんか？うわー...なんとたるんだ！

とにかく、私はあなたにいくつかの情報を記入し、いくつかの質問をするべきだと思います。 1）。 rootアクセス権を持っていますか、それともリリースイメージ/ファームウェアからシステムvoldをプルしましたか？ Linuxのスーパーユーザー権限が好きですか？ 2）。 rootアクセス/スーパーユーザー権限がある場合、どうやってそれを取得しましたか？ルートアクセスを取得するためにどの方法を使用しましたか？いくつかのスクリプト/バイナリと既知のエクスプロイトを介したものでしたか？または、ルート化されたカーネルを使用してフラッシュされましたか？私が尋ねる理由は、ほとんどの人が信じるように導かれるので、rootアクセスは単なるrootアクセスではないということです。ルートアクセスにはさまざまなレベルがあります。たとえば、デバイスのユーザーとして完全なrootアクセス権を持っているかもしれませんが、お気に入りのLinuxディストリビューションのコマンドラインからリモートでシステムを操作したいときは、rootアクセス権がすべてではないことに気づくかもしれませんあります。カーネルではなくエクスプロイトを使用した場合、システムレベルのルートアクセスのみがあり、PCへのADB（Androidデバッグブリッジ）が「アクセス拒否」、「スーパーユーザー権限を取得できません」などのさまざまなメッセージに直面する可能性があります。または「adbはプロダクションビルドではrootとして実行できません」またはこれに似たものです。これが発生する理由は、エクスプロイトを介してroot化された一部の特殊な開発者カーネルとは異なり、カーネルを安全にしないためです。安全でないカーネルとは何か、そしてそれがあなたが達成したいものに適しているかどうかについて少し読んでおくことをお勧めします。私が言う理由は、安全でないカーネルを持つ一部のデバイスでは、不要なシステムフラグ（一部のメーカーによれば永続的で不可逆的なもの）をトリガーする可能性があり、保証を守らないために開発者に対して使用されるため、または抽出する手段として理想的ではないためですデバイスのプレミアム修理サービスの費用（あなたが開発者に発見を突破することを望んでいるかどうかに関係なく...デバイスに損傷を与えたかどうか、どのsuxか）。あなたのデバイスは大丈夫だと思います...？しかし、私は100％確実ではないので、いくつかの調査を行います。

安全でないカーネルを実行できないことがわかった場合、それは世界の終わりではありません。必要なものを得るにはもう少し作業が必要です。これについては後で例を挙げて詳しく説明します。

次に考慮する必要があるのは、デバイス内/デバイス上の目的の場所に到達したときに何をしたいかです。そんなに考えたことはありますか？もしそうなら、標準のAndroidconsole/ShellはLinuxで瞬く間にできるすべての素晴らしいことを実行するためのツールを備えており、かなり気が悪く、装備が整っていないことに気付くでしょう。つまり、「busybox」などの他のサポートツールも必要になる可能性があります。たとえば、いくつかのデータベースで作業している場合、おそらくsqlite3が必要ですが、実際のbashバイナリを拡張して、少しシェル。また、これらのバイナリを取得するだけでなく、アクセスを容易にするためにシステム上のどこに配置する必要があるかも確認する必要があります。そうしないと、コンソールに巨大な長いパスを入力してデバイスの特定の領域に到達するのに飽きてしまいます。あなたのSDカードのように。 Linuxを使用したシンボリックリンクについてはよくご存じでしょう。Androidは、多くのシステムAndroidがアプリケーション用の環境のようなコンテナーを使用していることだけは同じです。これに対処する場合、システムに不要なサードパーティによる侵入を阻止するためのセキュリティチェックが設定されているため、克服しなければならないいくつかのハードルがある可能性があります。これにより、ほとんどの開発者は（およびあなたの）個人データが保護されていることを安全に知ることができます。ただし、これがあなたであり、デバイスのこれらの領域に行きたい場合は、ツールを正しく設定する必要があります。ほとんどのAndroid改ざん者は、変更されたリカバリイメージ（またはカスタムイメージ-カスタムカーネルの概念とそれほど似ていないもの）を使用します。埋め込みの説明用スクリプト、バイナリ、およびマニフェスト（Androidカスタムリカバリ用の署名付きおよび署名なしのzipを調査します-詳細については触れませんが、重要です）。基本的に、すべてのツールを単一のZipにパッケージ化し、コンポーネントを必要なシステムの領域に「フラッシュ」インストールして、同じファイルを他のさまざまな場所にシンボリックリンクすることもできます。

ここでいくつかの例を見てみましょう-ルートアクセスがあり、デバイスでエクスプロイトを使用したが、まだセキュアカーネルがあることに注意してください：システムのdefault.propファイル内のセキュアカーネル= ro.debugable=0（ブート時に生成され、ほとんどのファームウェアパッケージ内に見つからないか、見つかりません）。 adbにrootアクセスを許可したい場合は、そのファイル、特に上記の行を変更する必要があります。他の要件もあるので、デバイスに必要なものを検討する必要があります。私が現在修復しているGalaxy Tabは古いので、メディア転送プロトコルの代わりに大容量ストレージを使用しているため、デバイスに接続しているときは接続を開いたままにしておき（タイムアウトや切断ではなく）、adbに通知する必要があります。これは、たまたまdefault.propファイルを介して行われます。このファイルを変更するときに問題が発生します。ほとんどの人は、カーネルとRAMディスクを逆コンパイルして直接編集し、再コンパイルしてからデバイスに再フラッシュします。主な理由は、現時点ではadbにrootアクセス権がないためです。次のようにシステムからファイルをプルすることができます：

adb pull default.prop default.prop

（つまり、PCディストリビューション環境パスにadbがある場合）

これはあなたを真っ直ぐに連れて行きます、問題はあなたがそれを変えた後にそれを元に戻したいときにかなり難しいかもしれません。さまざまな解決策があり、それをSDカード/emmc/storage/sdcard0/default.propまたは/tmp/default.propにプッシュして、ターミナルエミュレーター、スクリプトマネージャーなどを使用してデバイスで「スーパーユーザー」として要求することをよく聞きますまたはルートエクスプローラーを使用してファイルを元の場所に戻し、適切な権限を付与します。

安全なカーネルを備えたデバイスでadb remountと入力すると、システム全体を読み書き可能として再マウントでき、好きなように実行できます。安全でない場合、あなたは次のようなことをするかもしれませんが

adb root
remount

または、コンソール全体にこれまでのところスーパーユーザー権限がないことに気付く可能性があるため、デバイスシェル（シェルまたはスーパーユーザー権限がある場合）にシェルをadbし、試行するコマンドを実行する必要があります。

adb Shell
su
mount -o rw /system
remount /system

私は最近、次のようにadbコンソールの1行と1つのリターンキーを使用して同じレベルのアクセスを取得できることを発見しました。

adb Shell su -c mount -o rw,remount /system

これにより、引数が単一文字列のadb Shell->スーパーユーザーアクセス-> passコマンド->読み取り/書き込みとしてマウント-> remountコマンド->でシステムパーティションに渡されます。

上記のコマンドを使用して、コンソールからスーパーユーザー権限を取得し、カーネルを逆コンパイルすることなく文字列をdefault.propファイルにエコーしたい場合は、.

私の場合、同じコマンドを数回繰り返し、同じ内容で特定の変数を調整するだけでdefault.propを上書きしました：最初の行は1>のみを使用しているので、これは事実上、default.propをワイプまたは上書きすることに注意してくださいファイルなので、残りの行も従う必要があります。これはファイルの次の行に追加されるため、2> like >>を使用します。

adb Shell su -c echo ro.secure=1>default.prop
adb Shell su -c echo ro.allow.mock.location=0>>default.prop
adb Shell su -c echo ro.debuggable=1>>default.prop
adb Shell su -c echo persist.sys.usb.config=mass_storage,adb>>default.prop
adb Shell su -c echo persist.service.adb.enable=0>>default.prop

これは4行または5行のコードに対してはかなり高速で効果的ですが、多数のテスト行を含む大きなファイルを書き換える場合、これは実用的ではありません。大きなtext/script/configファイルの特定の行をフィルタリングするために、bashスクリプトでループ関数を使ったgrepのようなものを調べたいと思うかもしれませんが、この例ではおそらくシステムのvoldファイルでこれで十分でしょう。

私はこれで（しゃれを許して）ARM危険になるのに十分な情報を得るのに十分であるべきだと思います:)そのことについて、いじる前に、デバイスのバックアップがあることを確認してくださいシステム。それらはlinuxに非常に似ていますが、非常に異なっています。この警告に注意して、EFSパーティションを完全にバックアップしてください。 EfsにはデバイスのIMEI番号が含まれていますが、これは本当に破損したり失われたりしたくないものです。私は何が起こり得るかを直接見てきました。 EFSパーティションを誤って呼び出して破壊する必要はありません。誤ったパーティションへの明示的なパスの呼び出しでエラーを発生させるだけで、IMEIが破壊される可能性があります。