We call updateAllPreferences in onCreate and onResume. If we always call
the method in onResume, the call in onCreate seemed redundant.
Bug: 327052480
Flag: EXEMPT low risk bugfix
Test: manual (able to see the accessibility screen as before)
Test: atest com.android.settings.accessibility
Change-Id: I40b44ed6b667f7b1375ec0e339fc2b28a3f70dc5
* In Android V, we can add qs as one of the accessibility shortcut option to be more discoverable.
Bug: 338327560
Flag: EXEMPT bugfix
Test: check shortcut option in hearing devices settings page
Change-Id: I60d4da2432605a5369eb87c1e594539d40c53ae8
AccessibilityShortcutsTutorial.
**Root cause**
When toggle the shortcut, it asks the AccessibilityManager to turn on
the shortcut and update the Settings data. Internally, the
AccessibilityManager delegate the work to AccessibilityManagerService
via a oneway binder call.
In the past, when launching the AccessibilityShortcutsTutorial, we
assume the shortcut selection are saved in the Settings before launching
the AccessibilityShortcutsTutorial. So we pass whatever are in the
Settings as what the user has selected to the tutorial.
This is not true anymore since we use the oneway AIDL call to do the
updates. The data in Settings may not yet be updated before we use it to
launch the tutorial.
Since the user preferred shortcuts are always set before we attempt to
launch the AccessibilityShortcutsTutorial, we can rely on it instead of
the Settings value to launch the AccessibilityShortcutsTutorial for the
selected shortcut options.
**Changes in this cl**
- Mechanical refactor to extract the lines to get the user preferred
shortcut into a method.
- Use the new method to grab the shortcut options to pass to the
AccessibilityShortcutsTutorial to prevent the crash.
Bug: 341176890
Test: manual
- Modify the AccessibilityManagerService locally to delay processing
the request to update the shortcut options in Settings data
- Turn on the shortcut toggle, and verify the app won't crash
Test: atest com.android.settings.accessibility
Flag: EXEMPT bugfix (low risk + mechanical refactor)
Change-Id: Id3cc4cc5f6667061545955881632544472aedd95
The bug-fix flag is already soaking in trunkfood full stage for a while.
Since there is no coming issues related to the fix, we can apply the fix
and remove the flag usage.
Bug: 341203230
Flag: NONE
Test: manually
atest MagnificationAlwaysOnPreferenceControllerTest
Change-Id: I7e6ef8e03e7b7291d2faa15351669a91a50f59a5
Although we haven't implemented joystick feature, but the joystick
preference controller is already in the codebase, so we also add hiding
logic for joystick toggle when in setup wizard.
Bug: 340721852
Flag: NONE
Test: manually
atest MagnificationJoystickPreferenceControllerTest
Change-Id: Ife93548583c3e82eac030e6e3aa55b9f643b055a
Originally we cache mFollowingTypingSwitchPreference in fragment so in
ToggleScreenMagnificationPreferenceFragmentForSetupWizard we can set the
preference visible to false to hide it. After creating MagnificationFeaturePreferenceController,
the MagnificationFollowTypingPreferenceController can extend it and
check isInSetupWizard internally then dicide whether to hide. Therefore,
we don't need to cache mFollowingTypingSwitchPreference in fragment
and let the fragment control the preference visibility anymore.
Bug: 340721852
Flag: NONE
Test: manually
atest MagnificationFollowTypingPreferenceControllerTest
atest ToggleScreenMagnificationPreferenceFragmentForSetupWizardTest
atest ToggleScreenMagnificationPreferenceFragmentTest
Change-Id: I44f7f0589b2df3d83a27139323fc68a0561f1cfa
Add a new abstract class MagnificationFeaturePreferenceController
that extends TogglePreferenceController, to wrap inSetupWizard
setter/getter. Then for magnification feature preference controllers
like alwaysOn or followTyping, they can just check isInSetupWizard to
decide whether hiding in setup wizard.
Besides, in ToggleScreenMagnificationPreferenceFragment we cache a flag
mInSetupWizard when fragment created, so we can pass the info to the
preferece controllers when creating them.
Bug: 340721852
Flag: NONE
Test: build pass
Change-Id: I05c59a766219862117d2a6ede775d68a4c3dedac
Add brightness level and auto brightness preference in
accessibility_settings_for_setup_wizard.xml. Since the flagging has not
be supported yet for non-Manifest resources, for now we add the
preferences by default, and update the preferece availablity status in
each preference controllers based on the flag.
Bug: 311093618
Flag: ACONFIG com.android.settings.accessibility.add_brightness_settings_in_suw DEVELOPMENT
Test: manually
atest AccessibilitySettingsForSetupWizardTest
atest AutoBrightnessPreferenceFragmentForSetupWizardTest
atest AutoBrightnessPreferenceControllerTest
atest BrightnessLevelPreferenceControllerTest
Change-Id: I350d99138bdd14bf28828a39e42f707b5b1066c1
VoiceAccess doesn't support the 16KB mode yet. Skipping
voice accesss service when in page-agnostic mode.
Test: m Settings && adb install -r $ANDROID_PRODUCT_OUT/system_ext/priv-app/Settings/Settings.apk
Bug: 335443194
Bug: 340231742
Change-Id: If4deae48aaa221c843af5eb65208659ad38a08b2
Updating owners file in settings/accessibility to make the haptics team owners on the vibration files in Settings.
No flag for changing owners, no UI changes.
Fix: 339187294
Test: N/A
Change-Id: I962040b509f40393101eadc76ca46afc2b0696ef
The SettingsMainSwitchPreferenceController might trigger a state change
twice on the page main switch when the user toggles the setting value.
Make sure we only trigger haptic feedback when the state is changing
between untoggled to toggled to avoid a double-click feedback.
No flag for small bug fix, no UI changes.
Fix: 338334977
Test: enable the "Use vibration & haptics" settings and feel a single
click feedback
Change-Id: I0c22b99bcb40f35ebe09c153133c354306ed1ff0
Per discussion with leads, we'd like to ensure that Settings > Accessibility changes are seen
and approved by the Android Accessibility team. This change prevents default Settings owners
from accidentally approving changes without looping in a11y, while ensuring Settings lead cipson
has approval for emergency changes.
Change-Id: I914067a4d2616c212309b70fb29679f9acfa7643
In ag/26349366 we wrapped the follow typing prefernce creation into new
method, but in the new method we didn't assign the created preference to
mFollowingTypingSwitchPreference. So
ToggleScreenMagnificationPreferenceFragmentForSetupWizard can not access
the preference object to hide it. Therefore, as a short-term solution we
assign the created preference to mFollowingTypingSwitchPreference. For a
long-term plan we should not create a preference and hide it in suw,
instead we don't need to create that preference. (tracked in b/335788167)
Bug: 335788769
Flag: NONE
Test: manually
Change-Id: Ideef93127343b7d1105a63006d343cd5ef66de08
PackageInstaller has protected the intent action by setting
"android:priority=1".
Test: manual
Fix: 332228634
Change-Id: If0794e5957366d8b26acd0362b59c6c9076a0c4f
Like MagnificationAlwaysOn toggle behavior, when the magnification
capability is window-mode only we'll hide the OneFingerPan toggle too.
Also do a small refactoring in MagnificationOneFingerPanningPreferenceControllerTest
Bug: 333821725
Flag: ACONFIG com.android.server.accessibility.enable_magnification_one_finger_panning_gesture TEAMFOOD
Test: manually
atest MagnificationOneFingerPanningPreferenceControllerTest
atest ToggleScreenMagnificationPreferenceFragmentTest
Change-Id: I8684b5bae5cbfc5b75fc4c14d2e9173b17d0fb02
This bug fix associated with this flag is low risk. The flag has been
soaked in the Trunkfood full for 30 days and tested by 1000+ users.
Based on the flag cleanup policy, we can clean up the flag.
Bug: 289967175
Flag: EXEMPT flag cleanup
Test: Run the Settings app and can still see the vibration & haptics
screen
Change-Id: I39890a33f04b53565461ae2c6c4e63b94f205e6d
Like the screenshots in b/323771329#comment26, the headerLayout padding is too large when
force-two-pane mode. Therefore, as a short-term fix, we make the AccessibilitySetupWizardUtils
not to adjust the headerLayout padding when shouldForceTwoPane, which
described in b/323771329#comment30. The long-term goal is to remove the
padding adjustment in AccessibilitySetupWizardUtils after the the
padding is handled in SUW library internally.
Bug: 323771329
Flag: NONE
Test: manually
Change-Id: Ie4585d9ee352ca74733d4bc14e957bf901347fdc
This bug fix associated with this flag is low risk. The flag has been
soaked in the Trunkfood full for 30 days and tested by 1000+ users.
Based on the flag cleanup policy, we can clean up the flag.
Bug: 307481249
Flag: EXEMPT flag cleanup
Test: Run the Settings app and can still see the text reading preview
Change-Id: I59e03da1719041fb2d17da1d1eed555f31c3d81d
This bug-fixing flag has been in Trunkfood in two months.
Test: existing presubmit (no functional change)
Bug: 294560581
Change-Id: I05282f1f7ee6b1bb4e4bf873771d80ae68204b4c
