For example when changing display states.
Save view states to solve this issue.
- Save current tab. (System / User)
- Save group expanded state. (Personal / Work)
- Save scrolling position of each group.
Also updated to ViewPager2 and updated the styles.
Bug: 204839552
Test: manual
Change-Id: Ibeda50b50e7dfd2ba071b75fe2aa88ef560f4c88
- for fragments that do not implement the preference screen, change them
to inherit from InstrumentedFragment instead.
Change-Id: I791c2634024bd2c248efea955be5c680180d735c
Fixes: 68277111
Test: make RunSettingsRoboTests
- remove all code that check for the feature flag, and use the new logic
by default.
Change-Id: I7fbe60da84c1c0f35e7241402a71d2bc4cd300e6
Fixes: 64564191
Test: make RunSettingsRoboTests
1. Move getPreferenceScreenResId() from individual subclass to
InstrumentedPreferenceFragment.
2. Removed InstrumentedPreferenceFragment.getTitle() and let the
preference fragments that do not have preference screen set the activity
title directly instead.
3. Removed OptionsMenuFragment as all it does is call
setHasOptionMenu().
- changed subclasses of OptionsMenuFragment to extend from
InstrumentedPreferenceFragment directly.
- none of the exisitng subclasses actually implements the option menu
related methods to provide any option menu. So, the setHasOptionMenu()
call is not added to the subclasses.
4. Update Languages preference title.
- launch the fragment from the preference controller instead of from the
default handling, as we need the title res id at launch time to get it
work properly when retrieving the title from back stack.
Bug: 64564191
Test: blaze-bin/screenshots/android/i18nscreenshots/i18nscreenshots
Change-Id: Ibecdcab32cbaed8bf604ec5ebe0a926b4e489a7d
- Add missing title to preference screen xml so that they will be used to
set the activity title when the fragment is launched.
- Also updated some incorrect preference screen titles.
- Overrides getTitle() in preference fragments that do not use the
preference screen xml.
Bug: 64564191
Test: blaze-bin/screenshots/android/i18nscreenshots/i18nscreenshots
Change-Id: Id72d5ddf18f0962bc484de8bbd847a2e55d6371e
[Cause of Defect]
TrustedCredentialsSettings#mKeyChainConnectionByProfileId is get/set by
more than one thread. Main thread would set it in onDestroy method, and
AsyncTask would get and set in the doInBackground method. So
mKeyChainConnectionByProfileId.get(profileId) would get null after
onDestroy method get called.
Bug: N/A
Test: Debugger to simulate concurrency
Change-Id: I0664d1e9b88b079855354ce0e6fe014a98a22327
Signed-off-by: daqi <daqi@xiaomi.com>
Even better would be to completely get rid of non-framework code using
this, and then even better than that would be to completely get rid of
all code using this.
Test: manual. open Settings > Security > Trusted Credentials before and after this change. Number of certificates should be the same. No crashes should happen in either case.
Change-Id: I4237e630b903eb04e6b572d6464a40d183b24276
And match the behaviour of the dialog button that does the same thing,
so it only asks for confirmation when something is being irrevocably
deleted.
The dialog button should not be removed as it's used by system services
that deeplink to a specific cert to give the option of reviewing,
removing, or trusting it.
Bug: 31159682
Change-Id: I4fb3f38f8ab0e80e5c2dca0fc3d6d3bd4db26bb6
Bug: 30681771
Test: SettingsUnitTests
Refactor visibility logging from InstrumentedFragment into a mixin. And
apply mixin in remaining fragments.
Change-Id: Ibbb59904336254a3e4bb9e8c7d0b36e5a6bc2622
Made use of the shiny LayoutTransition.CHANGING animations. Now it's a
little more obvious where things are going when tapping a header.
Future work: maybe show the usernames / user icons in there too? This
could get complicated, and it'll need to be done everywhere at once.
Change-Id: Id7396235abe6218d591d16db91af0f56a83a7bcd
Fix: 28310002
When trust button is clicked, if ConfirmCredential (CC) is shown,
and user successfully unlock CC, trust the cert immediately
Bug: 28752364
Change-Id: Ied4aeda59a668a9dd2bf079a385b1fecd8eabb9e
- Show ConfirmCredential in TrustedCredentialsSettings when Trust button is clicked
for the very first time since the activity launched
- Warning activity (work mode off, crpyto-aware) should not be shown when the activity is started. Also fixed it here.
Bug: 28619980
Change-Id: I084b70883c087376e437a9ad3238d7c3313a0a17
UI Change for 2-profile case:
1. When both personal and work listview are expanded, half height is allocated for each list view
2. When only one listview is expanded, full height is allocated to the list view
Video can be found at go/trust-cred-split-view
- Use 2 ListView instead of 1 ExpandableListView in order to scoll the list independently
- The ui is not changed for only one or more than 3 profiles.
- Remove TrustedCertificateAdapterCommons, and wrap GroupAdapter by ChildAdapter in order to re-use more codes
- clear mAliasLoaders in onDestroy. (Seems it's a bug.)
- When work mode or fbe locked, force to collapse work list view. User message will be prompted when user press on header
- Groups in GroupAdapter is set synchronously instead of async, since we assume the number of users are fixed during initialization
- DataSet events will go through GroupAdapter to notifiy ChildAdapter
Bug:28236955
(cherry picked from commit 7dde845544)
Change-Id: I87293afc56e9cc270c2289111bab6f1809351faf
- Allow user to trust multiple certs in chain in one AlertDialog
- The animation is similar to GrantPermissionsViewHandlerImpl.
- Fadeout current, Slide-in next cert from the right.
- Not animate scale as the CustomeView in AlertDialog matchParent
- Refactor CertDialogBuilder into a separate class
- The change for config multiple cert into the dialog is another CL
note: For single cert case when user taps on a system/user cert,
no change is visible to user after this change
Bug: 18224038
Change-Id: I09ee8f683031c800830af4001582882d61cd4974
- Put Disable button for system cert and Remove button for user cert as action button in cert dialog
- OK (dismiss) button is displayed when trust button is not shown
- Showing chain of cert dialot will be in a later CL
Bug: 18224038
Change-Id: Ieef70e12fd8bdf711be48dc0488f03dbe143d3c5
SettingsPreferenceFragment has this already set so that the drawer
layout will work when the menu doesn't exist. However, some fragments
are not preference fragments, and we need to set setHasOptionsMenu
manually.
bug:27879503
Change-Id: I6faadeb56dab00af611ac413109800822038c66d
Remove the enable/disable button in certificate setting dialog if restriction
has been put on the respective profile. Also catch security exception just in
case.
Bug: 18899182
Change-Id: Ia247ab264c1b2d08b58456519bf471ba8c727745
When removing a CA Cert in TrustedCredentialsSettings the UI item
is now removed from the list of the respective profile only.
Bug: 17926190
Change-Id: I7f7ae3498717cc457cb9e360e59bb365225b0cb6
Use fixed category names (e.g. 'Personal' and 'Work') on Trusted Credentials
screen instead of names of profiles that may be the same (or similar) for both.
Bug: 17629895
Change-Id: I25b39310f7b9f445d2724be046a16cc82f5d1a9a
List adapter's getCount method did not check for the case of uninitialised
data. This CL fixes that.
Bug:17437943
Change-Id: I72d7f2c92aa380b1aaafe0658bd920017ff23906
Trusted credentials for both the primary user and its managed profiles are shown
on the Trusted Credentials fragment. All functionalities (e.g. disabling/enabling
of certificates) remain available.
Bug: 16029580
Change-Id: Id6335d12ec5fbeed0e254f3ded1e715def3e8e04
Fixed bug in WirelessSettings where it was asking users for a PIN when
they weren't restricted. Did this by refactoring the preference level
pin checking into the superclass, where it checks for the restricted mode first.
Also pin protected changes to certificates for restricted users.
Change-Id: I8310fd39f0862159668318fc1360ec6859cc00d5
