UNKNOWN

INVALID_ARGS_ERROR

SERVER_ERROR

PERSISTENCE_ERROR

QUOTA_REACHED_ERROR

UNKNOWN

REPORT_UPLOADED

REPORT_ON_DISK

REPORT_IN_MEMORY

REPORT_NOT_FILED_USER_OPTED_OUT

PNG

UNKNOWN

The client will get this value if the server is sending a new enum value that the client was not compiled with.

COLD

The device booted from a cold state.

This is most likely the result of an extended period of time without power or a device booting with Fuchsia for the first time.

BRIEF_POWER_LOSS

The device rebooted due to a brief loss of power.

On some hardware this could be the result of a user disconnecting, then reconnecting their device's power supply in rapid succession.

BROWNOUT

The device rebooted because its voltage dipped below an allowable level without going to 0.

KERNEL_PANIC

SYSTEM_OUT_OF_MEMORY

HARDWARE_WATCHDOG_TIMEOUT

SOFTWARE_WATCHDOG_TIMEOUT

ROOT_JOB_TERMINATION

The device rebooted because the userspace root job was terminated, most likely because one of its critical processes crashed.

USER_REQUEST

The device rebooted because a user of the device initiated the reboot. A user can be a human or a program that interacts with the device on behalf of a human, such as SL4F or RCS.

SYSTEM_UPDATE

The device rebooted because of an OTA.

RETRY_SYSTEM_UPDATE

The device rebooted because applying the OTA failed and we want to retry.

HIGH_TEMPERATURE

The device rebooted because it was determined to be too hot.

SESSION_FAILURE

The device rebooted because of an issue with a session or because the session manager was unable to recover from an error.

SYSMGR_FAILURE

The device rebooted because the system manager (sysmgr) was unable to recover from an error.

FACTORY_DATA_RESET

The device rebooted following a data reset to factory defaults. See fuchsia.recovery.FactoryReset.

CRITICAL_COMPONENT_FAILURE

The device rebooted because a critical component managed by sysmgr has failed.

ZBI_SWAP

The device rebooted to apply the swap of Zircon boot images.

1

A vector of key-value string pairs. Keys are guaranteed to be unique.

Deprecation

Feedback is getting close to the limit defined by MAX_NUM_ANNOTATIONS_PROVIDED. Clients should migrate to |annotations2|, which will include all annotations included in |annotations| but has a higher limit for future growth.

2

A vector of key-value string pairs. Keys are guaranteed to be unique.

1

The top-level namespace associated with the data:

• Is intended to group related data together and reduce data key collisions across namespaces.
• May be shared by multiple clients, e.g., there could be multiple clients within the same component or across components that want to expose related data and they would all use the same namespace.
• Will be prefixed to every data key passed within that namespace in all feedback reports, e.g., the annotation "version" would appear as "foo.version" in all feedback reports if the namespace is "foo".
• Must match [a-z-]+, i.e. only lowercase letters and hyphens or this will result in a ZX_ERR_INVALID_ARGS epitaph.
• Must not match a reserved namespace used internally for platform data, e.g., "build", or this will result in a ZX_ERR_INVALID_ARGS epitaph. The list of reserved namespaces is internal and subject to change for now.

2

A vector of key-value string pairs, e.g., <"version", "1.2.3.45">.

Keys:

• Should be unique as only the latest value for a given key in the vector will be considered.
• Must match [a-z-.]+, i.e. only lowercase letters, hyphens and periods. Use periods for sub-namespacing, e.g., "build.label" and "build.type", so that related annotations are grouped together (here related to "build") when sorted lexicographically.

1

The name of the program that crashed, e.g., the process or component's name.

2

The specific report that depends on the type of crashes.

This field should be set if additional information about the crashing program needs to be sent, e.g., a minidump.

3

A vector of key-value string pairs representing arbitrary data that should be attached to a crash report.

Keys should be unique as only the latest value for a given key in the vector will be considered.

4

A vector of key-value string-to-VMO pairs representing arbitrary data that should be attached to a crash report.

Keys should be unique as only the latest value for a given key in the vector will be considered.

5

A text ID that the crash server can use to group multiple crash reports related to the same event.

Unlike the crash signature, crash reports sharing the same ID correspond to different crashes, but can be considered as belonging to the same event, e.g., a crash in a low-level server causing a crash in a high-level UI widget.

6

How long the program was running before it crashed.

7

A text signature that the crash server can use to track the same crash over time, e.g., "kernel-panic" or "oom". This signature will take precedence over any automated signature derived from the rest of the data.

Unlike the event ID, crash reports sharing the same signature correspond to the same crash, but happening over multiple events, e.g., a null pointer exception in a server whenever asked the same request.

Must match [a-z][a-z-]* i.e. only lowercase letters and hyphens or this will result in a ZX_ERR_INVALID_ARGS epitaph.

8

Indicates whether the crash report is for the atypical stop of a running process, component, or the system itself.

Examples of events that result in fatal crash reports are:

• an ELF process crashing
• the system rebooting because it ran out of memory.
• the system rebooting because a critical component crashed.
• the system rebooting because the device was too hot.

Examples of events that result in non-fatal crash reports are:

• an uncaught exception in a Dart program with many execution contexts. The runtime may chose to terminate that specific execution context and file a crash report for it instead of the whole program.
• a component detecting a fatal event (like an OOM) may occur soon, but isn't guaranteed to occur.

This field is primarily used for grouping crashes by fatal, not fatal, and unknown, each corresponding to the field being set to true, set to false, or not set respectively.

1

The product name on the crash server.

• The first character has to be alphanumeric. The remaining characters must be printable, but cannot be a space, which leaves values 33 to 127 in the ASCII table. Any other characters will result in a ZX_ERR_INVALID_ARGS epitaph.
• Missing this required field will result in a ZX_ERR_INVALID_ARGS epitaph.

2

Optional product version of the component.

• The first character has to be alphanumeric. The remaining characters must be printable, but cannot be a space, which leaves values 33 to 127 in the ASCII table. Any other characters will result in a ZX_ERR_INVALID_ARGS epitaph.

If no version is specified then none is reported to the crash server.

3

Optional product release channel for the component, e.g., "canary", "beta", "stable".

If no channel is specified then none is reported to the crash server.

1

The success type.

2

A non-empty value if |result| is FilingSuccess::REPORT_UPLOADED.

1

Annotations are collected in parallel from various places in the platform, each with a timeout.

collection_timeout_per_annotation allows clients to control how much time is given to each annotation collection. It enables clients to get a partial set of annotations under a certain time.

1

A snapshot aggregates various data from the platform (device uptime, logs, Inspect data, etc.) that are collected in parallel. Internally, each data collection is done within a timeout.

collection_timeout_per_data allows clients to control how much time is given to each data collection. It enables clients to get a partial yet valid snapshot under a certain time.

Note that this does not control how much total time the snapshot generation may take, which is by construction higher than collection_timeout_per_data, as clients can control the total time by using a timeout on the call to GetSnapshot() on their side.

2

If set, the snapshot archive will be sent as a |fuchsia.io.File| over this channel instead of being set in the |archive| field in the |Snapshot| response. This is typically useful if the client is on the host and does not support VMOs.

1

Whether the last reboot was graceful, i.e. the device didn't reboot in response to an error and rebooted in a controlled manner.

This field allows clients to know whether the last reboot was graceful without having to parse the optional |reason| field. This is useful when |reason| is not set, i.e. because the system doesn't know more than the fact that the reboot was graceful, or when the API evolves to support new RebootReason values and the clients hasn't been updated yet.

This field is always has a value if |reason| is provided. However, |reason| might not always have a value this field is provided.

2

Why a device last rebooted.

3

The uptime of the device before it rebooted.

1

The core dump in the Minidump format.

2

The name of the crashed process.

3

The kernel object id of the crashed process.

4

The name of the crashed thread.

5

The kernel object id of the crashed thread.

1

The exception type, e.g., "FileSystemException".

2

The exception message, e.g., "cannot open file".

3

The text representation of the exception stack trace.

1

A <filename, ZIP archive> pair.

The ZIP archive contains several files corresponding to the various data it collected from the platform. There is typically one file for all the annotations (device uptime, build version, etc.) and one file per attachment (logs, Inspect data, etc.).

Not set if |response_channel| was set in the request.

2

A vector of key-value string pairs. Keys are guaranteed to be unique.

While the annotations are included in the ZIP archive itself, some clients also want them separately to index or augment them so we provide them separately as well.

Deprecation

Feedback is getting close to the limit defined by MAX_NUM_ANNOTATIONS_PROVIDED. Clients should migrate to |annotations2|, which will include all annotations included in |annotations| but has a higher limit for future growth.

3

A vector of key-value string pairs. Keys are guaranteed to be unique.

While the annotations are included in the ZIP archive itself, some clients also want them separately to index or augment them so we provide them separately as well.

1

2

2

Intended for a native exception.

3

Intended for a Dart exception.

Maximum length for an annotation's key.

Maximum length for an annotation's value.

Deprecation

Feedback is getting close to the limit defined by MAX_NUM_ANNOTATIONS_PROVIDED. Clients should migrate to using MAX_NUM_ANNOTATIONS2_PROVIDED with |annotations2|, which will include all annotations included in |annotations| but has a higher limit for future growth.