dumpstate: notes on usage
This is what a few old maintainers of dumpstate told me
when I made changes to it back ~2016 or so: always exec
stuff, never link it.
Well, there have been quite a few divergences from this,
and it's come up in a couple of reviews I've seen here.
So, I've added notes on this into the readme and comments
on some of the worst offender. For instance, we could
have probably avoided a lot of this async/exec logic
for these custom cases if we used the standard run
command with timeout stuff.
Bug: N/A
Test: N/A
Change-Id: I4c33f3042ca16d4433082b8d78ebdd29cb75f0b3
diff --git a/cmds/dumpstate/Android.bp b/cmds/dumpstate/Android.bp
index be96306..1397ae6 100644
--- a/cmds/dumpstate/Android.bp
+++ b/cmds/dumpstate/Android.bp
@@ -83,14 +83,16 @@
"aconfig_lib_cc_static_link.defaults",
"dumpstate_cflag_defaults",
],
+ // See README.md: "Dumpstate philosophy: exec not link"
+ // Do not add things here - keep dumpstate as simple as possible and exec where possible.
shared_libs: [
"android.hardware.dumpstate@1.0",
"android.hardware.dumpstate@1.1",
"android.hardware.dumpstate-V1-ndk",
"libziparchive",
"libbase",
- "libbinder",
- "libbinder_ndk",
+ "libbinder", // BAD: dumpstate should not link code directly, should only exec binaries
+ "libbinder_ndk", // BAD: dumpstate should not link code directly, should only exec binaries
"libcrypto",
"libcutils",
"libdebuggerd_client",
@@ -98,11 +100,11 @@
"libdumpstateutil",
"libdumputils",
"libhardware_legacy",
- "libhidlbase",
+ "libhidlbase", // BAD: dumpstate should not link code directly, should only exec binaries
"liblog",
"libutils",
- "libvintf",
- "libbinderdebug",
+ "libvintf", // BAD: dumpstate should not link code directly, should only exec binaries
+ "libbinderdebug", // BAD: dumpstate should not link code directly, should only exec binaries
"packagemanager_aidl-cpp",
"server_configurable_flags",
"device_policy_aconfig_flags_c_lib",