This is a follow-up to
https://android-review.googlesource.com/#/c/131920/, addressing some
outstanding comments.
This CL also switches the source file to the correct indentation.
Bug: 19215516
Change-Id: Ia48455ab351081e11619afcccadb8fa90340391d
There is the case that adjustSurface() get called even if
the size of the surface of DimLayer is not changed actually.
Since changing the size of a surface is processed synchronously
in the SurfacFlinger, there is usually a few milliseconds delay
(up to 1 vsync interval) when we launch an application.
This patch avoids such cases.
Change-Id: Ib1f76d54f9f2364ac54b70120e4b781e8534e750
Signed-off-by: Dohyun Lee <dohyun.lee@lge.com>
If changing wallpaper when low on memory, retrieving the default
wallpaper may return null, which triggers error handling in
ImageWallpaper. This error handling tries to perform
WallpaperManager.clear(), but for that it needs SET_WALLPAPER
permission, which it does not have.
For users with apps that auto change wallpaper, this issue can
be frequent in low-memory conditions.
The solution is to add the permisson.
Change-Id: I81503c1667e3952c2dd15599969f7dcc51623e5b
The original logic would let the app hidden by keyguard be able to
decide the orientation. While going back from a show-when-locked app
to keyguard, there would be a short time that keyguard is unable to
decide the orientation, which causes WMS uses the wrong orientation
from the wrong app.
https://code.google.com/p/android/issues/detail?id=155640
Change-Id: Ibc17bfe4603f68b241dc7380459ec9de42a3e259
To obtain the gfxinfo for each process, the static method of RenderProxy is used, which is named outputLogBuffer().
In there,
1. RenderTask is created for getting DisplayList Commands in RenderNode.
2. staticPostAndWait() is called
3. RenderThread's instance is created by 'RenderThread::getInstance()' in staticPostAndWait()
In case of the service, they don't use HW Acceleration, so don't need RenderThread.
But, by the process of No.3, RenderThread is created for all process.
As we know, RenderThread never be destroyed while the process is alive.
This patch checks RenderThread instance before the creation of RenderTask.
And, there is no one, just return to prevent the unnecessay creation of it.
Change-Id: I4fe29d83c9ced3e8b67177c0874c5d8ee62e1870
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
