If the DevicePolicyManagerService updates the whitelist after a task
in the whitelist has started then the task won't have started locked.
When the updated whitelist arrives this change automatically locks the
topmost task if it is in the whitelist.
Also more locktask debugging.
Fixes bug 21031298.
Change-Id: I2494af6f2819ca91bc01abc5decb3d1adc088226
This reverts commit 08a04c15245c970856022d0779aa27d4d63cdee3.
This also reverts commit 5bcbf857d129f4513e562801a4e88077b2655ade.
Change-Id: Ia0b0a5339d523581c877822a3a1feec97ae4b73d
Because DeviceAdminReceiver is protected by BIND_DEVICE_ADMIN permission,
in order to send broadcast to it, we need to clear the caller's identity
and call sendBroadcastAsUser() as system.
Bug: 20213644
Change-Id: Icc7b239b9005e286012ade6580ec92a0a57198e0
Passing null to XmlPullParser.setInput forces it to do additional
work, which can be easily avoided if we know the charset beforehand.
bug: b/20849543
Change-Id: Iaff97be9df2d0f99d7af8f19f65934439c9658e2
Uri provides a stronger guarantee of well-formedness and lets apps do
nice extra things like specifying scheme etc. without twisting any
expectations.
Bug: 20820034
Change-Id: Ia6bbedb74765444920b667d643fb7e1eb6a7292b
And you may ask yourself: what is that beautiful icon?
And you may ask yourself: where does that API go to?
And you may ask yourself: is it a resource? is it a Bitmap?
And you may say to yourself: my god, what have I done
Bug: 18568715
Change-Id: I4377b311c538bd1cf36b3fba22326bae81af40c9
Added an API to pass an open file descriptor of DVB devices and
addressed the security issue of setting the permissions on DVB devices
to 0666.
Bug: 20436120
Change-Id: I4649e76084f3356ec22b7e776fb87c6a8fdc00d6
If another activity is starting while we are still animating
the starting window of the previous activity to start, we
transfer the starting window of the old activity to the one that
is currently starting so we don't have to create another starting
window and also to reduce jank from the starting window animation
appearing to restart.
However, there were several conditions that led to the starting
window animation stopping when the transfers app tokens
1. Starting window animator not been removed from the previous
app token animator causing it to finish/remove the starting window
prematurily.
2. Starting window animator not been properly added to the new
app token animator causing the animation not be be picked up.
3. WMS.mSkipAppTransitionAnimation been set to false regardless of if
an app transition was actually prepared in WMS.prepareAppTransition()
4. WMS.mSkipAppTransitionAnimation not been set to true in all cases
where the starting window transfers tokens even though we don't want the
new app to do any transition animation is the starting window is
animating.
5. New app not setting its animation to dummy animation when the next
transition should be skipped due to starting window still animating.
6. Starting window animation been cleared for the new app in
WMS.handleAppTransitionReadyLocked() even for cases where we transferred
the animation from the previous app.
Also, cleaned up some code.
Bug: 20953232
Change-Id: I714d6bdfcdaeeaac29f9d464bab9f3e9c192e937
- tune Intent resolution candidates filtering: add also the undefinedList
into the results at first so that when you install an App which is not
verified (after installing a verified App) you will still have the
Disambiguation Dialog prompted to the User.
See bug #19628271
Change-Id: I611fff4c1c7f60db22312d7948c8d5120719fbd0
It turns out switching to the new kernel alarm
reporting causes lots and lots of spurious flags
that the clock has changed. The alarm manager
would blindly trust these, thinking the world has
changed on it and recomputing everything and reporting
this to everyone else. This was expensive.
We now verify that the time has changed sufficiently
that it is worth caring about. This is basically the
same algorithm that battery stats was using to avoid
recording small clock changes, so we are really just
pushing this down into the alarm manager and can now
remove that from battery stats.
Also since we are getting these so much, make use of
the other information in about the wakeup that tells us
if an alarm went off to avoid doing anything if it didn't.
Change-Id: I6f4f4226db6eb2b38ca73860786e7cf7c9136cc3
- tune Intent resolution candidates filtering: remove the undefinedList
from the results and then add it again it there is no more candidates.
See bug #19628271
Change-Id: I9ab077f6a431367be8bab30c134d34e1e7ac51ed
For internal and unknowable wired devices, return the product name (i.e. "Nexus 7").
For connected devices with manufacturer-supplied product names, return those.
Change getName() to getProductName().
Bug: 20880296
Change-Id: I67ef3d4c73b3acab368b0879faa26fa9127c21bb
The access mock location is no longer a runtime permission. It is a
signature protected one that apps cannot get but the fact they request
it means they want to inject location into the system. Now the user
gets to choose the current mock location app in developer options from
the apps that request the mock location permission. The access to mock
location is no longer guarded by the permisson but from a new app op
which is off by default and the settiings UI sets it to enabled only
for the currently selected mock location app.
bug:21078873
Change-Id: I19e3f9dc7c7de82eab46b30fec1abfbca54a0e59
* Introduce a new "charger only" mode. In this mode, MTP is disabled,
and no file transfers can occur.
* Make charger only mode the default.
* Modify "persist.sys.usb.config" so it now only holds the adb status.
* Make the USB settings non-persistent. Unplugging the USB connection will
reset the device back to "charger only" mode.
* Fixup wording per UI guidelines.
TODO: Re-implement MDM restrictions for USB / MTP access controls.
Bug: 18905620
Change-Id: I99a50d9132a81e98187f431166fd9fef4d437e4f
- The mechanism to stop windows drawing while window animator was
animating was somehow flaky. It relied on the fact that the client
would call relayout() whenever the animating state changed. This is
mostly the case, but not for lockscreen animations. Instead, we now
use a push model, where window manager tells the app that the state
has changed.
- In addition, it only stopped drawing if that window was animating,
but then only resumed drawing after all windows have finished
animating. Now, we do this per window, so we only stop drawing for
windows that are currently animating.
- We resume the top activity now at the very beginning of the
unlocking sequence. This gives the app a chance to draw a frame
before the user sees anything. If it's to slow, then we just use the
outdated framebuffer.
Bug: 19964562
Change-Id: Ifef8abd189a3146d854b81b9b948861e4d38c155
"dumpsys usagestats history" will show the
active state of each app for the last 100 hours,
if the device hasn't rebooted.
Bug: 20066058
Change-Id: I703e5bc121298e4363c202da56fffb0b8534bcaf
- Don't subscribe/unsubscribe to new rules until the config has
been set, avoids race conditions.
- Process all condition updates on the same thread.
- Add the schedule provider's next alarm state to dumpsys.
Bug: 21111868
Change-Id: I389f4a4905a56d6c976f01408f48f87230109aba
