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
...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
If an app takes the 5-second ANR timeout before responding to a
drop, but then recovers, we were inappropriately throwing an
exception back at it for having acknowledged the drop after we'd
abandoned the operation out from under it. Now we let such
responses slide without taking any punitive action: the app is
still okay, and the drag/drop operation was cleanly terminated
already anyway.
Bug 5045618
Change-Id: I0b7e76c61f0f8c97e41280b542a470a7d3c8d86f
This patch fixes the following warning:
W/Binder: The following Binder class should be static or
leaks might occur: com.android.server
.InputMethodManagerService.MethodCallback
...in hope of removing a possible memory leaks.
Bugs: 5481376, 5461066
Change-Id: I1764090a7059d9bf9e5d90683d7ac190c83415de
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
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
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
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
Only unbind once.
Also protection from removing a SpellCheckerBindGroup from mSpellCheckerBindGroups
if it is no longer the current entry there.
Change-Id: Ic585295dfae77eae101a611afbf116bc681290ad
A LayerScreenshot is a special type of layer that contains a screenshot of
the screen acquired when its created. It works just like LayerDim.
Bug: 5446982
Change-Id: I7814aff2380e7e146937f2b641907be2a30c76cc
This supersedes any backup-password that the user might supply. Per
design, the device encryption password is also always used to encrypt
the backup archive.
The CL introduces two new strings, used for prompting the user for
their device encryption password rather than their settings-defined
"backup password" when confirming a full backup or restore operation.
Bug 5382487
Change-Id: I278737927a4ecbb765bfb5ecfd28a4cb8dae52ef
