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
[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
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
Follows the Google's permission check policy.
Add a getLegacyVpnInfoPrivileged method which skips the permission check
and change getLegacyVpnInfo to check the permission and then call getLegacyVpnInfoPrivileged.
It is already checked in this commit : https://android-review.googlesource.com/#/c/141771/
Signed-off-by: SangJin Cha <sj.cha@lge.com>
Change-Id: I83cfaedbd85745574f3ddf118b11b6e0415483c6
Having it as a raw byte[] caused issues in keystore because keymaster
handles a null blob differently than a blob with null contents. Make
this explicit in the API.
Change-Id: Ifcf550f438608b8f09fc589d00d06fffa6ee463b
Some authorization code needs to know the actual underlying operation
handle, not simply a reference to it, so return it in case it is needed.
Note that the handle cannot be used by the application to reference an
operation.
Change-Id: I4c883dde17168b7f6c1643d81741a4c2686d3159
Per bug 19848206, it turns out that APPLICATION_RESTRICTIONS_CHANGED
is only sent to dynamically-declared listeners, *not* to listeners
declared in the manifest. Updated doc to note this. (The code snippet
already showed how to dynamically declare a listener.)
See first comment for doc stage location.
bug: 19848206
Change-Id: I19c7150a9f36de226d00ad6d8db0e9210d5d135d
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
