It is no longer sufficient to check the value of
internal.R.bool.config_showNavigationBar to determine if a
navigation bar (separate from the status bar) is shown on a
device, because the emulator needs to be able to override
this value (now possible by setting qemu.hw.mainkeys to "1"
or "0", for navbar or no navbar, respectively).
This logic is now contained in PhoneWindowManager, and any
clients wishing to know whether the system has a software
nav bar should consult the new hasNavigationBar() method.
Bug: 5404945
Change-Id: I119d32a8c84b88b2ef46f63244e7f11dc5de0359
A LayerScreenshot is a special type of layer that contains a screenshot of
the screen acquired when its created. It works just like LayerDim.
Make sure to call compositionComplete() after rendering into a FBO.
Bug: 5446982, 5467587, 5466259
Change-Id: I5d8a1b4c327f9973d950cd4f4c0bca7f62825cd4
there was situations where SF's main loop would run (as if there was
an invalidate), but the dirty region was empty (so no new buffers
were retired). In this case we return early and don't swap, which
would cause drawing artifacts.
Bug: 5476838
Change-Id: Id3b7bf4b7aabec7919c50d9278eb2165973a4c3d
Avoid infinite loop in querying omx component about the supported color format.
Change-Id: I4997efd36462c792a6d8b5e04c79a80966a559fe
related-to-bug: 5466057
also update API levels doc with ICS version
add info about system themes and using an options menu button
Change-Id: I8adb2486fcceb91856fb1cbca4900bdb10ea6fe7
AudioFlinger logs a warning when a write to the audio HAL
takes too long to return. The threshold for this warning is
a rule of thumb based on the assumption that the audio HAL will consume
buffers at a regular pace.
The introduction of low power audio mode with larger buffers and writes
occuring in bursts makes that this threshold is often exceeded resulting
in excessive and misleading warnings.
The threshold is raised to remove unwanted warnings but we should reconsider
the usefulness of this warning altogether.
Change-Id: I5ef6898ea28d879cede3e47da542a64092a3cca4
when taking a screenshot, in particular, we could end up
with stale GL state when drawing LayerDim which resulted
in incortect rendering.
Bug: 5467587
Change-Id: Id9fbed2843481d31063620f3662b364c7e3ac781
This fixes three issues;
- Make the background black while the transport is showing.
- Show scrim sandwiched between artwork and overlapping UI.
- Remove gaps in sides of background assets.
Change-Id: I563fc680c4c042d8b25ec37332aeab528cf838ca
If you turn the device from portrait to landscape mode and immediately
invoke the lockscreen, it will come up in landscape mode and switch to
the desired portrait mode within a couple of seconds. Previously,
Face Unlock would come up in landscape mode, but its position would
not change once lockscreen corrected itself, causing Face Unlock to be
partly off the screen.
This has been fixed by checking if we are already bound to Face Unlock
when the layout is created. If this is true, then the layout is being
created due to a change in orientation, and we stop Face Unlock, and
restart it at the new position.
This commit also adds a fix where we now use INVISIBLE for the Face
Unlock area when it is not showing instead of using GONE. The
dimensions of the Face Unlock area is 0-by-0 when set to GONE, and we
want to avoid the possibility for the Face Unlock service being
assigned a zero area. I'm not sure if this was ever causing problems,
but it certainly is not the intended behavior.
Also cleaned up some comments and logging.
Change-Id: I68deb49cb26dafb5c238167d0c23f0eed2cfb75a
The basic problem was that at some points during setup wizard, this would
happen:
1. The app's process is killed.
2. The app's process is restarted, but not to actually resume the
setup wizard activity, just to put it in the stopped state.
When doing this, the saved state is cleared but the app will
never provide a new one.
3. The app's process is killed again. At this point, because the
saved state is cleared, the activity is completely removed.
4. Eventually the entire activity stack becomes empty, and a new
setup wizard activity needs to be created as the home app.
There is a combination of bad stuff going on here.
First, why is the process being killed? At this point the setup
wizard is the home app, so it shouldn't be killed. There were two
reasons why this was happening:
- CryptKeeper still was not completely cleanly going away. To fix
this, I removed the check in the activity manager to not allow
an activity to finish if it is the only activity on the stack and
maybe-kindof looks like the home app. This really wasn't necessary
(we always take care of starting a new home activity if we find the
stack is empty), and outright dangerous with all of these things
purporting to be home but not.
- There was an issue in computing the oom_adj where the home app
would not be marked as "not hidden", and if we had to re-compute
its oom adj in the current sequence would then give it an
adjustment as a background process... and with all the processes
we spin through during boot, it quickly got down to background
#16 and killed.
Second, what is going on with the state? This is easier, the code
in the activity manager to create a new activity but put it in the
stopped state was still clearing the saved state. The saved state
should only be cleared when going in to the resumed state. When
going in to the stopped state, we can just keep holding the same
saved state.
Change-Id: I7d21cdcfa082d98ca70c79d9923e29605ee4353e
Making the notfication delete-all animation smoother by carefully
choreographing the various parts of it. The problem with the previous
animation was that there was simply too much going on at the
same time, causing things like layout and recreating display-lists
in the middle of animations that became choppy as a result. This
approach swipes all items off quickly, then scrolls the shade up to the
top, making both sets of animations smoother as a result.
Fixes#5431207: Notification delete-all should be smoother
Change-Id: Iefe8ab5d661e05adcd10379dab85227d17904450
