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
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
There was a visibility problem when multiple already running
activity got resized at the same time.
Only the last activity launched that got focus was shown and all others
were not.
The problem arose when a new ActivityStack got created and the
(existing) window got attached which led to the divergence of the
visibility states in different objects. The WindowState thinks
that it is visible, but the AppWindowToken thinks that it is not.
Subsequent calls to WindowState::ShowLw ignore calls to show the window
and the application logic enters the GONE state until it recieves focus.
Bug: 20692085
Change-Id: Ifc0e3686398ccd1d1ff32e1a266163b8db5b7f26
Triggers are device idle mode changing as well as
internal delayed message handlers.
Bug: 20066058
Change-Id: I0627cfbcc16cfc2b8ac7d298fd2c681a5a6571dd
Surface basic StorageManager commands through shell tool, like
simple listing of disks and volumes, and commands like mounting and
partitioning.
The output is designed to be parsed by host-side testing tools,
instead of relying on fragile dumpsys parsing.
Bug: 19993667
Change-Id: I993e92ecf57996678965945f0ae648b392a77ea2
As per discussion with UX team, we start showing IME switcher UI
not only when there are multiple IMEs are enabled but also when
a hardware keyboard is connected.
This CL also simplifies needsToShowImeSwitchOngoingNotification()
by renaming it with shouldShowImeSwitcherLocked() and unifying
related condition checking into that method.
Bug: 19496012
Change-Id: Id44724a2a46190382c283a52ece8edffb740807d
Rename MidiDeviceInfo.getPortList() to getPorts()
Rename MidiManager.getDeviceList() to getDevices()
Rename MidiReceiver.onReceive() to onSend()
Replace MidiManager.DeviceOpenCallback and BluetoothOpenCallback
with new interface MidiManager.OnDeviceOpenedListener
Add MidiSender.onConnect() and onDisconnect()
Add MidiReceiver.onFlush()
Ensure that MidiReceiver max message size is immutable
Bug: 21044677
Change-Id: I7711734a45e831e9744849a6f569e906feff9f80
We recently changed the install flow to fully dexopt before renaming
the staging directory. This exposed the ability for the session owner
to abandon and destroy the stage contents while dexopt was still
happening.
Due to SELinux rules, the abandon would fail to clean up the stage
directory, and PackageManager would "successfully" rename and install
that stage, which now only contained the oat/ directory.
To avoid this case, we now ignore abandon requests once we've passed
the "point of no return" and relinquished our stage over to
PackageManagerService.
Bug: 20175072
Change-Id: I4ad5b1eba0e38f1315b8330bd95be6e3bc6c635a
It is not reliable to try to get it from the process since it might
not be running yet.
Bug: 20016740
Change-Id: If3e748a97015c6623741d9374ab4ed1ed5f4b11f
