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
- The buffer size increased, and the CTS test that checked that
was triggering.
- Privacy filtering wasn't working for the stack trace sections
- The incident command was not handling the default arguments correctly
- The throttler was throttling streaming reports, which made the
test flaky.
Bug: 126253679
Test: atest CtsIncidentHostTestCases
Change-Id: I342cd7d0421ea8c22b7796fc99e779f21855af73
+ Remove the spawned thread inside the ReportFile for filter_and_write_report
because it leads to accessing freed memory
Instead, let the caller of ReportFile::startFileteringData create the thread.
ReportFile class shouldn't care about whether it's writing to a pipe for IPC
or regular file.
+ Add uri building in incidentd
+ Add metadata and headers to incident reports
Test: existing passed tests in incidentd_test still pass.
Manually tested with statsd
Change-Id: I5fef900d31f5d181275814f1e1c8c98443f201a7
Added or changed some error messages and logging for easier debugging.
Log a few section errors to incident metadata in addition to logcat.
Also let incident reporting continue instead of failing when non-fatal
error occurs.
Bug: 119417232
Test: Take an incident report, and logcat.
Change-Id: Id18b7b690100923a8074d99b2312ee80c0bcd760
Implement dump() function in IncidentService so that it can be dumped by
default. Dumpstate calls it twice, one with and one without '--proto'.
dump() ignores the former.
Dumpsys allows 10s max for each service. Hence, section 1200, 1201, 1202
are skipped because they take too long. Section 3008 and 3015 are
skipped temporarily due to errors. All sections should be enabled once
we find a workaround.
A follow-up change in SELinux is needed to allow dumpstate to access
incidentd.
Bug: 119417232
Test: Run `adb shell dumpsys incident --proto`, inspect result and logs
Test: Run `adb bugreport`, make sure incident.proto is in the zip file
Check the proto for validity via aprotoc:
cat incident.proto | ./out/soong/host/linux-x86/bin/aprotoc --decode_raw
Exempt-From-Owner-Approval: The original owners no longer work on this
project.
Change-Id: I7d08f6b644cb6751b201fb7ba37ac5e1c42fd3c5
A few switches didn't have explicit breaks in them, which was causing
warnings. They were all benign, as the logic did not necessitate a
break. But this is will stop the warnings and perhaps prevent future
bugs.
Change-Id: Idb293a4896f4df8d3f11d748e0e716efc26bbd6a
Fixes: 119047812
Test: N/A
FdBuffer won't take ownership of the `main` fd.
It only enforces transfer ownership in readProcessedDataInStream.
Bug: 74021345
Test: atest incidentd_test
Change-Id: I6182730241c81c34b3be865b827a2d3e8c10c21c
The incidentd will accumulate the total size put into dropbox and once
it exceeds a threshold (currently 20MB) daily, it will stop further
requests. It allows collection again 24 hours later.
Bug: 64219725
Test: atest incidentd_test and manually flashed incidentd and test.
Change-Id: Iea21fbae40d5d01108797b190231d73e74eff213
Also move incidentd integration to its own files.
clang-format -style=file -i src/anomaly/* and src/subscribers/Incidentd*
Bug: 70239380
Test: manual
Change-Id: I7bfe14d704d9e86d925365a8a21ffed726723e60
to check if the report is uploadable.
Move incidentheader.proto to libincident so statds is able to include a lite
proto class for incident header.
Change IncidentReportArgs to add the proto object instead of serialized
bytes to prevent caller gives meaningless data.
Bug: 70241842
Test: push config to statsd and verify incidentd generate the report
with correct header.
Change-Id: If95b655be71047b019b229e5903a08f3c21a1f29
There are a few major pieces here:
incidentd
---------
This daemon (started by init) runs and accepts incoming requests to take
incident reports. When prompted, it calls into various system services
and fills in an IncidentProto data structure, and then writes the report
into dropbox.
The next steps for incidentd:
- Security review of SELinux policies. These will be a subset of
the dumpstate permissions. Until this is done, incidentd is
not started at boot time.
incident
--------
This shell command calls into incidentd, and can initiate an incident
report and either capture the output or leave for dropbox.
incident_report
---------------
This host side tool can call adb shell with the correct parameters
and also format the incident report as text. This formatting code
was left of the device on purpose. Right now it's pretty small, but
as the number of fields increases, the metadata and code to do the
formatting will start to grow.
The incident_report command also contains a workaround to let it
work before incidentd is turned on by default. Right now, it is
implemented to call adb shell dumpsys <service> --proto directly,
whereas in the future it will go through the full incidentd flow.
incident_section_gen
--------------------
A build-time tool that generates a stripped down set of information
about the fields that are available.
libincident
-----------
This library contains the code to connect to incidentd, and the
meta proto definitions that are used by the framework protos.
The basics are here now, but they are not fully fleshed out yet.
The privacy.proto file contains annotations that can go in the
proto file that we will later use to filter which fields are
uploaded, and which are used by local sources. For example, a
device in a test lab is safe to upload much much more information
than a real user. These will share the same mechanism, but the
user's output will be filtered according to these annotations.
frameworks/core/proto
---------------------
These .proto files contain the definitions of the system's
output. There is one master android.os.IncidentProto file that
is the top level of an incident report, but some other services
(notification, fingerprint, batterystats, etc) will have others
that are used directly by the logging mechanism.
Other files which are shared by several of the services also go
here, such as ComponentName, Locale, Configuration, etc. There
will be many more.
There is also a first iplementation of a dump method handling
--proto in the fingerprint service.
IncidentManager
---------------
The java API to trigger an incident report.
Test: Not written yet
Change-Id: I59568b115ac7fcf73af70c946c95752bf33ae67f
