This reverts commit 3029efc5f7.
Reason for revert:
To fix null pointer crash in Pairing dialog. Dialog maybe triggered by intent, in which LocalBluetoothManager couldn't have instance for BluetoothDevice and will return null. As a result, we need to depend on method in CachedBluetoothManager to handle it.
Bug: 115754654
Bug: 112735753
Change-Id: I1ebf1f1c2829cfb75e6c382df5acf785fe54a185
- change to use the new NetworkStats.Bucket instead of
NetworkStats.Entry when iterating through the detail data.
Bug: 111751694
Test: make RunSettingsRoboTests
Change-Id: I305cc384320e4a72531d80dd9a00a3034ab12837
When the last custom card for a specific type is removed,
onContextualCardUpdated should receive the cardtype info so we can
remove it from main data set.
- Reverted onContextualCardUpdated method signature back to before
- Force ConditionContextualCardController to send an empty list if
everything is removed.
* Note: the update logic is pretty complicated to handle
add/update/remove all together. In the future we should consider
spliting the removal logic to simplify this area.
Change-Id: Ied688deb693ec33e0017be02cf5c743a754a6e61
Fixes: 115572494
Test: visual
After we switch secutiry from EAP to WPA, add button will become
disabled forever. Main reason is that we use view visibility to decide
which security type it is. In this case target view is visible while its
parent view is gone. So even though UI shows correctly however we still
think it is in EAP mode.
This CL check the mAccessPointSecurity directly instead of depending on
fragile view.
Fixes: 114689178
Test: RunSettingsRoboTests
Change-Id: I4284d25e6bf86ee7c5e7c0e17f0834c719d8d587
- Current EditText value will set to preference text if we click
OK in EditTextPreferenceDialogFragment. We will set preference
text to default when click cancel in DeviceNameWarningDialog.
Change-Id: Iab9561953b58276e98ee68d9196fa18e0dc3d78c
Fixes: 115693838
Test: make RunSettingsRoboTests
Custom cards might need to monitor lifecycle events, waiting for
onFinishLoading is too late.
Also make sure custom cards cannot change card type.
Test: manual
Change-Id: Ib8f8e6e48926a63c9d241ed9e9843c025e3f634a
- query the intent activites with flags 0, so that only
enabled activities will be returned.
Change-Id: I6ec4e3f3fdff850228a723bcb2d2bdc5721b41eb
Fixes: 111796304
Test: make RunSettingsRoboTests
- when enabling multi user, also need to update the visibility of the
Add user preference, but need to check the add user capability as well.
Change-Id: Ia243901c7537bdb39ca3a39aed559b003f803e4d
Fixes: 115397726
Test: make RunSettingsRoboTests
- when multi user is enabled, we should keep the current visibility for
AddUser preference, since earlier check has been done to update its
visibility according to the add user capability. We should only set the
visibility to false if multi user is disabled.
Change-Id: I246e9242f255dbd57c5309b2d16c95d202607531
Fixes: 114241868
Test: make RunSettingsRoboTests
The new TopLevelSettings page uses a standard DashboardFragment to host
all top level settings. It's easier to maintain than DashboardSummary.
It does not support conditional cards or suggestion cards. We will use
PersonalSettingsFragment to host these as contextual cards going
forward.
Bug: 110405144
Test: visual
Change-Id: I2ab2d3556e870e86ebc18f9876336c4a3a361897
On some devices, data usage is not available; thus, it is possible that
ACTION_DATA_USAGE_SETTINGS has no matching activity. If no matching
activity is found, we should not populate "data usage" in the summary
field.
Bug: 111398942
Test: Manual check. I see that data usage is no longer visible on
devices without Data Usage activity.
Test: make RunSettingsRoboTests
Change-Id: I838206b76497c6550ef4826ad19e605cd32906ee
Make existing Settings Conditions show up in the new homepage as custom
view.
Bug: 113451905
Test: robotests
Change-Id: Ic49089f95ff04442a887cda97481e945136f7209
- and update all its subclass to extend DataUsageBaseFragment instead.
Bug: 111751694
Test: make RunSettingsRoboTests
Change-Id: Ic5720af43082d8b39642b6a539515f3f20d32694
This means that in some cases RestrictedLockUtils has to be used and in
some RestrictedLockUtilsInternal.
This causes a lot of trivial code changes.
I also updated the ordering of the imports in all affected files.
Bug: 110953302
Test: Built
make -j RunSettingsRoboTests
Change-Id: I9bdf8b89134f853bae4f38c81af436715c73e924
When requestCode is 0, we will not finish activity.
Change-Id: Ib630951739031b05c83efe189875a4a41c8e51ec
Fixes: 113372155
Test: make RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings.password"
