15f83a3118
Instead of just relying on the regular iteration through the system
services inside dumpstate, add another API to IIncidentManager
dedicated for dumpstate.
- It is only callable by dumpstate() (check the calling uid)
- It has the same behavior as the current call inside dump()
Advantages:
- More explicit function name, right next to takeIncidentReport will
make it easier to keep them in sync.
- Nobody else can call it, make security easier.
- If dumpstate calls it explicitly, it can skip the 10 second timeout
- The regular dump() call should provide debugging data about
incidentd itself, for example timestamps for the most recent N
incident reports taken and the current state of the work directory,
allowing us to debug incidentd itself.
Bug: 137493082
Test: Manually trigger a bug report, and verify
/proto/incident_log.proto in the zip file.
Change-Id: I19139c765b53ede63d3beb3ea3ac40ada1aba42d
Merged-In: I19139c765b53ede63d3beb3ea3ac40ada1aba42d
incidentd
How to build, deploy, unit test
For the first time, build the test and create an empty directly on device:
root$ make -j incidentd_test && adb shell mkdir /data/nativetest/incidentd_test
Run the test on a device manually
root$ mmm -j frameworks/base/cmds/incidentd && \
adb push $OUT/data/nativetest/incidentd_test/* /data/nativetest/ && \
adb shell /data/nativetest/incidentd_test 2>/dev/null
Run the test via AndroidTest.xml
root$ atest incidentd_test
Use clang-format to style the file
clang-format -style=file -i