As you can see, the results of the Android-Usagestats-XML-Protobuf parser accurately accounted for the strange looking timestamps, so what exactly is going on behind the scenes?

If you look through the different files in each of the respective sub-directories for yearly, monthly, weekly, and daily activity, you likely noticed that some timestamps don’t seem to fit into any of our previously addressed timestamp conversions and some timestamps are negative.

Each file in the usagestats sub-directories has a name that is reflective of the file’s creation date in Unix Epoch (ms). Application usage that occurs after the file’s creation date will have a positive (but unrecognizable time last time active format). This is because the timestamps are offsets from the creation date of the file. To correctly calculate the last time active, you must add the time offset associated with a particular application to the time recorded in the filename. From there, you can apply the normal Unix Epoch (ms) timestamp conversion: (time/1000,'unixepoch','localtime').

Negative timestamps will occur because the application activity precedes the file’s creation date. In these cases, the full, accurate timestamp is recorded in the file, but it is logged as negative. In these cases, taking the absolute value of the timestamp before applying the Unix Epoch (ms) timestamp conversion results in the correct timestamp.

The script provides a database file as well as an html report file for distribution.

To run the script, copy out the entire usagestats folder (or just your files of choice) to a folder on your computer. Place the usagestats_conv.py file in the same directory as your usagestats folder (example below).

Run the command (example below).

Html output