[Preconditions]
set password or patten lockscreen
[operating steps]
1.install the app (eg QQBrowser) and connected wifi
2.wait a while,the weather notification will shown on statusbar
3.turn off screen,the weather notification will shown on lockscreen too.
4.click the search bar in weather notification,it will disable lockscreen.
5.press HOME button or kill QQBrowser in Recent apps,you can operate the phone
Use a single vararg Object array for both kernel/invoke arguments
and global bindings. The assumption is that global bindings are in
the end after the kernel/invoke arguments.
This simplifies the api to add a kernel or invoke to a script group.
Change-Id: I7efb1035c5967e2cadd15e6fe27f20c80ba197a2
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
%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
