The attribute declares whether the app intends to use cleartext
network traffic (e.g., HTTP, WebSockets, XMPP, SMTP, IMAP -- without
TLS or STARTTLS). The default value is true. If set to false, the app
declares that it does not intend to use cleartext network traffic. In
this case the app requests the platform, tooling, and third-party
libraries to prevent it from using cleartext traffic. The danger of
cleartext network traffic is that its confidentiality, authenticity,
and integrity are not guaranteed.
This feature is designed to help apps which care about security of
data exchanged over the network. These apps can accidentally
regress/downgrade to using cleartext network communications. This
typically happens when the server the app communicates with all of a
sudden tells it to use cleartext communications (e.g, HTTP URL
instead of an HTTPS URL) or when one of the components of the app gets
updated and regresses to cleartext communications without the
developer noticing.
In general, the prevention measures are on best effort basis. It's
impossible to automatically prevent all instances of cleartext
traffic. For example, an app bent on bypassing restrictions could
perform low-level network I/O with unusual TCP packet fragmentation,
or could use a custom application-level protocol.
The expectation is that most apps use libraries for network
communications and these libraries over time will start to honor this
flag, thus increasing the protections offered by it.
Bug: 19215516
Change-Id: I8700d51ddbc5d528faa4b6a5fa5bc9551ad02d13
%p is not a valid conversion in format strings. It is also superfluous,
as it is already known that location is null.
Bug: 19797138
Change-Id: I5784e28b05b4ca9aac57e0fc9da4a7f01d9b3247
The comparator's equal implementation doesn't satisfy the constraints
of an equals method, namely being reflexive. Use the standard Object
implementation instead.
Bug: 19797138
Change-Id: I74f888e99533e1945aab7ab10fe8ee3ded6388f4
The constructor was public API, doh. Gotta do this differently.
This reverts commit 33c5b2a62f3e62382c41e24c6b527119978816a0.
Change-Id: Iadca87fe6a8866a8bd9d6f2a91578ec0d4c44691
According to the if below, ains == null is potentially valid. But
the foreach loop would throw a NullPointerException.
Change-Id: I4460fb1357eaa3abfe0ab9a21effb608f474ab51
Integer == is dangerous, as equal objects may not be identical
objects. In fact, MediaFormat.setInteger was creating a new object
every time.
Change MediaFormat.setInteger and setLong to use valueOf, which
may reuse returned objects.
Change-Id: Iedcc6003adbf05c0c870aa4b3ada7f181a5b870e
