...has wrong layout but corrects itself
Maybe fix issue #5405788: Device continuously opening and closing...
...the "Complete action using" dialog
I have never been able to reproduce this consistently, but here is
another stab in the twilight. It looks like during boot we have
a potential race where we could reset the config sequence number after
we had gone through a config change, causing ActivityThread to ignore
a following config change. Maybe this change will help.
Change-Id: I7199b6de370488e8d897d6a78ff6f15624da862c
Outsiders asking for this list may cause the list to change on another thread.
Fixing general synchronization issues.
bug:5531630
Change-Id: I7a3ee0bba3db40f45bcb0159491942fa4cf38c37
Sometimes the interface is removed before we can untether leading to
errors when cleanup up various rules (iptables). Do as much as we can
and then let a re-tether result in error if needed.
bug:5536516
Change-Id: Ib1d064ecc8e9022566f9b0e4678b33144906971c
When a process changes foreground status or dies, NetworkPolicy
updates its internal state with a lock held. In cases where there
is contention, this can block the AMS handler and prevent other
events, such as broadcasts, from being dispatched.
This change moves the incoming AMS events to an existing internal
NetworkPolicy handler thread, where they can execute without
blocking AMS.
Bug: 5497544
Change-Id: Ie0c620a620fd9f0f4eb02af510bd819efa4deb6a
Getting source-based routing working is too risk for this point
in the project but tethering is broken otherwise, so disable
the tethering option if DUN is required until we can get a real
fix in.
bug:5495862
Change-Id: I5e852bf30c887599024a8b61af86ffec1d5333af
Fix a few places where we would unfreeze the screen too early.
Now that we are no longer relying on surface flinger freezing, we
can't depend on it keeping the screen frozen until surfaces get
drawn.
Change-Id: Icb03bf30c9599a5e2016817bfa5ca6458adc7249
This is especially important when AGPS is disabled
Bug: 5355661
Change-Id: I072dbe1ddf43aa24c8fc39b750040504a1633c53
Signed-off-by: Mike Lockwood <lockwood@android.com>
Now the screen brightness will readjust to ambient lighting when toggling
auto-brightness on and off in Settings or the Power Widget.
Bug: 5486091
Change-Id: Ic98939fe1c59cb8def0f84266e48ca00329d6b30
Signed-off-by: Mike Lockwood <lockwood@android.com>
The correct behavior for the light sensor is to immediately report a value
when it is enabled, so this change should not be necessary.
Bug: 5426212
This reverts commit 5dca30affc517879315b3a928c78756cbc9cf689.
Two issues. A mcc/mnc-driven overlay means that the config at boot may not be
the config we wish to use - the sim card is read later which may switch the
config. Changed to read the configuration each time rather than once at boot.
Second, the secure-setting override was always trumping the resource config
as we weren't discriminating between a not-set default and a real setting.
This meant the config could never make DUN-required.
bug:5495862
Change-Id: Icd4e90ac1d32bbb704c0ff9cc69e954fb0a0b58c
We now have mInvalidateRegion which holds the region to invalidate, it
can be set from any thread as long as mInvalidateLock is held. We use
fine-grained locking here because mInvalidateRegion can be set from anywhere,
in particular frmo HWC callbacks.
Bug: 5466774
Change-Id: Iafca20aa3f5b25a87755e65bde7b769aa8f997bc
...wallpaper first time IRK81.
We were monitoring for file creates when those are not needed, and
receiving the initial file create was causing us to be confused.
Change-Id: Iccd3b7492c82895dba87f25c4881c538f300d342
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
When AudioEffectTest is executed, an Equalizer is created
and enabled on a MediaPlayer session. Effects on the output
mix are therefore suspended.
Then the MediaPlayer is released with the effect still enabled.
In this case, Audioflinger::purgeStaleEffects_l() fails to restore
the suspended effects when the effect attached to the released audio session
is removed.
When subsequent tests are executed on output mix effects, these effects cannot be
enabled as they are still suspended.
Fixed purgeStaleEffects_l() to restore suspended effects if the effect removed is enabled.
Also fixed EffectHandle::disconnect() to only restore suspended effects if the disconnected
handle actually has control over the effect.
Change-Id: I67232e7c34680b0cc01abfd57d5d510a524e5d4f
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
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
