The initial purpose of the NetworkSecurityPolicy class is to provide a
way for network libraries to check whether cleartext network traffic
(e.g., HTTP, WebSockets, XMPP, IMAP, SMTP) should be blocked from this
process.
The policy is set declaratively by the app developer in the app's
manifest and can be queried from ApplicationInfo.flags. Unfortunately,
several network stacks (bundled and unbundled) do not have a reference
to ApplicationInfo or Context.
Alternatives:
* Keep this API hidden (and thus potentially move it from framework to
libcore), thus precluding unbundled HTTP stacks from using the API.
* Introduce a new java.lang.System property instead of this API.
However, such properties are a mess and not as powerful/extensible
as a public class.
Bug: 19215516
Change-Id: If22056a74d257bf1d805ebb4fc284240b3d338f1
This is one of the few remaining users of libzipfile, but doesn't get built.
Not worth porting to libziparchive.
Change-Id: Ica466b22e3a7ebaf123727c0d703af39cc89cf9c
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
Add methods for sending an auth token to keystore and to query the
authorization state of a given operation.
Change-Id: I223df5c56ae2a251ef31cfe60f06c046c12a5cd8
%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
Kernel will reuse process id, when wrap-around happens,
there may be just after a pid is freed, a new thread/process
uses the pid immediately.
For examples, there may be a process with pid 1234 killed
by lowmemorykiller or itself (app.killed=false).
Before the death recipient enters AMS, a new thread/process
is started with pid 1234, then when appDiedLocked executes,
this new pid 1234 will be killed again.
It is especially easy happens to zygote:
During zygote starting process, it will stop 5 daemons threads.
And restart the 5 threads after fork is called, so it has
larger pid range to hit the resue case.
https://code.google.com/p/android/issues/detail?id=160661
Solution:
If the dead event is from binder, it is not necessary
to call killProcessQuiet again, because it should really
be dead.
Keep no checking for killProcessGroup because zygote does
not have record under /acct/, and also the parameter uid
has restriction that will not kill another application
which reuses the pid.
Change-Id: Iec4a4884ae641c4d036f4d024ce463f7a351a17b
New ShadowTask with the ShadowDescription key that already
exists in the shadow LruCache will leak as it is not being
added.
Fix adds check for the existing key that is common in the hwui
code but missing for the TessellationCache::precacheShadow
function.
Change-Id: I37fd5ec82f8b8da5d1ec0f2ab9fd04c5f8534367
