libstatslog is a blocker for some fuzzing. Our continuous fuzzing
infrastructure requires a statically-linked binary, and things depend on
libstatslog down the chain. We should allow libstatslog to be linked
statically.
Bug: N/A
Test: m libstatslog
Change-Id: Ic742a90daf6cbb5d197784416626256bfb6182b7
We used a whitelist to determine which atoms should have their
timestamps truncated to the nearest 5 minutes. This changes the logic
to a blacklist so that we can get fine grained timestamps from vendor and
mainline atoms. Also reserves a range for atoms that need to be
truncated in the future.
Bug: 134574701
Test: inspected generated statslog.cpp file to make sure it had the
correct blacklist
Test: testdrive on ScreenStateChanged to ensure timestamps are preserved
when they should be
Test: testdrive on CallStateChanged to ensure timestamps are truncated
when they should be.
Change-Id: Id3468542c830cdf41395a94c77f7df0b46cd11b7
We use "%zu" for a size_t argumet.
Test: TreeHugger
Bug: 126134616
Change-Id: I02916829dfb71a63f78eda0d45129b4dc0732a82
Merged-In: I02916829dfb71a63f78eda0d45129b4dc0732a82
(cherry picked from commit f87e93835a9cbebec2a46124f0f0b7e967de0d52)
Adds support for generating app code to allow java mainline modules to
call the StatsLog.writeRaw public API. Supports primitives, enums,
attribution chains, MODE_BYTES. Does not support key value pairs,
worksource methods (because worksource uses hidden apis in the
worksource object).
Test: manually tested atom logging from DocumentsUI
Test: existing autogenerated code is not modified
Test: cts will follow
Bug: 126134616
Change-Id: Ia321cf2d9952e3875ed0c7a28db1f4113711513f
Sets up a public api for logging atoms to statsd. The API excepts a
buffer which is already encoded in the proper format for the socket, as
well as the number of bytes of the buffer to write. It performs a JNI
call to perform the socket write. Autogenerated app code will be built
for each mainline module that needs to use this API to log.
Test: builds
Test: existing logs flow properly
Bug: 126134616
Change-Id: I8a9a91e638d730e3ff69cb9345692e49e0db3c96
Creates an annotation to specify if an atom needs to be logged from a
specific mainline module. Creates options in stats-log-api-gen so that
if the same module name is passed in, cpp/h files will be generated with
only those atoms that are specified. These files can be used to create a
static library per mainline module to log to statsd.
Test: builds
Test: atest stats-log-api-gen-test
Test: does not affect existing shared libstatslog
Test: manually created a static lib for netd and used it to log to
statsd. Used testdrive to validate the data was properly flowing.
Bug: 126134616
Change-Id: I78064f81fb4971eede8e97dacce5424e3eefd8bb
This is the C++ counterpart of the enum generation for Java done in
ag/I1ad19b86e28d0df0f8c15d4c995d101423cff4c2
Bug: 120990429
Test: builds successfully, logged one of atoms with an enum in C++ code and verified statsd logcat
Change-Id: I2c1452c0590aecdef0dbede6d88014c748e6509e
To avoid conflict between statslog.write() function signatures for
Atom1 {
Foo foo = 1 [logMode=bytes];
}
and
Atom2 {
string bar = 1;
int64 arg2 = 2;
}
Bug: 122571213
Test: manually tested with new atoms.
Change-Id: Ied0f0bd81cef8d0964f571e921f47022301157d9
This CL updates the code generator which creates the
hidden StatsLogInternal class to explicitly hide
the generated constants and write methods as well.
The intent of this class was for everything to be hidden,
but it turns out that public methods and fields in
hidden classes which are extended by a public class also
ends up in the SDK, even though they don't appear in the
signature file. StringBuilder#setLength(int) is an
example of this.
Bug: 118395019
Test: make sdk
Change-Id: I97e510e8155ee50ade653f6abeb5479c7ca9029d
* libutils must be used as a static library when compiled on host
* Host does not have Android system properties and hence we cannot
use <cutils/properties.h>. In fact, properties.cpp is not even
compiled on host for libcutils. Therefore, this CL adds a check
for __ANDROID__ macro before including <sys/propoerties.h> and
before calling properties_get_bool()
* On host, statsd logging will be disabled since host does not
use statsd for anything
Fixes: 121294178
Test: test drive statsd
Change-Id: I838ff02468c650c5f7d85e68fa5008b98f08ce8c
The proto binary data can contain '\0's and in the native layer,
the current liblog api would convert that into string and thus
the data is truncated.
This CL adds a "size_t bytes_field_len" after the bytes fields so that
we can correctly pass the data from JAVA to native.
Java StatsLog.write() APIs remain the same
Bug: 120635548
Test: test_drive with atom 103
Change-Id: I34f1c4ddd6a4ec5f3604b0c67a47a5399e3c6ddd
Merged-In: I34f1c4ddd6a4ec5f3604b0c67a47a5399e3c6ddd
(cherry picked from commit 1fe9f594984b47144b958f0ac423eeffc56b62ea)
Test: unit test added
Bug: 120635548
Change-Id: I825b1ce526944a20fe65705508ad180ece37492c
Merged-In: I825b1ce526944a20fe65705508ad180ece37492c
(cherry picked from commit 8e6f9983009eadf32d05ad65e38906d3985bc9ba)
There are an increasing number of requests to log data in complex format to statsd, while the data
is not expected to be parsed or aggregated by statsd and only to be uploaded as events.
Instead of making an exception for each of these cases in a hard coded way, this CL add a feature to
annotate these field in atoms.proto and the stats-log-api-gen tool will produce byte array
interfaces for them.
Note that log_msg does not have byte array type, and only has string type, when statsd receives the
log, these fields are in string type. Only when the atom is written to proto, we will check if this
field should be bytes field and write it to protobuf in message format.
Change-Id: If53dd95c5826710c76d7fe982bf951a435dfc738
Merged-In: If53dd95c5826710c76d7fe982bf951a435dfc738
Fix: 118386797
Bug: 120635548
Test: unit test & manual test
(cherry picked from commit bbdd67d19f4912fbec00220b22e44c68eff5ab3f)
The proto binary data can contain '\0's and in the native layer,
the current liblog api would convert that into string and thus
the data is truncated.
This CL adds a "size_t bytes_field_len" after the bytes fields so that
we can correctly pass the data from JAVA to native.
Java StatsLog.write() APIs remain the same
Test: test_drive with atom 103
Change-Id: I34f1c4ddd6a4ec5f3604b0c67a47a5399e3c6ddd
The error code will give us some clue on what caused the loss (e.g., EBUSY, or ENOENT)
Test: manual
Bug: 80538532
Change-Id: I446c6e2255bdae063dfb8803ad0b702ead87c645
There are an increasing number of requests to log data in complex format to statsd, while the data
is not expected to be parsed or aggregated by statsd and only to be uploaded as events.
Instead of making an exception for each of these cases in a hard coded way, this CL add a feature to
annotate these field in atoms.proto and the stats-log-api-gen tool will produce byte array
interfaces for them.
Note that log_msg does not have byte array type, and only has string type, when statsd receives the
log, these fields are in string type. Only when the atom is written to proto, we will check if this
field should be bytes field and write it to protobuf in message format.
Change-Id: If53dd95c5826710c76d7fe982bf951a435dfc738
Fix: 118386797
Test: unit test & manual test
There will be followup cls to add support of new types that can be
nested and repeated.
+ skip StatsLog.write signature generation for pulled atoms.
Bug: 113872139
Test: manual test
Change-Id: I69d0ee0b2fe8e286e48eac20ec2c8b280c477bf0
+ Only record eventual failure after the retries to get a accurate log loss count.
+ Record all types of failures which lead to log loss
+ Change the timestamp from elapsedRealtime to wallclock time for easier debugging server side
+ Also log the count too.
Bug: 80538532
Test: manually tested
Change-Id: I4fcccae3fa39c9e280a842e27c6432bb0a090b85
Modified cherry pick from master:
(cherry picked from commit d888df2ba99e117b50a5553e18426ad370294a20)
covering ag/4210168 and ag/4230692.
The tool that generates StatsLogInternal.java now includes the following
type of code, to accomodate WorkSources automatically.
public static void write(int code, WorkSource ws, int arg2) {
for (int i = 0; i < ws.size(); ++i) {
write_non_chained(code, ws.get(i), ws.getName(i), arg2);
}
ArrayList<WorkSource.WorkChain> workChains = ws.getWorkChains();
if (workChains != null) {
for (WorkSource.WorkChain wc : workChains) {
write(code, wc.getUids(), wc.getTags(), arg2);
}
}
}
This will reduce a lot of code repitition for the StatsLog.write calls
in BatteryStats. Consequently, doing so will make it easier to remove
these StatsLog.write calls out of BatteryStats.
Bug: 80308558
Bug: 80314737
Test: manual verification
Test: com.android.internal.os.BatteryStatsTests
Change-Id: Ied537a6195121f16ef49b6bccf58c8c31964909c
Merged-In: Ibd28297345f4ab926dec01a89de0f1bfff9f8871
This CL changes the relevant cpp files to c files. And added functionalities to reset the log
context for reuse.
Background:
+ lmkd doesn't use the generated statslog code because:
1. lmkd doesn't want to create a 4K log context for each log. lmkd is single threaded and can
reuse the same log context.
2. lmkd is written in c, and the existing statslog.h/.cpp are not compatible
Bug: 78603347
Test: manually tested with alloc-stress
Change-Id: Ife6f5c69248ecf5af730269e67f229ba4c72f37f
+ Reuse the log_event_list from liblog. StatsLog's binary format remains unchanged
+ Copied socket write code from liblog, including the retry logic.
+ Added build flags to control the StatsLog channel (logd, statsd, or both for debugging)
Bug: 78239479
Test: locally tested and saw logs being written to statsd
Change-Id: I7b1f0069ead00bbf3c29e4bd5b7f363a7ce26abe
[memory]
statsd binary size from 664k -> 600k
memory usage 1978k -> 1813k (with no configs)
+ Avoid initialize any static map in statslog.h to avoid many copies of the map in each include.
- Do it in cpp so that it is initialized only in places that use them
[Uid annotation]
+ Uid annotation is needed for extracting uid from dimension for UidCpuPuller.
+ After the change, stand-alone uids don't need to be in field 1 anymore.
+ Also added exclusive bit annotation in AppDied
+ Currently only allow one uid field in an Atom. This is to keep things simple until
we find an exception.
Test: statsd_test
Bug: 73958484
Bug: 72129300
Change-Id: I8a916d5c00d5930e24ae7e0825a57dea19c0e744
+ A state change atom can have one exclusive state field, and any
number of primary key fields.
When there is primary key in the atom, it means the state belongs to the primary key.
For example,
message UidProcessStateChanged {
optional int32 uid = 1 [(stateFieldOption).option = PRIMARY];
optional android.app.ProcessStateEnum state = 2 [(stateFieldOption).option = EXCLUSIVE];
}
When there is no primary key fields in the atom, the state is global.
For example,
message ScreenStateChanged {
optional android.view.DisplayStateEnum state = 1 [(stateFieldOption).option = EXCLUSIVE];
}
+ The annotation is consumed by stats_log_api_gen to generate a static map from the state
atoms to its primary fields, and exclusive fields
+ stats_log.proto is splitted into 2 proto files, because statsd needs proto lite, and c++
lite proto library cannot properly ignore the field options which requires full proto.
This CL doesn't change any logic in the statsd yet. A separate CL will use the field option
information to correctly track the state.
Test: added unit tests in stats_log_api_gen_test. and statsd_test pases.
Change-Id: I9e8a979fe81ba60efd4d854bb7087ce4b2b147ec
Usually the input parameters for attribution chain is list of int64/string.
The new c++interface takes one int64 and one string as input and write
as a single node into logd.
This will help avoid allocating temp objects in battery stats java code.
Test: all statsd unit test passed.
Change-Id: Ia0f7f26b71a570bd3628c42726a5afb0a500d073
