Add presubmit test to verify v2 metrics are working when enabled

[cjreynol]

Bug: 453757034

[jmacnak]

I don't think it needs to block this PR but I find this one file per event type quite strange.

It also seems like this file generation as-is right now completely overwrites any existing file (

android-cuttlefish/base/cvd/cuttlefish/host/libs/metrics/metrics_writer.cc

Line 51 in 35f43d8

CF_EXPECT(WriteNewFile(event_filepath, text_proto_out));

)

I think it is feasible to have repeating events. Could the existing boot completed event trigger twice currently if someone did a adb reboot ?

I guess I would imagine us having something like a

message CuttlefishLogEvents {
   repeated CuttlefishLogEvent event = 1;
}

and then there would be a single "metrics.txtpb" file which can be written to in an appending fashion.

WDYT?

[cjreynol]

I use the <event type>*.txtpb to simplify the checks here because we are controlling the cvd invocations and know there will only be one event per type, but the full filepath for each event is generated with the format:

<event type>_<datetimestamp>_<random 10 digit suffix>.txtpb

to avoid the possibility of overwriting.

reference:

android-cuttlefish/base/cvd/cuttlefish/host/libs/metrics/metrics_writer.cc

Line 47 in 35f43d8

"{}/{}_{}_{}.txtpb", metrics_directory, EventTypeString(event_type),

Each event is also per group, capturing the details for each instance within the group (since we cannot start/stop individual instances).

Which all means that it is fine to have an invocation sequence like:

`cvd create`  # starts by default
`cvd stop`
`cvd start`
`cvd stop`

and the resulting <group_root_directory>/metrics/ directory could have event files roughly like:

'device_instantiation_2026-01-09 16:05:00.12345_1234561111.txtpb'
'device_boot_start_2026-01-09 16:05:10.12345_1234562222.txtpb'
'device_boot_complete_2026-01-09 16:06:15.12345_1234563333.txtpb'
'device_boot_stop_2026-01-09 16:12:00.12345_123456444.txtpb'
'device_boot_start_2026-01-09 16:23:00.12345_1234565555.txtpb'
'device_boot_complete_2026-01-09 16:24:15.12345_123456666.txtpb'
'device_boot_stop_2026-01-09 16:38:00.12345_123457777.txtpb'

The timestamps are the practical differentiator, though the random number suffix is there in the case where two event types somehow occurred on the same group at the same time. I believe cvd prevents that from being possible in practice, but just in case.

I do not think an adb reboot will trigger new events, since the V2 metrics are all cvd generated (to ideally work identically across any build/host tools). The V1 metrics might capture that, but I do not know either way.

---

All of that said, I am not opposed to a single, expanding file. The main drivers for going this direction were:

• cvd is doing the writing (and thus transmitting) at the time of each event rather than gathering up events and doing it all at once (to avoid missing events due to unexpected failures). Coming up with a unique filename and writing a separate file matched that one-event-at-a-time structure.
• I wanted to avoid consideration for concurrent writing to a single file if/when the amount of metrics events expands.