Android ro。Typeシステムプロパティを変更する必要がある場合、おそらく2つの方法があります。1つはブートローダーのロックを解除して独自のboot.imgファイルをカスタマイズする方法、もう1つはsetpropexツールを使用する方法です。
どちらの方法にもroot権限が必要です。最初の方法はより複雑ですが、属性を永続的に変更できるという利点があります。2番目の方法は非常に単純ですが、一時的なものであり、システムの再起動は失敗します。
ここでは、プロパティを設定するためのルート権限でsetpropexを実行し、adb rootがルート権限でadbデーモンを再起動し、最後にsystem_serverプロセスを強制終了して再起動するのを待っている限り、2番目の方法を使用します。これはDalvikを再起動することです。
上記のプロセスは理論的なものですが、実際の運用プロジェクトでは失敗しており、実行環境はNexus 5、システムはバージョン4.4.4です。
問題を解決するために、setpropexのソースコードを読みます。おおよそのプロセスは、/ proc / <pid> / mapsファイルを介してinitプロセススペースで「/ dev / __ properties__（削除済み）」のアドレス範囲を見つけて、/ proc / <pidを渡すことです。 > / memこの部分のコンテンツを読み取ります。コンテンツのこの部分は実際に保存されているシステム属性であり、変更する属性アドレスを見つけて、ptraceを介して変更する値を書き込みます。余談に加えて、/ proc / <pid> / memにはmemprodroidと呼ばれる抜け穴があり、これを使用して多くのことを実行できます。興味がある場合は、調べることができます。
しかし、実際の環境と組み合わせると、initプロセスのマップファイルに「/ dev / __ properties__（deleted）」がないことがわかりましたが、「/ dev / __ properties__」の背後にある削除済みフラグの意味を確認すると、フラグが削除されることになります。ファイルがメモリにマップされた後、削除されたフラグがファイルの後に追加されます。このファイルは私のシステムに存在します。なぜ元のプログラムと異なるのかはわかりません。
次に、プログラムを後者に変更しましたが、再コンパイルして実行した後も失敗しました。コンテンツのこの部分を解析すると、デバッグで問題が発生したことがわかりました。setpropex解析部分のコードと__system_property_get関数のソースコードをbionicで比較すると、大きな違いがあることがわかりましたさらに2つの重要なデータ構造、prop_areaとprop_infoがあり、これらも異なります。propp_areaはシステムプロパティ共有メモリ全体を格納する構造である必要があり、prop_infoは特定のプロパティの構造です。さらに、setpropexとndkの<sys / _system_properties.h>の2つの構造の定義は同じです。つまり、これらの2つの構造は、ndkとAOSPのバイオニックソースコードで異なります。理由がわかりませんか？？
システムプロパティの概念について少し説明しましょう。システムプロパティはinitプロセスによって管理されます。initプロセスが開始すると、システムプロパティサービスが開始されます。Androidのシステムプロパティに対するすべての変更とクエリは、このサービスを通じて実装されます。 、つまり、サービスはinitプロセスで実行されています。サービスが開始すると、システムプロパティが4つのファイルから読み込まれます。
/default.prop
/system/build.prop
/system/default.prop
/data/local.prop
これらのファイルは共有メモリの一部に読み込まれ、プロセスが開始すると、共有メモリの各部分が独自のプロセスメモリ空間にマップされます。このマッピングプロセスは、bionic libcの__libc_preinit関数に実装されています、それはlibcがロードされるときに自動的に実行されます。
これは概念の簡単な説明にすぎません。詳細については、私が転載した別の記事を参照してください。直接クリックしてください。
上記の問題は、setpropexを使用する過程で発生した問題であり、これまで解決されていません。後で解決するために記録してください。
参照リンク：
1. http://www.cnblogs.com/bastard/archive/2012/10/11/2720314.html
2. http://blog.csdn.net/jackyu613/article/details/6136620
3. http://blog.csdn.net/xujianqun/article/details/6363318
