frameworks_base

Files

lifr d130002e88 Extend NetworkDnsEventReported and add new DnsCallReported to log per-query information

NetworkDnsEventReported -The message represents the entire lookup operation,
which may result one or more queries to the recursive DNS resolvers.

DnsCallReported - Those DNS queries are individually logged in DnsCallReported
to enable computing error rates and network latency and timeouts broken up by
query type, transport, network interface, etc

Test: make statsd_testdrive
     ./out/host/linux-x86/bin/statsd_testdrive 116 => pass
Bug: 129253665

Change-Id: Ib75affea5d849437a293affbe294732153511d97
Merged-In: Ib75affea5d849437a293affbe294732153511d97

2019-05-03 16:13:12 +08:00

android

Extend NetworkDnsEventReported and add new DnsCallReported to log per-query information

2019-05-03 16:13:12 +08:00

Android.bp

Atom: Add more Bluetooth atoms

2019-01-28 17:30:05 -08:00

OWNERS

Merge "Add zhfan as owner of settings_enums.proto."

2018-11-07 19:46:22 +00:00

README.md

Refactoring GlobalSettingsProto to avoid method limit.

2018-03-23 18:03:43 -07:00

README.md

Conventions for the protos in this directory:

As in the rest of Android, use 4 spaces to indent instead of 2.
For protos based on Java files, use the same package as the Java file. For example, com.android.server.thing instead of com.android.server.thing.proto.
If the proto describes the top level output of dumpsys, it should contain Dump. This makes it easy to understand that the proto is the dumpsys output of a certain service, not the data structure of that service, e.g. WindowManagerServiceDumpProto vs WindowManagerServiceProto.
- Inner messages whose containing messages have the Proto suffix do not need to have a Proto suffix. E.g:

message FooProto {
    message Bar {
        ...
    }
}

vs

message FooProto {
    message BarProto {
        ...
    }
}

If the proto represents the structure of an object, it should have Proto as its suffix. Please also include the full package path of the original object as a comment to the proto message.
Include units in the field names. For example, screen_time_ms vs screen_time, or file_size_bytes or file_size_mebibytes vs file_size.
Leave field numbers 50,000 - 100,000 reserved for OEMs.