Moved functions which parse the USB functions list into one common
place on UsbManager.
Deleted the no longer supported USB_FUNCTION_MASS_STORAGE.
Ensured that the UserManager.DISALLOW_USB_FILE_TRANSFER rule is
consistently applied during user switch and when changing the
current USB functions and make sure it only affects MTP and PTP.
Collapsed the boot completed and user switched receivers to
ensure consistent ordering of side-effects.
Validate the list of functions passed to setCurrentFunction() so
that the separation of concerns is clearer. It was somewhat
ambiguous as to whether functions such as ADB could / should be
enabled through that interface. Improved the docs for clarity.
Fixed a bunch of broken stuff related to the USB config
persistent property (list of default functions) that could cause
ADB and other functions to not work at all. Added new failsafes
to ensure that we reliably get back into a happy state.
Bug: 22206076
Change-Id: I02915ddfce7193a8f67a14f0d76bab22fc575dfa
This patch refines the crude check for potential RTL characters, based
on ranges containing RTL scripts and format characters that affect
bidi. This will make it much less likely that a StaticLayout will be
chosen instead of a BoringLayout.
Bug: 22328919
Change-Id: I9a0ed9b3f3373069052de21c836b3372f175430f
When an OTA contains a new package, the system performs some gymnastics
to ensure that we use the most up-to-date version of the package in
either the system image or user directory. But, during boot, we enforce
a package's codepath will never change. This prevents a user-installed
package from ever overriding the system provide package [regardless of
version]. In this one, specific instance, we allow a package's codepath
to change.
Bug: 22179337
Change-Id: I2c29a87801fb5960ffbd2268231446895ad1868f
Otherwise we leave user hanging in wizard forever, instead of
telling them that something went wrong.
Bug: 20914299
Change-Id: Ib9ff3a8c316976c6a1dfdaffa10762abbea0c229
This new class replaces the awkward string token and ConnectivityManager APIs
used by apps handling captive portals.
Bug:21343774
Change-Id: I1a2c69edb17322715bf8422bb4216b0ea60bfd59
Previously, once a network validated, for the purposes of comparing networks
to select the default network, we always considered it validated.
With this change if a network later fails to validate, we'll take this latest
validation result into account. This means if WiFi and cellular are up
(e.g. if we recently switched from cellular->WiFi, and cellular is now
lingering) and both are validated, but for some reason WiFi fails a validation,
cellular will become the default network connection.
Bug:20896761
Change-Id: I858aa10c1aaec5cd9032067f960963409107bdb1
Reduce the duplication of some logic so when falling back to Cellular
when WiFi fails to validate is enabled, there's less chance for bugs
and failures:
1. De-duplicate several Network vs NetworkRequest matching functions
2. Remove the very tricky nascent logic by adding a simple "lingering" bit.
Bug:20896761
Change-Id: I21da9e827eec9cfd6835fcaa650192b9186ed053
Removal of the (now-outdated) non-English versions; corresponding adjustments
to the related TOC file; edits to the English version.
Change-Id: Iec797963f355faf1034911d74d1d9580aaf0bc76
This got lost in the multinetwork work for L. It means
that if telephony stops having the ability to pass packets for a while
the rest of the platform doesn't know.
Telephony enters the suspended state if it enters a telephony call
while using certain radio access technologies, or if it switches to
one of those RATs while in a call. It also can enter this state if
it temporarily loses contact with the network - the modem will
not report the loss of the data call for an indeterminant time in
the hope that regaining the network will restore the connection
without harm to any ongoing ip layer interactions. For example
passing through a tunnel or taking an elevator trip may use this
mechanism.
bug: 19637156
Change-Id: If9fde68175e8561c19323c81fbfcb02a6e5a00fb
Use case: Exception while handling pairing cancel
Intent received
1. Initiate pairing from DUT to remote
2. Power off DUT after getting pairing popup
Root Cause:Crash observed in settings application
Change-Id: Ia05fe196ecf6a1d4ec26f85b0cf984e23089c728
Fix: Fixed by adding Null check in PairingCancelHandler