History log of /frameworks/base/libs/incident/src/IncidentReportArgs.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
437aa6e8ad24489fcd8a7ab2c889874cfae12d0b 10-Jan-2018 Yi Jin <jinyithu@google.com> Add more information to incident header. Especially add config keys
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
/frameworks/base/libs/incident/src/IncidentReportArgs.cpp
bdf58942c86240070bacc25203177cf47f6a1577 15-Nov-2017 Yi Jin <jinyithu@google.com> 1. Implement Privacy Policy Tag Inheritance
2. Expose Dest values in IIncidentReportArgs.h

Please see bug for detail descriptions.

Bug: 67869340
Test: unit tested and on-device test. Ran command:
$ out/host/linux-x86/bin/incident-section-gen incidentd
to test various of privacy taggings.
Change-Id: I12af3d7da4c7c72bd63598893fe2c1f70b09baa4
/frameworks/base/libs/incident/src/IncidentReportArgs.cpp
0f0471623e91c202fb7381a050cc331572fb439f 05-Sep-2017 Yi Jin <jinyithu@google.com> Implement Pii Stripper Part 3

The incident request args sets privacy spec. Strip action is optimized
to run once for each type of spec and ready for flush multiple times.
Incident command is updated to take -p option to specify privacy spec.

Bug: 64687253
Test: unit tests written, manually run incident command to test as well
Change-Id: I6753df117f76dc1a5f4d2152baa3fbbf56b490e4
/frameworks/base/libs/incident/src/IncidentReportArgs.cpp
1754d744a7a34731ffc07af1bc3dbfcb06864ab0 22-Nov-2016 Joe Onorato <joeo@google.com> First checkin of incident reporting.

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
/frameworks/base/libs/incident/src/IncidentReportArgs.cpp