The dreams manager also manages dozing. It has a minimal footprint
so there is no real reason to disable the component (it just makes
debugging more difficult).
Improved the documentation of the config_dreamsSupported resource
to clarify exactly what it controls.
Bug: 12494706
Change-Id: I78244846f7c1ddfd11bc1605af59b0db91337971
When the ActivityView is part of the home activity special checks
must be made. Things like don't move the home stack to the back
when the ActivityView activity is resumed.
Fixes bug 13119389.
Change-Id: I3a6040c9824dfd4b8ee97d58d131b14a519b470a
A task is scheduled for deletion after the final activity has
been removed and has animated away. But if another activity is then
added to the task the deletion flag must be reset.
Also added improved debugging.
Fixes bug 12987986.
Change-Id: I207ea6e9592a9e036d67aa5d1465b4acc5bdd120
Setting the time-of-day clock is still useful on systems where the RTC
device is not yet brought up or otherwise unavailable. This matches the
in-kernel behavior of the Android alarm driver.
Change-Id: I6d4fdadab12e241ada7419425efd55bd13873c55
Signed-off-by: Greg Hackmann <ghackmann@google.com>
On devices using /dev/rtc instead of /dev/alarm, updating the
time-of-day clock and RTC are separate syscalls. Hence the clock and
RTC could be left in inconsistent states if two threads called
SystemClock.setCurrentTimeMillis() simultaneously.
By moving this code into AlarmManagerService, we can put a global lock
around AlarmManagerService.setTime() and prevent the race condition.
Note that access to SystemClock.setCurrentTimeMillis() is now gated by
android.permission.SET_TIME, where before it was gated by filesystem
permissions (i.e., could the process write to /dev/alarm or /dev/rtc).
Change-Id: Ia34899a4cde983656305fd2ef466dfe908ed23c8
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Using the alpha value to trigger a resizing of the DimLayer was a
Bad Idea. The alpha value should reflect the true alpha value and
not be used to trick the code. Actually changing the size and
position is a Better Idea.
Fixes bug 13101776.
Change-Id: I11c16b8276919ea85960fe87bb17c0956ce8a3b1
When a doze component has been specified in a config.xml resource
overlay, the power manager will try to start a preconfigured dream
whenever it would have otherwise gone to sleep and turned the
screen off. The dream should render whatever it intends to show
then call startDozing() to tell the power manager to put the display
into a low power "doze" state and allow the application processor
to be suspended. The dream may wake up periodically using the
alarm manager or other features to update the contents of the display.
Added several new config.xml resources related to dreams and dozing.
In particular for dozing there are two new resources that pertain to
decoupling auto-suspend mode and interactive mode from the display
state. This is a requirement to enable the application processor
and other components to be suspended while dozing. Most devices
do not support these features today.
Consolidated the power manager's NAPPING and DREAMING states into one
to simplify the logic. The NAPPING state was mostly superfluous
and simply indicated that the power manager should attempt to start
a new dream. This state is now tracked in the mSandmanSummoned field.
Added a new DOZING state which is analoguous to DREAMING. The normal
state transition is now: AWAKE -> DREAMING -> DOZING -> ASLEEP.
The PowerManager.goToSleep() method now enters the DOZING state instead
of immediately going to sleep.
While in the doze state, the screen remains on. However, we actually
tell the rest of the system that the screen is off. This is somewhat
unfortunate but much of the system makes inappropriate assumptions
about what it means for the screen to be on or off. In particular,
screen on is usually taken to indicate an interactive state where
the user is present but that's not at all true for dozing (and is
only sometimes true while dreaming). We will probably need to add
some more precise externally visible states at some point.
The DozeHardware interface encapsulates a generic microcontroller
interface to allow a doze dream for off-loading rendering or other
functions while dozing. If the device possesses an MCU HAL for dozing
then it is exposed to the DreamService here.
Removed a number of catch blocks in DreamService that caught Throwable
and attempted to cause the dream to finish itself. We actually just
want to let the process crash. Cleanup will happen automatically if
needed. Catching these exceptions results in mysterious undefined
behavior and broken dreams.
Bug: 12494706
Change-Id: Ie78336b37dde7250d1ce65b3d367879e3bfb2b8b
Changes in this patch include
[x] Long(64-bit) is used to store native pointers in
AssetAtlasService and related classes as they can be 64-bit.
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
Change-Id: Ib4c77c134e3ad5b21732e20cde9a54a0b16bdab1
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
When switching USB modes there are often spurious connect and disconnect events
that occur before reenumeration is complete. There is currently a 1000ms timer
to "debounce" the disconnect events. But with some USB accessories, this timeout
is not long enough, which results in an endless cycle of attempts to enter
USB accessory mode when the phone is connected.
To fix this, we now wait up to 10 seconds for the host to successfully configure
the device when entering USB accessory mode before giving up.
This is separate from the existing debounce timer, so the behavior of the
USB state change broadcasts are not affected.
Bug: 12877769
Change-Id: I7aa61f8a618546d749a7ddfc97bf103029a73d03
* commit '23ef1b5e0b84e3bb726454b97846f91f2efad212':
A background started service is removed from mStartingBackground when timeout. Fix is to make sure mStartingBackground is updated to remove one.
Converts surfaces from transparent to opaque and opaque to transparent
without creating a new surface. Uses the new SurfaceControl.setOpaque
method.
Fixes bug 12387406.
Change-Id: I669c064e622e211b00b1585183a488d5b3f4b778
PackageManager does not need to create a hash set
when comparing two sets of signatures, where each set
contains one signature. This is the common case for
most applications.
Bug:13029313
Change-Id: I61883d85960db7b376e234d7abae6149c4d20245
Fixes the case when the app on system is newer than the
currently installed. Something that can happen e.g. after
a FOTA update.
Change-Id: I102e9cdd5693d5e66667c0c8989dc2643c72dd16
