The previous implementation failed to properly distinguish between
trigger times in the RTC vs the ELAPSED time bases. The pernicious
result of this was that sometimes it would decide to align RTC
alarms based on, say, 0 rather than on the real current time.
This would pull the recurrence into wall-clock alignment, with
serious side effects: in particular, periodic tasks that would hit
external network resources would, because *all* devices would be
pulled into wall-clock alignment, wind up inducing heavy QPS
spikes on the backends.
The new implementation works completely differently. The basic
goal is the same: try to align inexact alarms to "the same" time,
avoiding extra wakeups / radio spinups / etc. The way this is done
is to divide the timeline into 15-minute quanta, and drift the start
time of every inexact alarm onto one of these 15-minute quantum
boundaries. The skew between the RTC and ELAPSED time bases is
taken into effect; RTC alarms are no longer pulled into wall clock
alignment.
Fixes bug 3388961
Change-Id: I2a0460e1f5d0e4036f3402f332b642b557b2fc20
Fixes a race between the onDaemonConnected callback and setting the
mOutputStream in NativeDaemonConnector.
MountService connects to vold using the NativeDaemonConnector.
Throws a “NativeDaemonConnectorException: No output stream!”
when the onDaemonConnected callback in MountService calls the doListCommand.
Change-Id: Ib895bab37f7df680e4362df6366198c0a673c5e9
Since there is no support for hardware GLES acceleration under
emulation, we disable the screen rotation animation when we detect
that we are in the emulator.
Note that ideally, we should only disable it when we detect that
GLES is implemented in software. However, I don't think there is
an easy way to test for this inside of the WindowManagerService.
Change-Id: Ic17719f7d0b14640bacb3b33b7b1a196006982ee
This change improves upon the notification priority API
introduced in change I9e738cc4, allowing privileged clients
to set the priority of a notification when posting it
directly to INotificationManager. StatusBarTest is updated
to test this new feature.
The new LocationController in SystemUI uses this facility to
post a high-priority ongoing notification whenever GPS is in
use (replacing the functionality of the legacy GPS status
bar icon).
Also happens to fix http://b/3325472 (adding a log message
when notifications are dropped because of a missing icon).
Bug: 3412807
Change-Id: I523016ffa53bf979be98ddc4a2deb55a6270c68a
- The ImageWallpaper wasn't watching for the desired dimensions to
change, at which point it needs to resize its surface.
- The system process has been running with the small dalvik heap
limit, which is too tight with these huge wallpapers; this would
cause switching wallpapers to eventually stop working as it
couldn't get the memory it needed to load the new one.
- The compatibility mode background surface had a bunch of issues,
such as moving its windows to the right by the window size to
make them disappear. This of course doesn't play well with the
now super-sized wallpaper surface. This code is re-worked to
not require such shenanigans.
Change-Id: I64fde4059645d8507f1c4761ba6c17b89877a5c0
Two problems:
1. The wallpaper offsets were being applied at the wrong place in the xform.
2. The background black needs become a clip around the newly revealed UI.
Change-Id: I3b46aea2ace3c8c5a36fc5e37b4e2b67fff1b289
This can be used to prevent applications from connecting to
sensitive internal USB devices (like the modem)
Change-Id: I6587f58018e3f8d8f78405d4004cce64db23b628
Signed-off-by: Mike Lockwood <lockwood@android.com>
That return statement is effectively a reading of asynchronously modified
field. The reading and writing is elsewhere protected by locking on thread
instance, except this one occurence. Moving 'return' statement into
synchronized block ensures that it reads updated value.
Don't be afraid of deadlock - wait() releases the lock and acquires it
back when notified.
Change-Id: I940c24c04a1a2d4508d14d11b6174ff4fb2ab7d5
