Where Does Android Gets Its Traffic Stats?

Quite simple.  Android get these stats from Linux sysfs and proc file systems.  They can be found at the following locations on a Android powered device:

Android Traffic Stats Table

Android TrafficStats	Linux File Location
getMobileTxPackets()	/sys/class/net/rmnet0/statistics/tx_packets
	/sys/class/net/ppp0/statistics/tx_packets
getMobileRxPackets()	/sys/class/net/rmnet0/statistics/rx_packets
	/sys/class/net/ppp0/statistics/rx_packets
getMobileTxBytes()	/sys/class/net/rmnet0/statistics/tx_bytes
	/sys/class/net/ppp0/statistics/tx_bytes
getMobileRxBytes()	/sys/class/net/rmnet0/statistics/rx_bytes
	/sys/class/net/ppp0/statistics/rx_bytes
getTotalTxPackets()	Add up tx_packets for all interfaces under /sys/class/net
getTotalRxPackets()	Add up rx_packets for all interfaces under /sys/class/net
getTotalTxBytes()	Add up tx_bytes for all interfaces under /sys/class/net
getTotalRxBytes()	Add up rx_bytes for all interfaces under /sys/class/net
getUidRxBytes()	/proc/uid_stat/[uid]/tcp_rcv
getUidTxBytes()	/proc/uid_stat/[uid]/tcp_snd

Inconsistent Life-cycle Events in Andorid Service API

Google Android engineers should read the API design guideline from one of their own.  The callback methods on the Service class violates the basic consistency principle in good API design.  Here is what the SDK doc says about the two callback methods:

"If someone calls Context.startService() then the system will retrieve the service (creating it and calling its onCreate() method if needed) and then call its onStartCommand(Intent, int, int) method with the arguments supplied by the client."

But wait:

"Clients can also use Context.bindService() to obtain a persistent connection to a service. This likewise creates the service if it is not already running (calling onCreate() while doing so), but does not call onStartCommand()."

So, the life-cycle events on Service creation do not occur in a consistent way!  No explanation was given. Sigh...