Test Setup:
===========
HW DUT: Pixel O
Remote: MecApp (PBAP Client, MAP Client, SAP Client)
Steps:
=====
1. Enable BT on DUT and bond with Remote.
2. Connect from MecApp for PBAP, MAP, SAP and observe if
connection goes through fine.
Reproducibility:
===============
5/5
Observation:
============
MAP, PBAP and SAP cannot be connected.
Root cause:
In Android O, notifications are hidden by default.
This must be changed to use notification channels so that the
priority of the notifications can be updated.
Test: PBAP/MAP/SAP connection works fine with MecApp.
Bug: 38331825
Change-Id: I51de0ea303037bf88773352d99f092673acda2e3
(cherry picked from commit bd9f532013f0397879101f68f21ac8841fec344b)
Test: There's a condition where FP enrollment fails and a fragment
transaction/commit occurs after onSaveInstanceState. We should be
using commitAllowingStateLoss() instead of commit()
I'm not able to repro this issue but from looking at the stack
trace this should fix the problem.
Fixes: 38432354
Change-Id: I56b9c8d2efc45e9d77f29b897280f5378c3a84a0
This more closely reflects the idea that the top level setting title
should match the actual screen title.
Change-Id: Ie7ab1756d799c182cad74041995768037bba710f
Fixes: 37923462
Test: Manual
Change the keys in the Language and Input screen for the
gesture and tts-output settings so they can be disabled
in search. Then change the preference controllers to take
a key as input to avoid crashes on the other screens with
these settings.
Test: make RunSettingsRoboTests
Bug: 33701673
Change-Id: Ifeb2a2d34a3efded3f0a9ba02ac76fd6f8ffd087
Merged-In: I8bc0776131fcac5a6edf7e8271bc53252c2fc719
This happens when user has different accounts with same account name. For
example: user@domain.com for type1 and same email for type2, etc. When
we refresh the account list during onResume(), the same account name
incorrectly causes the logic to think they are the same account and
updates the account list by mistake.
- Introduced a util method to generate unique key from Account object.
And set it as preference key.
- when updating preference on screen, use key to find preference instead
of the preference instance itself.
Change-Id: I0aa692cb965b7037155a746389a919cd155843da
Fix: 34035653
Test: make RunSettingsRoboTests
Default UserManager caches instance across entire test suite, so
test becomes flakey depending on the order they are run. Using a
a ShadowUserManager without the cache ensures each test class gets
a UserManager with clean state.
Change-Id: Ia54f6a3259859add5a1e5d0101829497fb985ab1
Fix: 38393235
Test: make RunSettingsRoboTests
Don't show managed profile version of shortcut
picker as it lunaches same activities as personal
one.
Test: manual - check badged shortcut isn't present in launcher.
Bug: 38333213
Change-Id: Iade6595255524a8dbf223a70a6c8312087258c23
Test: make ROBOTEST_FILTER=TelephonyMonitorPreferenceControllerTest
RunSettingsRoboTests -j40
Use enable, disable, user_enable, user_disable four statuses to
replace the old boolean value,
Bug:36704500
Change-Id: I5d3fd36aecaf36bb6969a6f6354c85bb162a0293
When strong auth (PIN, password, or pattern) is removed from a user,
fingerprints enrolled for that user should also be removed. Then, if the
user has a work profile guarded by a unified work challenge, the work
profile's fingerprints should also be removed.
Previously, when removing the fingerprints of the current user,
ChooseLockGeneric checked the finger id of the onRemovalSucceeded() and
onRemovalError() callbacks, and assumed the removal had completed when
the id was 0. Only after this would it initiate the removal of work
profile fingerprints, if any.
However, the finger id is actually non-zero even for the user's last
fingerprint. This means the work profile fingerprints (under unified
challenge) were never removed. Another more visible symptom was that
when the user removed the device lock by choosing "None" or "Swipe" in
ChooseLockGeneric, the activity failed to exit, since finish() is called
only at the end of the removal flow which was not executed.
In this CL, we check the number of remaining fingerprints instead of
relying on the finger id, thus allowing the removal flow to complete and
the activity to finish().
Bug: 37938345
Test: manual, both with and without work profile
Test: make SettingsRoboTests
Change-Id: Ic04fd01177ad6d4a061023a4b6889af585f8f2b7
