This is a new public API for developers to opt-in to strict rules
about what they're allowed to do on certain threads. (this is the
public face of the @hide dalvik.system.BlockGuard, added recently...)
In practice this will be used for developers to opt-in to declaring
that they don't want to be allowed to do various operations (such as
disk I/O or network operations) on their main UI threads. (these
operations are often accidental, or even when they are fast come with
a good chance of being slow or very slow in some cases....)
Implementation wise, this is just a thread-local integer that has a
bitmask of the things that aren't allowed, and more bits for saying
what the violation penalty is. The penalties, of which multiple can
be chosen, include:
* logging
* dropbox uploading for analysis/reporting
* annoying dialog
* full-on crashing
These are all only very roughly implemented at this point, but all
parts now minimally work end-to-end now, so this is a good checkpoint
commit before this gets too large.
Future CLs will polish all the above 4 penalties, including
checksumming of stacktraces and minimizing penalties for duplicate
violations.
Change-Id: Icbe61a2e950119519e7364030b10c3c28d243abe
Merge commit 'a2c6d5bf308181c019ade0aac6d25fe33dc3d76c' into kraken
* commit 'a2c6d5bf308181c019ade0aac6d25fe33dc3d76c':
do not merge: cherry-picked 929b4855b8208d36272769e8eeaa6cd2823b94c0 from master branch
* changes:
update EGL headers to the latest
update GL ES stub libraries with the new GL ES headers
fix OpenGL ES extension headers from khronos
update the OpenGL ES headers to the latest
* changes:
Add a test item the turns on a bunch of extra icons.
Move the status bar icon list, hopefully for the last time.
Call into the notification manager when the panel is revealed.
Move status_bar_latest_event and LatestItemView into SystemUI.apk.
Start the status bar service based on a configuration option, instead of trampolining through a braodcast receiver.
Require the STATUS_BAR_SERVICE permission for something to be the status bar.
Handle errors inflating notifications (and their icons).
* changes:
dead code removal
Cap the number of notifications that a given package can post.
Move the usb mass storage notification & activity into SystemUI.apk.
Add some disabled logging and another test case for reapplying the notification views.
Then, now that StatusBarManagerService is the only thing in that package,
move it up to the regular services package. (I've been waiting for 4 years
to delete that package!)
Change-Id: If5faf44641319fd19e486d1f4e5bc1c6dfcff3ad
When dealing with any kind of limited operating system resource,
we should ensure that we properly close everything that we
open, rather than relying on the system garbage collector.
Change-Id: Ic71f710eb85ac71a91b7a1215647c75010d37643
The problem is that we are referring an temp object returned from a function call.
When the function call returned, the temp object is gone; and thus the reference
may be invalidated.
-- rebased
bug - 2734946
Change-Id: I1993c4462df95610ca478f816adc30058af5850e
On an inflation error, the StatusBarService cleans up, removes / doesn't add
the views, and calls into the StatusBarManagerService, which tells the
NotificationManagerService to remove the notification.
That then calls all the way back into the StatusBarService, but I think being
extra careful is okay. Throughout the status bar, it's all keyed off of the
IBinder key, so if the app comes in with a good notification while we're
cleaning up, we won't lose the new notification or anything like that.
Change-Id: Iea78a637495a8b67810c214b951d5ddb93becacb
Right now the number is 50, just to prevent apps that have gone completely bonkers. I think the limit should be lower.
Change-Id: Ib2c4abf669c8b0250e5421b6d5aeb81aeb2f82ce
Surfaces can now be parcelized and sent to remote
processes. When a surface crosses a process
boundary, it looses its connection with the
current process and gets attached to the new one.
Change-Id: I39c7b055bcd3ea1162ef2718d3d4b866bf7c81c0
Merge commit '75b6a6b972e6b18143fd629d3d9c824c442c5f4c' into kraken
* commit '75b6a6b972e6b18143fd629d3d9c824c442c5f4c':
Fix 2737842: Disable KeguardManager API if device policy is enabled
This change adds notification to find out when the device policy
has changed. When an admin adds or changes a policy, we get notified
and reset the state of keyguard to be enabled.
It also moves disabling keyguard into the TokenWatcher.acquired()
method to avoid disabling keyguard when a policy doesn't permit it.
This avoids reference counting issues in TokenWatcher and hence relieves
the ordering issue.
There is one remaining caveat. An application that uses KeyguardManager
to disable keyguard will need to disable keyguard again after any
policy change.
Tested:
Install and run app that disables keyguard with no admin. Result: keyguard is enabled/disabled as expected.
Enable admin and set quality = "something" after installing & running app. Result: keyguard is enabled.
Change admin password quality to "unspecified" and re-run app (per caveat). Result: keyguard is disabled.
Change admin password quality to "something" again. Result: keyguard is enabled.
Disable admin : Result: keyguard is enabled until app runs again (per caveat).
Added minor cosmetic changes after review.
Change-Id: I302f2b01446bf031f746b0f3e8b5fd7a6cc0e648
Merge commit '71d73a0dfc110d0bdfc1b7ba385db3e2cfe007e5' into kraken
* commit '71d73a0dfc110d0bdfc1b7ba385db3e2cfe007e5':
Add a method to hide/show a SurfaceView's surface.
