Fixed a problem where the key up for the ALT or META key was not
delivered to the task switcher dialog because it was deemed
to be inconsistent with the window's observed state. Consequently
the dialog would not be dismissed when the key was released.
Moved global hotkey handling for META+* shortcuts and ALT/META-TAB
into the window manager policy's interceptKeyBeforeDispatching
method. This change prevents applications from hijacking these
keys.
The original idea was that these shortcuts would be handled only
if the application did not handle them itself. That way certain
applications, such as remote desktop tools, could deliberately
override some of these less important system shortcuts.
Unfortunately, that does make the behavior inconsistent across
applications. What's more, bugs in the onKeyDown handler of
applications can cause the shortcuts to not work at all, for
no good reason.
Perhaps we can add an opt-in feature later to enable specific
applications to repurpose these keys when it makes sense.
Bug: 5720358
Change-Id: I22bf17606d12dbea6549c60d20763e6608576cf7
Add a Widevine-specific format sniffer to avoid having to
refetch data from the remote server.
Change-Id: I5fdb21fe7a0d6e74f2a6f06e6fbf8070b068ac60
related-to-bug: 5725548
This looks to fix a problem where the nv_data.bin file
file gets corrupted. When greping a radio log for "md5" if something
like following is seen:
RIL(s) : load_md5_state: MD5 state 1
RIL(s) : check_md5:
RIL(s) : compute_md5: path /efs/nv_data.bin
RIL(s) : check_md5: MD5 fail. orignal md5 '628647a8e5c6cac2d586199417c0103c' computed md5 '58a635cbaf5fe4ffb2797aeaa2b32709' (rild)
RIL(s) : check_md5:
RIL(s) : compute_md5: path /efs/.nv_data.bak
It means that corruption was detected and a back version was used
which is ok. Apparently that backup version can have the default
network type revert to 2G only thus causing the symptoms reported
in b/5695729 where after taking an OTA 2G becomes the default.
By calling setCurrentPreferredNetworkType when the sim is ready we
can reset the the network type to 3G.
Note: I also tried calling setCurrentPreferredNetworkType in
EVENT_RADIO_AVAILABLE but that didn't work and we would see
the response to setPreferredNetworkType failing as the ril wasn't ready.
RILJ : setCurrentPreferredNetworkType: 0
RILJ : [0004]> REQUEST_SET_PREFERRED_NETWORK_TYPE : 0
RILJ : [0004]< REQUEST_SET_PREFERRED_NETWORK_TYPE error: com.android.internal.telephony.CommandException: RADIO_NOT_AVAILABLE
Bug: 5695729
Change-Id: Ibbd29cda0b201a8c08f4dcfa5cec211611e1d599
Reduce likelihood of crash when state machine has quit and someone
sends a message using one of the public functions.
Bug: 5724844
Change-Id: I6582a1d19113e6ed545c8ab20adb0a414d8784a7
...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
According to TS 22.030 6.5.2 "Structure of the MMI", the dialing number
can not end with #. The format is like *SC*SI#DN. Correct the mmi pattern
to exclude DN# case. With this fix, processCode() will tread *NNN#DN#,
e.g. *400#16 digit number# in bug 5622718, as USSD and send via
RIL_REQUEST_SEND_USSD.
bug:5622718
Change-Id: Ifc8d0edff4308602a5f3fc651cf116bf6bad3cbc
New versions do not contain BCI hints, which were deleterious to
rendering in TextView with these particular fonts. WebView does not
use hints, and so TextView and WebView now render the same.
Font versions are updated from 1.00 to 1.01.
Bug: 5727604
Change-Id: Ib69318708994324caba36c10ac6159da70426d28
Bug: 5721663
Added content descriptions and made the listview allow navigation between nested
views.
Change-Id: I69d78d65e1bab829f63c2e6025051206e511f00f
...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
... a different app opens
In some cases when reparenting activities we could end up with a reply
chain that crosses task boundaries, so if an activity below that needs
to be reparented we pull that and the activities above it up into the
new task.
Change-Id: Ia4fa041ab7069e39dac162ddbf5b8e1de98675b9
The tablet system bar is too short for a full notification
row, but it will show the largeIcon of a new notification in
its full frame, intruding into the main application content
rectangle a bit. This is a good thing---the notifications
really pop out at you---but it looks a little odd if the
largeIcon is actually *small*: the icon is vertically
centered in the larger (invisible) rectangle, making it look
poorly centered on the system bar.
This change will detect short largeIcons and center them in
the system bar's height instead. Additionally, it applies
the same ticker background all the way to the left
underneath largeIcons that are not full-frame (and therefore
have transparent regions).
Bug: 5708907
Bug: 5560485
Change-Id: I32af45632df164c58fb960110063dbaa08b5536c
