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
2016-11-21 17:51:35 -08:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2016 The Android Open Source Project
|
|
|
|
*
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
*
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define LOG_TAG "incident"
|
|
|
|
|
|
|
|
#include "incident_sections.h"
|
|
|
|
|
|
|
|
#include <android/os/BnIncidentReportStatusListener.h>
|
|
|
|
#include <android/os/IIncidentManager.h>
|
|
|
|
#include <android/os/IncidentReportArgs.h>
|
|
|
|
#include <binder/IPCThreadState.h>
|
|
|
|
#include <binder/IServiceManager.h>
|
|
|
|
#include <utils/Looper.h>
|
|
|
|
|
2017-09-05 13:44:22 -07:00
|
|
|
#include <cstring>
|
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
2016-11-21 17:51:35 -08:00
|
|
|
#include <fcntl.h>
|
|
|
|
#include <getopt.h>
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
|
|
|
|
using namespace android;
|
|
|
|
using namespace android::base;
|
|
|
|
using namespace android::binder;
|
|
|
|
using namespace android::os;
|
|
|
|
|
|
|
|
// ================================================================================
|
|
|
|
class StatusListener : public BnIncidentReportStatusListener {
|
|
|
|
public:
|
|
|
|
StatusListener();
|
|
|
|
virtual ~StatusListener();
|
|
|
|
|
|
|
|
virtual Status onReportStarted();
|
|
|
|
virtual Status onReportSectionStatus(int32_t section, int32_t status);
|
|
|
|
virtual Status onReportServiceStatus(const String16& service, int32_t status);
|
|
|
|
virtual Status onReportFinished();
|
|
|
|
virtual Status onReportFailed();
|
|
|
|
};
|
|
|
|
|
|
|
|
StatusListener::StatusListener()
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
StatusListener::~StatusListener()
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
Status
|
|
|
|
StatusListener::onReportStarted()
|
|
|
|
{
|
|
|
|
return Status::ok();
|
|
|
|
}
|
|
|
|
|
|
|
|
Status
|
|
|
|
StatusListener::onReportSectionStatus(int32_t section, int32_t status)
|
|
|
|
{
|
|
|
|
fprintf(stderr, "section %d status %d\n", section, status);
|
2019-02-11 15:55:13 +00:00
|
|
|
ALOGD("section %d status %d\n", section, status);
|
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
2016-11-21 17:51:35 -08:00
|
|
|
return Status::ok();
|
|
|
|
}
|
|
|
|
|
|
|
|
Status
|
|
|
|
StatusListener::onReportServiceStatus(const String16& service, int32_t status)
|
|
|
|
{
|
|
|
|
fprintf(stderr, "service '%s' status %d\n", String8(service).string(), status);
|
2019-02-11 15:55:13 +00:00
|
|
|
ALOGD("service '%s' status %d\n", String8(service).string(), status);
|
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
2016-11-21 17:51:35 -08:00
|
|
|
return Status::ok();
|
|
|
|
}
|
|
|
|
|
|
|
|
Status
|
|
|
|
StatusListener::onReportFinished()
|
|
|
|
{
|
|
|
|
fprintf(stderr, "done\n");
|
2019-02-11 15:55:13 +00:00
|
|
|
ALOGD("done\n");
|
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
2016-11-21 17:51:35 -08:00
|
|
|
exit(0);
|
|
|
|
return Status::ok();
|
|
|
|
}
|
|
|
|
|
|
|
|
Status
|
|
|
|
StatusListener::onReportFailed()
|
|
|
|
{
|
|
|
|
fprintf(stderr, "failed\n");
|
2019-02-11 15:55:13 +00:00
|
|
|
ALOGD("failed\n");
|
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
2016-11-21 17:51:35 -08:00
|
|
|
exit(1);
|
|
|
|
return Status::ok();
|
|
|
|
}
|
|
|
|
|
2017-06-22 19:23:11 -07:00
|
|
|
// ================================================================================
|
|
|
|
static void section_list(FILE* out) {
|
|
|
|
IncidentSection sections[INCIDENT_SECTION_COUNT];
|
|
|
|
int i = 0;
|
|
|
|
int j = 0;
|
|
|
|
// sort the sections based on id
|
|
|
|
while (i < INCIDENT_SECTION_COUNT) {
|
|
|
|
IncidentSection curr = INCIDENT_SECTIONS[i];
|
|
|
|
for (int k = 0; k < j; k++) {
|
|
|
|
if (curr.id > sections[k].id) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
IncidentSection tmp = curr;
|
|
|
|
curr = sections[k];
|
|
|
|
sections[k] = tmp;
|
|
|
|
}
|
|
|
|
sections[j] = curr;
|
|
|
|
i++;
|
|
|
|
j++;
|
|
|
|
}
|
|
|
|
|
|
|
|
fprintf(out, "available sections:\n");
|
|
|
|
for (int i = 0; i < INCIDENT_SECTION_COUNT; ++i) {
|
|
|
|
fprintf(out, "id: %4d, name: %s\n", sections[i].id, sections[i].name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
2016-11-21 17:51:35 -08:00
|
|
|
// ================================================================================
|
|
|
|
static IncidentSection const*
|
|
|
|
find_section(const char* name)
|
|
|
|
{
|
|
|
|
size_t low = 0;
|
|
|
|
size_t high = INCIDENT_SECTION_COUNT - 1;
|
|
|
|
|
|
|
|
while (low <= high) {
|
|
|
|
size_t mid = (low + high) >> 1;
|
|
|
|
IncidentSection const* section = INCIDENT_SECTIONS + mid;
|
|
|
|
|
|
|
|
int cmp = strcmp(section->name, name);
|
|
|
|
if (cmp < 0) {
|
|
|
|
low = mid + 1;
|
|
|
|
} else if (cmp > 0) {
|
|
|
|
high = mid - 1;
|
|
|
|
} else {
|
|
|
|
return section;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-09-05 13:44:22 -07:00
|
|
|
// ================================================================================
|
|
|
|
static int
|
2019-02-11 15:55:13 +00:00
|
|
|
get_privacy_policy(const char* arg)
|
2017-09-05 13:44:22 -07:00
|
|
|
{
|
2018-01-24 17:33:35 -08:00
|
|
|
if (strcmp(arg, "L") == 0
|
|
|
|
|| strcmp(arg, "LOCAL") == 0) {
|
2019-02-11 15:55:13 +00:00
|
|
|
return PRIVACY_POLICY_LOCAL;
|
2018-01-24 17:33:35 -08:00
|
|
|
}
|
|
|
|
if (strcmp(arg, "E") == 0
|
|
|
|
|| strcmp(arg, "EXPLICIT") == 0) {
|
2019-02-11 15:55:13 +00:00
|
|
|
return PRIVACY_POLICY_EXPLICIT;
|
2018-01-24 17:33:35 -08:00
|
|
|
}
|
|
|
|
if (strcmp(arg, "A") == 0
|
|
|
|
|| strcmp(arg, "AUTO") == 0
|
|
|
|
|| strcmp(arg, "AUTOMATIC") == 0) {
|
2019-02-11 15:55:13 +00:00
|
|
|
return PRIVACY_POLICY_AUTOMATIC;
|
2018-01-24 17:33:35 -08:00
|
|
|
}
|
2017-09-05 13:44:22 -07:00
|
|
|
return -1; // return the default value
|
|
|
|
}
|
|
|
|
|
2019-02-11 15:55:13 +00:00
|
|
|
// ================================================================================
|
|
|
|
static bool
|
|
|
|
parse_receiver_arg(const string& arg, string* pkg, string* cls)
|
|
|
|
{
|
|
|
|
if (arg.length() == 0) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
size_t slash = arg.find('/');
|
|
|
|
if (slash == string::npos) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (slash == 0 || slash == arg.length() - 1) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (arg.find('/', slash+1) != string::npos) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
pkg->assign(arg, 0, slash);
|
|
|
|
cls->assign(arg, slash+1);
|
|
|
|
if ((*cls)[0] == '.') {
|
|
|
|
*cls = (*pkg) + (*cls);
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
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
2016-11-21 17:51:35 -08:00
|
|
|
// ================================================================================
|
|
|
|
static void
|
|
|
|
usage(FILE* out)
|
|
|
|
{
|
|
|
|
fprintf(out, "usage: incident OPTIONS [SECTION...]\n");
|
|
|
|
fprintf(out, "\n");
|
|
|
|
fprintf(out, "Takes an incident report.\n");
|
|
|
|
fprintf(out, "\n");
|
|
|
|
fprintf(out, "OPTIONS\n");
|
2019-02-11 15:55:13 +00:00
|
|
|
fprintf(out, " -l list available sections\n");
|
|
|
|
fprintf(out, " -p privacy spec, LOCAL, EXPLICIT or AUTOMATIC. Default AUTOMATIC.\n");
|
|
|
|
fprintf(out, "\n");
|
|
|
|
fprintf(out, "and one of these destinations:\n");
|
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
2016-11-21 17:51:35 -08:00
|
|
|
fprintf(out, " -b (default) print the report to stdout (in proto format)\n");
|
|
|
|
fprintf(out, " -d send the report into dropbox\n");
|
2019-02-11 15:55:13 +00:00
|
|
|
fprintf(out, " -s PKG/CLS send broadcast to the broadcast receiver.\n");
|
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
2016-11-21 17:51:35 -08:00
|
|
|
fprintf(out, "\n");
|
|
|
|
fprintf(out, " SECTION the field numbers of the incident report fields to include\n");
|
|
|
|
fprintf(out, "\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
main(int argc, char** argv)
|
|
|
|
{
|
|
|
|
Status status;
|
|
|
|
IncidentReportArgs args;
|
2019-02-11 15:55:13 +00:00
|
|
|
enum { DEST_UNSET, DEST_DROPBOX, DEST_STDOUT, DEST_BROADCAST } destination = DEST_UNSET;
|
|
|
|
int privacyPolicy = PRIVACY_POLICY_AUTOMATIC;
|
|
|
|
string receiverArg;
|
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
2016-11-21 17:51:35 -08:00
|
|
|
|
|
|
|
// Parse the args
|
|
|
|
int opt;
|
2019-02-11 15:55:13 +00:00
|
|
|
while ((opt = getopt(argc, argv, "bhdlp:s:")) != -1) {
|
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
2016-11-21 17:51:35 -08:00
|
|
|
switch (opt) {
|
|
|
|
case 'h':
|
|
|
|
usage(stdout);
|
|
|
|
return 0;
|
2017-06-22 19:23:11 -07:00
|
|
|
case 'l':
|
|
|
|
section_list(stdout);
|
|
|
|
return 0;
|
|
|
|
case 'b':
|
2019-02-11 15:55:13 +00:00
|
|
|
if (!(destination == DEST_UNSET || destination == DEST_STDOUT)) {
|
|
|
|
usage(stderr);
|
|
|
|
return 1;
|
|
|
|
}
|
2017-06-22 19:23:11 -07:00
|
|
|
destination = DEST_STDOUT;
|
|
|
|
break;
|
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
2016-11-21 17:51:35 -08:00
|
|
|
case 'd':
|
2019-02-11 15:55:13 +00:00
|
|
|
if (!(destination == DEST_UNSET || destination == DEST_DROPBOX)) {
|
|
|
|
usage(stderr);
|
|
|
|
return 1;
|
|
|
|
}
|
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
2016-11-21 17:51:35 -08:00
|
|
|
destination = DEST_DROPBOX;
|
|
|
|
break;
|
2017-09-05 13:44:22 -07:00
|
|
|
case 'p':
|
2019-02-11 15:55:13 +00:00
|
|
|
privacyPolicy = get_privacy_policy(optarg);
|
|
|
|
break;
|
|
|
|
case 's':
|
|
|
|
if (destination != DEST_UNSET) {
|
|
|
|
usage(stderr);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
destination = DEST_BROADCAST;
|
|
|
|
receiverArg = optarg;
|
2017-09-05 13:44:22 -07:00
|
|
|
break;
|
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
2016-11-21 17:51:35 -08:00
|
|
|
default:
|
|
|
|
usage(stderr);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-02-11 15:55:13 +00:00
|
|
|
string pkg;
|
|
|
|
string cls;
|
|
|
|
if (parse_receiver_arg(receiverArg, &pkg, &cls)) {
|
|
|
|
args.setReceiverPkg(pkg);
|
|
|
|
args.setReceiverCls(cls);
|
|
|
|
} else {
|
|
|
|
fprintf(stderr, "badly formatted -s package/class option: %s\n\n", receiverArg.c_str());
|
|
|
|
usage(stderr);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
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
2016-11-21 17:51:35 -08:00
|
|
|
if (optind == argc) {
|
|
|
|
args.setAll(true);
|
|
|
|
} else {
|
|
|
|
for (int i=optind; i<argc; i++) {
|
|
|
|
const char* arg = argv[i];
|
|
|
|
char* end;
|
|
|
|
if (arg[0] != '\0') {
|
|
|
|
int section = strtol(arg, &end, 0);
|
|
|
|
if (*end == '\0') {
|
|
|
|
args.addSection(section);
|
|
|
|
} else {
|
|
|
|
IncidentSection const* ic = find_section(arg);
|
|
|
|
if (ic == NULL) {
|
|
|
|
fprintf(stderr, "Invalid section: %s\n", arg);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
args.addSection(ic->id);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2019-02-11 15:55:13 +00:00
|
|
|
args.setPrivacyPolicy(privacyPolicy);
|
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
2016-11-21 17:51:35 -08:00
|
|
|
|
|
|
|
// Start the thread pool.
|
|
|
|
sp<ProcessState> ps(ProcessState::self());
|
|
|
|
ps->startThreadPool();
|
|
|
|
ps->giveThreadPoolName();
|
|
|
|
|
|
|
|
// Look up the service
|
|
|
|
sp<IIncidentManager> service = interface_cast<IIncidentManager>(
|
|
|
|
defaultServiceManager()->getService(android::String16("incident")));
|
|
|
|
if (service == NULL) {
|
|
|
|
fprintf(stderr, "Couldn't look up the incident service\n");
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Construct the stream
|
|
|
|
int fds[2];
|
|
|
|
pipe(fds);
|
|
|
|
|
|
|
|
unique_fd readEnd(fds[0]);
|
|
|
|
unique_fd writeEnd(fds[1]);
|
|
|
|
|
|
|
|
if (destination == DEST_STDOUT) {
|
|
|
|
// Call into the service
|
|
|
|
sp<StatusListener> listener(new StatusListener());
|
|
|
|
status = service->reportIncidentToStream(args, listener, writeEnd);
|
|
|
|
|
|
|
|
if (!status.isOk()) {
|
|
|
|
fprintf(stderr, "reportIncident returned \"%s\"\n", status.toString8().string());
|
2017-08-03 18:50:48 -07:00
|
|
|
return 1;
|
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
2016-11-21 17:51:35 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Wait for the result and print out the data they send.
|
|
|
|
//IPCThreadState::self()->joinThreadPool();
|
|
|
|
|
|
|
|
while (true) {
|
2019-02-11 15:55:13 +00:00
|
|
|
uint8_t buf[4096];
|
|
|
|
ssize_t amt = TEMP_FAILURE_RETRY(read(fds[0], buf, sizeof(buf)));
|
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
2016-11-21 17:51:35 -08:00
|
|
|
if (amt < 0) {
|
2019-02-11 15:55:13 +00:00
|
|
|
break;
|
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
2016-11-21 17:51:35 -08:00
|
|
|
} else if (amt == 0) {
|
2019-02-11 15:55:13 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
ssize_t wamt = TEMP_FAILURE_RETRY(write(STDOUT_FILENO, buf, amt));
|
|
|
|
if (wamt != amt) {
|
|
|
|
return errno;
|
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
2016-11-21 17:51:35 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
status = service->reportIncident(args);
|
|
|
|
if (!status.isOk()) {
|
|
|
|
fprintf(stderr, "reportIncident returned \"%s\"\n", status.toString8().string());
|
|
|
|
return 1;
|
|
|
|
} else {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|