Add NetworkStats parser

[0x4552494b]

This parser adds support for artifacts from the Android NetworkStats API located at /data/system/netstats/.

[0x4552494b]

Moved artifact icon into the artifacts_v2 header. The linter should pass now.

[stark4n6]

@0x4552494b do you know of any public images that have test data? I haven't been able to find any just yet

[0x4552494b]

Hi @stark4n6,

BinaryHicks Android 11 Image contains some data that can be parsed.

Unfortunately, I'm afraid the script can't comply with the new policy that all new artifacts must be LAVA ready. I can't think of any way to squeeze the data into a 2-dimensional view without omiting relevant info.

Here is a sample of the current output:

[abrignoni]

Only idea that came to mind is to split it into two artifacts. One for the network identity and another for the data buckets. The data buckets will have a field for the network identity so it can be correlated to the network identity entry in the previous artifact by the user. Thoughts?

…

On Tue, May 26, 2026 at 1:28 PM Erik ***@***.***> wrote: *0x4552494b* left a comment (abrignoni/ALEAPP#655) <#655 (comment)> Hi @stark4n6 <https://github.com/stark4n6>, BinaryHicks Android 11 Image <https://thebinaryhick.blog/2020/10/07/new-android-image-available-this-one-goes-to-11/> contains some data that can be parsed. Unfortunately, I'm afraid the script can't comply with the new policy that all new artifacts must be LAVA ready. I can't think of any way to squeeze the data into a 2-dimensional view without omiting relevant info. Here is a sample of the current output: screenshot1.png (view on web) <https://github.com/user-attachments/assets/6681755a-a0e9-4318-ac28-a2b0f74f7d7d> — Reply to this email directly, view it on GitHub <#655?email_source=notifications&email_token=AG3DPC3YQFLAEKJADONF55D44XH27A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJUGY4DQMRQGMZ2M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4546882033>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG3DPC2NTSSZQ7LR2L77CY344XH27AVCNFSM6AAAAACQ6BE4L2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKNBWHA4DEMBTGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[JamesHabben]

Agree with @abrignoni on the split. The identity artifact could even loop through the buckets to sum up things like total transfer value of each identity or count of transfers.

Edit: also it looks like you may be combining sessions for shared user id? If you split those into distinct records, this can allow sorting and filtering in lava, and the timestamps can get the timezone handling too.

[0x4552494b]

Thank you guys for the suggestions. I currently see two problems with the splitting approach.

1. Network identities don't have a unique identifier. So to reference an identity from the "data buckets view" we'd have to introduce a new index that doesn't exist in the original data.

   and more importantly

2. In theory the file structure supports entries with multiple NetworkIdentities (the Android sources refer to it as NetworkIdentitySet). An entry could basically look like this:

.
├── NetworkIdentity
├── NetworkIdentity
├── Bucket
│   ├── Netstats
│   ├── Netstats
│   └── Netstats
├── Bucket
│   ├── Netstats
│   └── Netstats
└── ...

I didn't observe this during testing but we can't rule out the possibility that there will ever be an entry with more than one NetworkIdentity. In that case we'd need a way to link Buckets to multiple NetworkIdentities as well as convey that these NetworkIdentities belong together.

[JamesHabben]

I think there is enough structure in the source data to support relational output.

The parser is already treating each parsed entry as a grouped structure containing:

• one or more NetworkIdentity records
• one or more bucket records

The source format may not expose a native unique ID for the identity set, but the grouping itself appears explicit from parse context.

For relational output, I think we could preserve that relationship by generating a synthetic grouping identifier during parsing. My preference would be to use the file offset of the entry structure rather than an arbitrary incrementing entry index.

For example:

• entry_offset
  or
• identity_set_offset

Then both the identity table and bucket table could carry that value as the relational key.

I prefer offset over entry index because:

• it is derived directly from the source structure
• it provides forensic provenance/debug traceability
• it avoids introducing a purely parser-generated ordinal
• the meaning of the value is transparent to downstream consumers

An incrementing entry ID would also technically work, but offset feels cleaner and more defensible from a forensic/data lineage perspective.

There is still opportunity for aggregation/summarization as well. The offset/set identifier would simply preserve the original grouping relationship while still allowing aggregation by UID, identity fields, durations, totals, etc.

[stark4n6]

@0x4552494b just fyi, tried on Josh's Android 11 image, got some errors for NoneTypes, so might have to add some extra file checks

[0x4552494b]

@stark4n6 Weird... I could have sworn this didn't happen when I originally wrote the script.

The problem is in L264, where I’m returning dummy data because otherwise the artifact icon wouldn’t be registered. Once the script is adapted to be LAVA-compatible and return actual data, the issue will resolve automatically.