The DialogFragment used for WarningDialog was not instatiatable
by the fragment manager.
Bug:17435234
Change-Id: I5f65dd1e0ec0b95d048934480bd5fafd8648ab7c
Settings has super powers because it shares the system uid. We prevent
those powers from being exploited by malicious authenticators by
checking the intents those authenticators provide.
We will only launch intents that resolve to Activities that are exported=true
or owned by the same UID as the authenticator.
Bug: 14408627
Change-Id: Ia179df8561d29745767dac0f3c97eb0f68083f59
+ The root of the problem is that the callback for a device change may be
set before the fragment has a layout. Then if a change does come in,
getView() would return null. This fix delays registering the callback
until appropiate.
Bug: 17404518
Change-Id: Ibd0e90f82593d45729f427bcc2e40fe9195eb42a
+ Multi-SIM has been punted out from the L release. This change disables
the SIM Cards UI while keeping the code base.
Bug: 16808006
Change-Id: I2bd7ad430a6309f3f2241cd26ec86268aa31b699
Unfortunately the Settings app has super powers. We shouldn't let
untrusted 3rd party authenticators re-purpose those powers to their own
nefarious ends. This means that we shouldn't pass along PendingIntents
that can have addressing information (component, action, category)
filled in by third parties.
Bug: 17356824
Change-Id: I397d26c5f465ddfb0e58bbc66cd44756e58cc507
This fixes a bug where the TrustAgent intent was being lost when
the device configurtion changes. It used to depend on a view that
gets recreated. Instead, we persist the actual launch intent
which works across activity restarts.
Fixes bug 17040470
Change-Id: Ia1c93867254cfdc27683a767cf41fe74dbb97db0
- remove any reference to the Switch and use the SwitchBar API instead
- set the initial state of the SwitchBar depending on the WifiManager
Change-Id: I556bf8a007892c057edf7c6c144f71b2dcfe4f99
As a fallback we attempt to get DISPLAY_NAME from the
provider. Any other URIs probably don't have titles.
Bug: 14093281
Change-Id: I39adbad52ef6dcc1686cbc738457b55c33948bd6
There is a NPE in the print settings if the following occurs:
We open the print job state UI in settings for an ongoing print
job (now we have action bar buttons for cancel and restart);
now the print job gets completed and we update the UI and
since the print job is not longer present we nullify the current
job reference and finish the activity. But since activity
is not finished immediately there is an opportunity for the
user to click on the action bar options which results in NPE.
The fix is to not update the print job instance in the update
UI method if the job is not available, i.e. the update method
does not mutate state if the job is no longer present, as we
are finishing and performing an operation on a finished job will
have no effect.
bug:17387134
Change-Id: I501ed1e05b8b70584b3299a16e93ead5ab7f155f
- will actually make the Ripple look better and a bit longer
(it was showing and disappearing a bit too fast)
See bug: #14974443
Change-Id: I7a0354c679cfa8d9596bcb957c922b8dcf88f0e3
