Based on some analysis, these fields/methods are likely false positives.
Set maxTargetSdk=P so that any apps using them are required to migrate off
them in future. See the bug for more details.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
For packages:
android.preference
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I31a80552a66554d876edd01950df368c31239c2b
The VOLUME_SETTINGS_INT contains more stream types, VOLUME_SETTINGS
also has the @removed tag.
Bug: 78806021
Change-Id: If01b3693e6507f1cd9c9f587b49f6a4e89a67439
doclava was accidentally suppressing all these broken links
in @see tags. This CL fixes issues so we can start enfocing
checks for broken @see links.
Test: make docs
Exempt-From-Owner-Approval: Fixing @see javadoc link issues that are currently completely broken
Change-Id: I767e9fb9842494e5eccef2a7bdeee3877c488b5d
When ViewGroup is dispatching touch events to children, it can
happen that a child, upon receiving a touch event, may decide
to close the window. In this case, dispatchDetachedFromWindow will be
called, which would invalidate (=recycle) the TouchTargets. As the
ViewGroup would continue dispatching the event to other children, those
TouchTargets would already no longer be valid. This could cause an NPE.
In one particular example, there could be several views in a Dialog, and
one of the views would dismiss the Dialog in a click handler.
Since the click handler executes events immediately, this makes
ViewGroup.dispatchTouchEvent recurse on itself, and modify the internal
state. This would later cause the NPE.
Calling dismiss in a message avoids this issue by letting the event
handling finish before dispatching dispatchDetachedFromWindow, which
would cause another ACTION_CANCEL to be sent to the view.
Bug: 26611563
Test: created a sample app and recorded a sequence of touch events using
inputstudio in order to reproduce the crash. The repro rate was 100%.
Could no longer repro with this change.
Change-Id: Ia1d8070152c7ba2d14cddebcc5844994fe3ab5da
- Added logic for streams to be muted by dnd (unassociated with ringer)
Test: runtest -x frameworks/base/services/tests/uiservicestests/src/com/android/server/notification/ZenModeHelperTest.java
Bug: 73362490
Change-Id: I1101e67282f7331497e91eb510d2bf4f1ea6b4b1
- if alarms and/or media cannot pass dnd and the phone is currently
in priority only dnd, then the alarm and/or media volume stream
will appear muted in the volume dialog and sound settings
(Settings > Sound)
- if all behavior for priority only dnd is not allowed to bypass dnd
(discluding alarms and media), then ringer is muted when priority-only
dnd mode is on. If a user clicks this ringer in the volume dialog, then
dnd ends
- Updated default zen config to version 3 (added alarms and media)
Test: manually toggle alarms + media in Settings > Sound > DND >
Behavior, toggle on/off dnd and then look at volume dialog and
volume bars in Settings > Sound
Test: runtest --path cts/tests/tests/media/src/android/media/cts/AudioManagerTest.java
Fixes: 72052742
Change-Id: Ia9e809ec2be93cb5a9ba6518dce04bf3ce45110b
Redirect developers to use the Support Library
versions of Fragments and Loaders to ensure that
they get consistent behavior across versions of
Android and all devices as well as access to
Lifecycle improvements.
Test: Confirmed APIs deprecated in current.txt
BUG: 68381801
Change-Id: I58ec599e557fc93c8547c45ba7c9ced96b0c8616
SeekBarVolumizer: do not use FLAG_BYPASS_INTERRUPTION_POLICY as
there is no need to bypass DnD modes in seek bar for volume
since they are disabled according to the DnD mode.
AudioService (PlaybackActivityMonitor): check both
AudioAttributes flags BYPASS_INTERRUPTION_POLICY and
BYPASS_MUTE for forced alarm playback (see b/63617557).
Test: see bug
Bug: 67578783
Change-Id: Iaf43f16d96d1ad8a1eacc73a050db767004ba96b
The flag to check whether the single line title attribute is initialized
only when we processed the layout attributes. When the attribute is not
set in the layout, but set through the setter method, the flag is not
being updated properly, and hence the title view is not set correctly.
Need to update the flag as well when the setter method is called.
Bug: 62947301
Test: manual
Change-Id: If843663165a0f3348048aaf1d920f3b740af5bc3
Only call setSingleLine() on the preference title if the attribute is
set.
Bug: 37328004
Test: manual
Change-Id: Ia95230cd08feaf8213cb5917c105d070eb30c11c
Add an attribute to Preference to specify whether the space of the icon
view should be reserved when no preference icon is provided.
Bug: 36448695
Test: manual
Change-Id: I03b49fe93d54bb9106cf167a677a9ea544a3e3a1
Add an attribute to Preference to specify whether single line is to
be used for the preference
Change-Id: I578b496cdc4c5b0e3b3146183c6c30c4dee02eab
Fix: 36389770
Test: manual
There is also change in PreferenceManager.getSharedPreferences. The
original was not always returning null in case mPreferenceDataStore is
not null. That was contradictory with the java doc and conufing during
the runtime. Added tests for it.
Test: Separate CTS (2) being submitted along this one, see the topic.
Bug: b/34322039
Change-Id: I78a6758a674c3c8139bbe66ec17f2e29ca847828
Until now we have been recycling only framework preference widgets since
there were no guarantees for third party preferences to support recycling.
This let to broken animations for preference widgets that are outside of
the framework.
This change makes recycling to be used always and in case the developers
need to turn it off they can explicitely use a new attribute that is
being added to the Preference called "recycleEnabled" and set it to false.
Bug: b/34334451
Test: Test are part of the same topic.
Change-Id: I324087841e1edddbf0d3eaad00b5895a196acff6
Bug: b/35977048
Test: Done manually. Automated test will be added later.
After recent changes in PreferenceActivity finishing the activity on
pressing back is not correct anymore. Instead onBackButton method should
be called to deal with it (we have fragments transactions for instance).
There can be multiple buttons:
1. The native default one - calls onBackPressed by default so no extra work
needed.
2. PreferenceActivity has buttons that can de displayed when settting
EXTRA_PREFS_SHOW_BUTTON_BAR to true. But it is a private API and I
didn't find any usage of it, so there is no need to change that. Also
it looks like something very specific used in WiFi wizards.
3. Apps often use a toolbar that has a home button which essentialy
emulates back button. The issue is that this Activity never had support
for this. So apps had to override onOptionsItemSelected and some of
those are unfortunately calling finish() which worked previously when
PreferenceActivity wasn't using fragments in single pane. This CL adds
support so app will no longer need to override that method and some
apps need to be instructed to use that override in O.
Change-Id: I94f557edb2e03f89fbf02e800beb390b2ad0544f
I have done some important cleanup of java docs where it wasn't clear
enough that there is a PreferenceDataStore option.
I have fixed incorrect behavior when setting default value while data
store is assigned. Previsouly we looked into SharedPreferences which is
incorrect.
I have also changed behavior of methods getSharedPreferences and
getEditor. These methods now return null when custom data store is
assigned. The reason is that we definetly don't want to use
SharedPreferences if data store is assigned. So the original behavior
was a bit ambiguous. Also if we didn't enforce it, we would have
troubles to change that in the future.
Test: Tests are under the same topic.
Change-Id: Ib7303bae13648767c519edba74ef9a7143e703df
These were never part of any public API level, so apps should never
have been using them.
Test: builds, boots
Bug: 31241513
Change-Id: I4fc8f5c325da56694a5db98acc995a22d4947805
When navigating from a preference panel back to the headers in single pane,
the title was not restored and the original one (of the previous
preference panel) was kept instead.
Bug: b/35468759
Test: Is covered in ag/1761868
Change-Id: I30cc4c1d2a53d05411cc849ce8423b694c76976a
Transitions in and out of multi-window were causing navigation history
losses + incorrect views to be displayed. The history loss was caused by
the fact that single-pane mode was using Activities but multi-pane mode
was using Fragments. Translating history between those two would be
challenging. Because of that Fragment approach was also applied to
single-pane mode. That required some changes in back press handling and
initial logic when creating the PreferenceActivity.
Test: Separate CTS CL being submitted along this one, see the topic.
Bug: 32201932
Change-Id: I5e6a6a21c34e813d1c3522ae7f5e33f43887c602
Preference class now keeps track of its PreferenceGroup parent which
makes it easier to remove it from the preference hierarchy.
This required a new API method.
Test: Separate CTS CL being submitted along this one, see the topic.
BUG: 30599046
Change-Id: Ia9f274ef0315cb09a8c558e781b10f57efd28406
Developers will be able to use PreferenceDataStore to replace default
SharedPreferences to store / retrieve the data.
Test: Separate CTS CL being submitted along this one, see the topic.
Change-Id: Ie46a876dcb14b46b8b2584735c106c25655ec6cf
Preferences lack a title on watch type devices due to lack of ActionBar
support. A custom ListView was added to use a custom wrapper adapter to
add a persistent header view at the top of the ListView that developers
would not be able to remove via the ListView API.
Bug: 27962897
Change-Id: I6bccecf85592d9507e0c7a04c9a035617001e9ef
Symptom:
1. Set Alarm volume to 0 on Sound & notification screen, then tap
Back key and reopen the screen.
2. Set Alarm volume up to 1 or larger, then alarm icon changes to
unmute.
3. Set Alarm volume down to 0, then the icon doesn't change to
mute. There expected the icon should change to mute one.
Detail and sample:
SeekBarVolumizer manages a variable mLastAudibleStreamVolume.
This variable decides whether it executes mute procedure or not.
When this variable is 0, it will not execute mute procedure.
Because the condition to execute mute proceduce is below.
- lastAudibleVolume * (mute ? -1 : 1) < 0
What original code will not update this variable from constructor
is one of problems. So once the icon changes to unmute one,
the icon will never change to mute one.
Solution:
Changed the condition as it doesn't depend on value of
lastAudibleVolume.
Bug: 30265487
Change-Id: I42165f39d1f344169674c09a045b6fb2bb25db4d
