This is a cherry-pick of https://googleplex-android-review.git.corp.google.com/#/c/399886/
Instead of storing a kb layout per device descriptor (which is expected
to be unique), store it for each vendor/product. This way we can keep
a consistent layout between identical but physically different keyboards.
There are some corner cases this is expected to fail on, namely devices
that incorrectly have the same vendor/product id. Devices that don't
define a vendor/product id will continue to use the descriptor to store
layout files.
Change-Id: I1f2508561992080459310d5a644dad65a9c24f1a
Under certain circumstances, the power manager might continue to
hold the display wakelock long after the display had been turned
off due to the mDisplayReady flag having an incorrect value.
1. An inverted conditional caused DisplayPowerState to incorrectly
signal the screen on ready state.
2. The DisplayPowerController failed to clear the block screen on
flag in the case where the screen was turned off before it became
unblocked from turning on. This could happen when the display was
rapidly turned on-off-on-off.
Bug: 13248135
Change-Id: I8faa3034695c83c8cd35613d81acccf40d22128d
The window manager and view hierarchy currently disable all drawing
when PowerManager.isScreenOn() returns false so no drawing occurs
while dozing. This will be fixed in a future patch to take the
display blanking state into account correctly.
This patch is a workaround to unblock development in the meantime.
Bug: 13133142
Change-Id: I2dc0b422c77285e657d73adca2606aa68264d987
We're getting signals from the radio and it sometimes drops out for
a while. This change will delay applying an empty country code
for 15sec but apply non-empty country codes immediately. It uses a
sequence number so we only apply the most recent change, even if
it's delayed.
Also secures the wifi call to set the country code as we can't
allow apps to set it willy-nilly.
bug:11062898
Change-Id: I610039a833e26d4c5c8b7b9ac1b7546f3c83446a
This is a change to add args to some of the profiler related
functions, including installd commands.
Also read properties and set command line options for the runtime
profiling parameters.
Changed calls to isDexOptNeeded() to isDexOptNeededInternal(). This
needs additional arguments passed for profiles.
Bug: 12877748
Change-Id: I1a426c9309d760bac0cf92daa298defee62287c1
Conflicts:
core/jni/AndroidRuntime.cpp
- Introduce a boolean extra for intent TIME_CHANGED that
specifies if the user wants a 24 hour format or not.
- Have the ActivityManagerService inform running processes
of changes to this preference.
- Add plumbing in ActivityThread to inform j.t.DateFormat
Change-Id: I05fafb903ae54e39c03a048b7a219dc5a93fd472
...broadcasted repeatedly at every boot time
Remember the last done pre-boot receivers, so that if we have
a new pre boot receiver appearing (without the platform version
changing), when we re-write the file of done receivers it will
contain all of them, not just the new one.
Change-Id: I4ed3478edc549d4b023ec4b3719111bc4d970ae4
Permission denied when trying to launch an activity from a notification
We don't remove pending intents when updating an app, which is necessary
to keep app widgets and other things working. However, when uninstalling
an app, we should clear out all of its pending intents.
Change-Id: I95067b31098115b5a7b127766fd093750063bbb8
This change fixes two problems - first, if you rebooted phone after
turning on Airplane mode, Wifi controller goes to ScanOnly mode which
may end up in Wifi radio transmissions. Secondly, because of this
incorrect state, the state machine doesn't turn on Wifi once Airplane
mode is turned off.
bug: 11409692
Change-Id: I55b4a5352a72a9c783e1b9891dd5363434585fb0
This may mean that secondary networks have bad network settings,
but currently default settings are overriden by secondary nets
which seems worse.
bug:13211589
Change-Id: I08d56e618208781bf6b21a88663c2b8503a4f226
When WindowManagerService creates a new Task, it passes atoken to the
Task constructor. In this case atoken is added to mAppTokens list by
the Task constructor and then it is added manually again by calling
newTask.mAppTokens.add(atoken). As a result, the same atoken is present
in mAppTokens list twice.
When another window token is added to the list, it may be placed in
beetwen duplicated tokens and corresponding window will be hidden from
the screen by corresponding duplicated windows.
From user perspective it means that some windows will not be displayed
on the screen.
The issue is fixed by avoid adding atoken to mAppTokens list manually
when it was added already in Task constructor.
Change-Id: I10628e68186160fffdde07beb7d84ab3cecb7051
We need to specify "PBKDF2WithHmacSHA1And8bit" now in order to get precisely
the same output as was previously generated with "PBKDF2WithHmacSHA1". We
also now try both when it's ambiguous which was used to generate the archive
checksums.
Bug 12494407
Cherry-pick from master.
Change-Id: I2d6081dd62f50f7d493045150b327ed120de7abd
The ACTION_EXTERNAL_APPLICATIONS_UNAVAILABLE broadcast now uses the
EXTRA_REPLACING intent extra when it is sent as part of an upgrade operation
on a forward-locked application. Update PackageMonitor to recognize this
new information and express it appropriately to the observer.
Bug 11988313
Cherry-pick from master.
Change-Id: Iecea1876ffc918f23f9fa5845f1f89ed8d740dd5
This fixes the logic on the death handlers for notification listeners,
and doesn't unbind from the listener services so that the system will
bring them back up again.
Bug: 12587702
Change-Id: I44ce250e0e1c2583836dc823d9a333dabec51df9
The power manager sends SCREEN_ON and SCREEN_OFF broadcasts
purely based on the current wakefulness state. In particular,
when the system is awake, we consider the screen to be on even
if the screen may actually be off due to the proximity sensor
or some other condition. Likewise when the system is dozing
or asleep, we consider the screen to be off although technically
it may still be on and dozing.
This behavior is maintained for compatibility with applications
that interpret screen on / off as an indicator of user presence.
As it happened, the value of PowerManager.isScreenOn() did not
always match the state indicated by the broadcasts under certain
situations. Instead, it was based on the desired screen state.
These states used to be closely correlated but the addition
of doze mode causes them to diverge in meaning.
One consequence is that wake events from input devices might not
always wake the device from sleep unless the display's power
state was actually DOZING or OFF even if the power manager's
wakefulness was already DOZING or ASLEEP. This is now fixed.
Change-Id: Ie819c6d2c5a9ffaaf3101c5dee93ff72e9bc9f30