Secret keys are not longer identifiable by their alias prefix.
So now we call getKeyCharacteristics and check the algorithm of the
key.
Bug: 63931634
Test: Manually installed a key and checked that it is still dispayed
correctly.
Change-Id: I55a4e46434618cb52ceb9456f184e004165872fd
- 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
Less obviously easy than it looks because we want to make it a
SettingsPreferenceFragment for consistency with the other blank
fragment implementations.
Fix: 30878596
Test: make RunSettingsRoboTests
Test: # open up Settings and have a look, uninstall cert, reinstall cert
Change-Id: Ifbe3132475c3104d76589a50dec3f436b9548585
Bug: 33126414
Test: Enable new authentication flow; go to user credentials in Settings
observe no entries related to user authentication are shown.
Change-Id: I62e5796cc73213b23ca7809a77082350a883fbee
Bug: 30681771
Test: SettingsUnitTests
Refactor visibility logging from InstrumentedFragment into a mixin. And
apply mixin in remaining fragments.
Change-Id: Ibbb59904336254a3e4bb9e8c7d0b36e5a6bc2622
Deleting wifi certificates isn't supported yet since cascading the
removal back into wifi configs will need some easy way of enumerating
wifi configs first.
Bug: 29208062
Change-Id: I2d9d1ea7e0974701009bfa6ea162b8bc80806639
All settings preferences related to credentials of any kind should be
stopped by this user restriction.
Bug: 26879958
Change-Id: I983c6e58081bd4022bb006942499cba4b74954e7
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
Credentials is a bit too low-level. KeyChain will call into the same API
but also arrange deletion of grants, send out STORAGE_CHANGED broadcast
and anything else that might be needed in future.
Bug: 27335182
Change-Id: I764ffa3c5539ddec2b9a776bd3fec6a78a043248
Unit test to verify that the internal Credential that gets passed to
dialogs for removing said credential is actually a valid Parcelable
object, since it's hard to provoke a marshal/unmarshal in real-world
usage (but not impossible).
Bug: 22541933
Change-Id: I780ca2d7b01fc6081b9ea8b2810cfc97f0433a86
This makes removing a particular keyset possible without deleting the
whole keystore along with it.
Bug: 22541933
Change-Id: I248803cb27efdd1695438dfc82951887dc579f99
