Note that eventually VideoPlaneView should not inherit from SurfaceView.
Remove a few trailing spaces too.
Change-Id: Ia0a461169d560435a827861be2cc15f1e3ee68fa
This makes it much easier to define a disabled state color as an alpha
modulation of some base color.
Change-Id: Ie2ecf40b1f6560fcd8eda208d780616dddfc0d08
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
Was incorrectly clearing the DRAWN flag and updating mLastIsOpaque from
partial invalidations, though why this should be different is somewhat
of a mystery.
BUG: 13138721
Change-Id: Ic8d11a64406bc78e94adec7355c1f50d87567887
* commit '5f652b9fdfbcc279353955f7ef86b72d2ef9f5fb':
open("/dev/rtc0") failure in AlarmManagerService.setTime() should be non-fatal
Move time setting code from SystemClock to AlarmManagerService
* changes:
open("/dev/rtc0") failure in AlarmManagerService.setTime() should be non-fatal
Move time setting code from SystemClock to AlarmManagerService
BackupDataReader / BackupDataWriter were implicitly assuming that when
instantiated, the underlying fd was positioned at start-of-file. If one
tried to e.g. open an existing data stream to append further data to it,
things might randomly fail (at read time, possibly when consuming the
stream later) due to incorrect alignment of the data entities: the
appending writer would assume that no padding was needed to achieve
correct alignment, and this might easily be false.
Now the underlying native reader/writer helpers recognize the true
position within the file when constructed, and as a result it's now
safe to e.g. construct a BackupDataOutput for an existing file and
then append to it.
Change-Id: If0484921e687852f923a4b4efabff573a6c16981
The value for the TCP initial receive window comes from,
in order,
kernel
/proc/sys/net/ipv4/tcp_default_init_rwnd
init.rc (via properties)
net.tcp.default_init_rwnd
properties
net.tcp.default_init_rwnd
gservices
Settings.Global.TCP_DEFAULT_INIT_RWND
Bug: 12020135
Change-Id: I0e271be19472900fa9f3bab037d53383ec014a9e
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>
JNITest class is no longer actively used. This patch
removes the class (java and jni) files.
JNI interfaces and calls are extensively tested in
the art unit tests (art/tests) and in cts (see
CtsJniTestCases).
Change-Id: I62f7c72deb5d206fa3f545ae39a9cb9011110d0a
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
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)
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
(cherry-picked from 4de3f481bc)
Change-Id: If22daf40eef46f8df9f94d65ddcc52c45b3acf2a
Constants are derived from this doc:
https://docs.google.com/a/google.com/document/d/1lmlFcTeefLDRp_bpMrXk3yK9nKxoTVfpcShanpLxiMg/edit#heading=h.b16863tyyjzv
That doc contains the full explanation of these changes.
I'm making this change on behalf of {elmas,pengr} who don't have
android source access but designed this in collaboration with
rharagutchi on the play music team. I'll probably have to route any
significant questions through them.
Bug: 12874557
Change-Id: I85a4bee57a2bde519da0dc6de2cad9d036da225c
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
Bug: 13111945
Fixes an issue where a layer is destroyed after the GLRenderer
lost its Surface. Instead just check that the context we want is
current regardless of the active surface
Change-Id: I6537e6232b5c667b218b896ed5ef390fbe956344
