The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
To be able to have more intelligent code — code that can adapt
to Internet activity on the device — Android offers the
TrafficStats class. This class really is a gateway to a block of
native code that reports on traffic usage for the entire device and
per-application, for both received and transmitted data. This chapter
will examine how you can access
TrafficStats and interpret its data.
Understanding this chapter requires that you have read the core chapters and understand how Android apps are set up and operate.
TrafficStats class is not designed to be instantiated —
you will not be invoking a constructor by calling
TrafficStats() or something like that. Rather,
merely a collection of static methods, mapped to native code, that
provide access to point-in-time traffic values. No special
permissions are needed to use any of these methods. Most of the
methods were added in API Level 8 and therefore should be callable on
most Android devices in use today.
If you are interested in overall traffic, you will probably care most
TrafficStats. These methods return received and transmitted
traffic, respectively, measured in bytes.
You also have:
getTotalTxPackets(), if for your case measuring IP packets is a better measure than bytes
getMobileTxBytes(), which return the traffic going over mobile data (also included in the total)
getMobileTxPackets(), which are the packet counts for the mobile data connection
TrafficStats does not provide per-application traffic
statistics. Rather, it provides per-UID traffic statistics. In most
cases, the UID (user ID) of an application is unique, and therefore
per-UID statistics map to per-application statistics. However, it is
possible for multiple applications to share a single UID (e.g., via
android:sharedUserId manifest attribute) — in this case,
TrafficStats would appear to provide traffic data for all
applications sharing that UID.
There are per-UID equivalents of the first four methods listed in the
previous section, replacing “Total” with “Uid”. So, to find out
overall traffic for an application, you could use
getUidTxBytes(). However, these are the only two UID-specific
methods that were implemented in API Level 8. Equivalents of the
getUidRxPackets()) were added in API Level 12. API
Level 12 also added some TCP-specific methods (e.g.,
getUidTcpTxBytes()). Note, though, that the mobile-only method are
only available at the device level; there are no UID-specific
versions of those methods.
You will get one of two types of return value from these methods.
In theory, you will get the value the method calls for (e.g., number
of bytes, number of packets). The documentation does not state the
time period for that value, so while it is possible that it is really
“number of bytes since the device was booted”, we do not know that
for certain. Hence,
TrafficStats results should be used for
comparison purposes, either comparing the same value over time or
comparing multiple values at the same time. For example, to measure
bandwidth consumption, you will need to record the
values at one point in time, then again later — the difference
between them represents the consumed bandwidth during that period of
In practice, while the “total” methods seem reliable, the per-UID
methods may return
Three possible meanings are:
Hence, the per-UID values are a bit “hit or miss”, which you will need to take into account.
The preview of this section is being chased by zombies.
The preview of this section was lost in the sofa cushions.