* Changed to inplace encryption.
* Changed decryption to return the proper error code. It will now return success or the number of failed attempts.
* Be lazy and post a message 2 seconds later to call restart. I don't feel like messing with binder interfaces for a proper callback.
Change-Id: Iae2de7057aa66f248fd2df3f29777ad3368442f0
This eases VpnSettings on dealing with multiple-activity-instance problem
(i.e., SettingsActivity and VpnSettingsActivity).
+ Most of the code is moved from the VpnServices package to vpn/java/.
+ VpnManager and VpnServiceBinder are revised to provide synchronous API.
+ Add a new method isIdle() to IVpnService.aidl.
Related bug: 3293236 (need to deal with multiple-activity-instance problem)
Change-Id: I03afa3b3af85d7b4ef800683cd075c356a9266c4
Having it non-touchable was making it possible to e.g.
touch buttons and launch new activities out from under
an in-flight drag operation.
Bug 3370698
Change-Id: I46fe70a8fe8fbaa5cca48f6bb478ed7ded1f1cc3
In particular, if a new window was created out from under the drag,
the drag-move event dispatch logic would wind up blithly assuming
that it would find a valid touch-dispatchable window under the
finger. When this was untrue, it would NPE, but the NPE was caught
and discarded safely by higher-level guard code.
With this change, we now avoid the NPE entirely and report the
spurious condition as part of the debugging log stream.
(Also add the local-state object to DragEvent.toString()'s output.)
Change-Id: Idfa5f45d049e48415ee59c8b0ffb5b0ed4098ce3
1. ViewGroups being removed from the layout during a drag would wind up
crashing the app with an NPE at drag-ended time, due to blind dereference
of now-cleared object pointers.
2. Passing a 'null' ClipData to startDrag() would crash the system
process with an NPE. Should this even be valid? I'm inclined to say
yes, though it means that apps will need to guard against it.
Fixes bug 3369542
Change-Id: I168fc1284d6fd4403999946609725414cf254df0
- Moving the service binding to AppWidgetService to prevent arbitrary apps from binding to widget services
- Requiring RemoteViewsServices to require android.permission.BIND_REMOTEVIEWS permission
Change-Id: Id135bafba998299eb278067712b8a5d8487cfd04
We no longer enforce permissions for applications that are accessing
their own components. This allows an application to require a permission
on one of its components that it does not itself have. This is useful
for example with the new advanced widgets, which require a system-only
permission on the implementing service to ensure the app's data stays
private but it is nice to allow the application to still touch its own
widget service.
Change-Id: I5d61930a083816919545870039ad191314ed48c6
A crash of the system server leaves us out of sync with the kernel network setup.
Try to recover.
bug:3241213
Change-Id: I70c0daa0d54ecee6e203bcba2460e8d069305a89
Adds a new virtualKeyQuietTimeMillis configuration resource that sets
the duration for which virtual keys will be dropped after recent touches
on screen. The default value is 0; it is intended to be overridden
per device using a resource overlay.
This change is designed to help in two cases:
1. Swipes from touchscreen into virtual key area.
2. Accidental taps in virtual key area while using on-screen keyboard.
Bug: 3089163
Change-Id: Ib912d4f8a4df9966a39cd537d3ec7c24afab7225
OBB files on USB storage or SD card should be removed when an
application is removed.
Bug: 3356804
Change-Id: Ifbbf043368b125fcd47fd74e5cd2e5167a8deb00
