背景
マー兄弟が winscope を使用してさまざまなフラッシュ ブラック、ブラック スクリーン、その他の問題を分析する方法を説明した後、コースを購入した多くの学生がこのツールを実際の企業プロジェクトで使用し始めましたが、多くの学生は別の問題を発見し始めました。ユーザー版のモバイル端末では当該winscopeをキャプチャできず、たとえキャプチャできたとしても分析用にエクスポートできないことが判明しました。この問題についてグループ内のブラザー・マーに助けを求めてください。今日は関連する解決策をいくつか紹介します。
フラッシュ ブラックアウトなどを解決するための winscope の詳細な使用方法については、私の b サイト ビデオまたは有料ビデオをご覧ください。ビデオを直接見て、私に連絡することができます
https://www.bilibili.com/video/BV14M411M7Pu/
1. ユーザーの携帯電話の Web ページから winscope を取得できませんでした
ユーザーの携帯電話に対する winscope の影響は次のとおりです。
常にエラーが表示されることがわかりますが、エラーの具体的な原因は何でしょうか?
サーバー側の Python プログラムから出力される毎日のログを見てください。
サーバーが関連する adb シェル コマンドのみを実行することは明らかですが、このコマンドには su root などの高レベルの権限が必要です。当然のことながら、ユーザーの携帯電話では利用できません。
2. 携帯電話でキャプチャすることはできますが、ファイルを取得する権限はありません。
ショートカットボタンは設定で解除可能
クロールが完了すると、関連するトレース ファイルが作成されます。
トレース ファイルが data/misc/wmtrace フォルダーにエクスポートされたことがわかります。それからそれを取り出して
、次の権限の問題を見つけてください。
このwmtraceフォルダには権限が全くないので取り出すことができないことが分かります。
3. 解決策を模索してみる
bugreoport コマンドを使用します。
test@test:~$ adb bugreport
/data/user_de/0/com.android.shell/files/bugreports/bugreport-crosshatch-SP1A.210812.016.C1-2022-06-28-12-21-13.zip: 1 file pulled. 27.7 MB/s (11790205 bytes in 0.406s)
test@test:~$ adb pull /data/user_de/0/com.android.shell/files/bugreports/bugreport-crosshatch-SP1A.210812.016.C1-2022-06-28-12-21-13.zip
/data/user_de/0/com.android.shell/files/bugreports/bugreport-crosshatch-SP1A.210812.016.C1-2022-06-28-12-21-13.zip: 1 file pulled. 27.7 MB/s (11790205 bytes in 0.406s)
この bugreport コマンドによってエクスポートされた関連ファイルを見てください。
misc 自体には adb シェルを表示する権限がないため、FS フォルダーの下に misc フォルダーの下に data フォルダーがあることがわかりました。。
しかし、状況は次のとおりです。
リカバリのみが関連しており、wmtrace 関連のフォルダーは表示されません。
しかし、これは明らかに /data/misc/wmtrace パスですが、エクスポートされないのはなぜですか?
理由を知りたい場合は、ソース コードを参照する必要があります。
まず、バグレポートは、adb シェルによって起動されるプロセスでもあるため、最大でもシェル権限しか持てないことを理解する必要があります。しかし、なぜエクスポートできるのでしょうか
。 data/misc/ の下の関連フォルダー
これを解読するには、関連するソース コードFrameworks/native/cmds/bugreport/bugreport.cppを確認します。
int main() {
fprintf(stderr,
"=============================================================================\n");
fprintf(stderr, "WARNING: Flat (text file, non-zipped) bugreports are deprecated.\n");
fprintf(stderr, "WARNING: Please generate zipped bugreports instead.\n");
fprintf(stderr, "WARNING: On the host use: adb bugreport filename.zip\n");
fprintf(stderr, "WARNING: On the device use: bugreportz\n");
fprintf(stderr, "WARNING: bugreportz will output the filename to use with adb pull.\n");
fprintf(stderr,
"=============================================================================\n\n\n");
return 0;
}
ここで、bugreport が実際には空のシェルであることがわかります。Bugreportz は実際に動作しています。bugreportz
の関連コマンドを見てください:
Frameworks/native/cmds/bugreportz/main.cpp
int main(int argc, char* argv[]) {
//省略
// TODO: code below was copy-and-pasted from bugreport.cpp (except by the
// timeout value);
// should be reused instead.
// Start the dumpstatez service.
//启动相关的 dumpstate服务
if (stream_data) {
property_set("ctl.start", "dumpstate");
} else {
property_set("ctl.start", "dumpstatez");
}
// Socket will not be available until service starts.
int s = -1;
for (int i = 0; i < 20; i++) {
//与dumpstate进行本地socket跨进程通讯
s = socket_local_client("dumpstate", ANDROID_SOCKET_NAMESPACE_RESERVED, SOCK_STREAM);
if (s >= 0) break;
// Try again in 1 second.
sleep(1);
}
int ret;
//socket接受相关的数据进行处理
if (stream_data) {
ret = bugreportz_stream(s);
} else {
ret = bugreportz(s, show_progress);
}
return ret;
}
概要を次の図に示します。
識別方法:
bugreport コマンドを実行する場合:
test@test:~/aosp/frameworks/native/cmds$ adb bugreport
[ 5%] generating bugreport-crosshatch-SP1A.210812.016.C1-2022-06-28-13-02-19.zip
ターミナルで別の adb シェルを開いて、dumpstate サービスの権限を確認します。
crosshatch:/ $ ps -A | grep dump
root 16137 1 10878140 5172 0 0 S dumpstate
これが root 権限を持つプロセスであることは明らかです。
4. 原因と解決策の探求
バグレポートの原理は上で分析しましたが、実際には高権限のルートを取得するために dumpstate が使用されていますが、問題は、なぜ wmtrace 関連のフォルダーがあるのかということです。この質問は、dumpstate の関連ソース コードに依存します。
Frameworks/native/cmds/dumpstate/dumpstate.cpp には
次のコードがありました。
#define PSTORE_LAST_KMSG "/sys/fs/pstore/console-ramoops"
#define ALT_PSTORE_LAST_KMSG "/sys/fs/pstore/console-ramoops-0"
#define BLK_DEV_SYS_DIR "/sys/block"
#define RECOVERY_DIR "/cache/recovery"
#define RECOVERY_DATA_DIR "/data/misc/recovery"
#define UPDATE_ENGINE_LOG_DIR "/data/misc/update_engine_log"
#define LOGPERSIST_DATA_DIR "/data/misc/logd"
#define PREREBOOT_DATA_DIR "/data/misc/prereboot"
#define PROFILE_DATA_DIR_CUR "/data/misc/profiles/cur"
#define PROFILE_DATA_DIR_REF "/data/misc/profiles/ref"
#define XFRM_STAT_PROC_FILE "/proc/net/xfrm_stat"
#define WLUTIL "/vendor/xbin/wlutil"
#define WMTRACE_DATA_DIR "/data/misc/wmtrace"
#define OTA_METADATA_DIR "/metadata/ota"
#define SNAPSHOTCTL_LOG_DIR "/data/misc/snapshotctl_log"
#define LINKERCONFIG_DIR "/linkerconfig"
#define PACKAGE_DEX_USE_LIST "/data/system/package-dex-usage.list"
#define SYSTEM_TRACE_SNAPSHOT "/data/misc/perfetto-traces/bugreport/systrace.pftrace"
#define CGROUPFS_DIR "/sys/fs/cgroup"
RECOVERY_DATA_DIR や WMTRACE_DATA_DIR など、データ関連のディレクトリが 1 つずつリストされていることがわかります。ここでは、WMTRACE_DATA_DIR がエクスポートされなかった理由に焦点を当て、関連する制限があるかどうかを確認します。
次のコードを見ると、ここでの 1 つの条件は!PropertiesHelper::IsUserBuild() です。
つまり、WMTRACE_DATA_DIR ディレクトリは非ユーザーの携帯電話でのみエクスポートできます。
/* Add window and surface trace files. */
if (!PropertiesHelper::IsUserBuild()) {
ds.AddDir(WMTRACE_DATA_DIR, false);
}
変更計画の調査:
1. if (!PropertiesHelper::IsUserBuild()) 条件を直接削除します (より暴力的で安全ではありません)
//if (!PropertiesHelper::IsUserBuild()) {
ds.AddDir(WMTRACE_DATA_DIR, false);
// }
2. or 条件を追加して、独自の秘密のドアを追加できます (これをお勧めします) たとえば、adb シェルを通じて変更できるプロップを自分で作成することもできます。
if (!PropertiesHelper::IsUserBuild() || isEnableProp（）) {
ds.AddDir(WMTRACE_DATA_DIR, false);
}