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
The old code was dependent on the order of things in config.xml. This fixes that
so hipri will get the correct dependency-met value at startup. Good ITS test.
bug:5382518
Change-Id: Ie327ab1abbc5697ffab0ed4d8c9d6de321513adb
The TouchExplorer was not taking into account the case with incative
pointers while dragging. If one puts a finger down and then perfroms
a dragging gestore the explorer tries to inject UP event for the end
of the gesture upon every of the two dragging pointers going up instead
only for one the first went up.
bug:5476098
Change-Id: I20d2dd7bde7e016b0678a35d14cd068d9ff37023
- Removing the second ticker text
- Adding a new animation to the status bar
- Adding a large icon to the notification
Change-Id: I8778178519fc72ffc299e8d624069b684475191d
The DPM seemed to always go through ExternalStorageFormatter to wipe the
device and SD card. For SD cards emulated on a fuse filesystem, this
seems to fail unless the device is wholly encrypted. Bypass
ExternalStorageFormatter in those cases and just wipe as normal.
Bug: 5458396
Change-Id: Iec759ef894c6bd3863cb4e7329f4de4584c60c1a
An internal method was changed to add parameters to support a new
feature (7-bit national language tables). Add a compatibility
wrapper for the original method signature, which is used by OEM code.
Bug: 5334032
Change-Id: I1acba369b1c1da52c4a950fd4ae21d693652e9c5
This fixes a bug where we were no longer showing the countdown dialog
every 5 attempts or "forgot pattern" button when the user has a fallback
password enabled on the pattern unlock screen.
It now correctly shows the dialog whenever the user hits a multiple of
5 bad attempts on any of the pin/pattern/password screens.
Change-Id: I4eb47b4149958a93572d256a4a70f9d67bc1eb38
would only work in the case where onSaveInstanceState was called.
- combined mExistingAccounts and mSavedAccounts into one field
- set this field when starting the addAccount request
- write this to the instance state if the request state
is ADDING_ACCOUNT
- read this field from the instance state, if any,
when the request state is ADDING_ACCOUNT
Bug: 5459669
Change-Id: I5a7b4943de8e706cc8a21ff9f54fce4258f18b19
This works around a file descriptor leak in Skia. It also improves
view creation time by avoiding re-loading the font every time a
DigitalClock is created.
Change-Id: I5c46445da36b1e6ba06c8ca340e436835d281180
