The VolumeGroup callback was initializing the sliders by querying
the VolumeGroup API, which talks to APM. In AVCRP with a
BT headset that supports absolute volume, the APM only sees the
media volume at max, as no digital attenuation is applied then,
which causes the VolumeGroup API to report max volume.
The fix consists in using the updateSlider() method instead, which
will cause the volume query to go through AudioService (which
maintains the actual volume setting independently of the digital
attenuation that is applied).
Bug: 132287865
Test: connect BT headset with abs volume, go to Settings > Sound
Change-Id: I3d46af69d808169806c86cb543440f262097965b
- Removed AudioProductStrategies and updated usages to work with
List<AudioProductStrategy>
- ditributed looping logic to the respective callers
Test: built successfully with make and ran on device
Bug: 129265140
Change-Id: If95ba9c2418a1fda29590ca1af2d04e7395c2130
In order to prevent misalignement between hard-coded stream aliases,
this CL allows to use the Volume Group cb to update the SeekBarVolume.
The ultimate step would be to remove stream aliases from audioserver.
Bug: 124767636
Test: dumpsys media.audio_policy
Change-Id: Ide99e9dd97669e880d0d253102533c72070012a1
Signed-off-by: François Gaffie <francois.gaffie@renault.com>
Fixes: 118534516
This reverts commit d7e9d35a44.
Reason for revert: Users can adjust volume from volume slice without preview sound, so re-enable preview sound in Settings > Sound
Change-Id: I009d4a915a900e74bdcf14fb6dabad2e4a497a82
For packages:
android.companion
android.filterfw
android.hardware.camera2.utils
android.inputmethodservice
android.net.nsd
android.os
android.preference
android.security.keymaster
android.service.dreams
android.telecom
android.telephony.ims.compat.feature
android.telephony
android.util
android.view.accessibility
android.media.effect
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: I9c2f8347952f3cc65759472b0e1a2717b285e44e
Since getDecorView may return null when dialog's window is no longer
present, annotate it as @Nullable.
Bug: 124327419
Test: none
Change-Id: I0d49b75b14f54cd8ba8304c900f6c8625f889aa8
Protect against crash surfaced by monkey, where it seems that the window
of the dialog is no longer present. If not present, don't need to post
dismiss runnable.
Bug: 124327419
Test: adb shell monkey -p com.google.android.GoogleCamera -s 999 -v 20000
Change-Id: Ic03b8501bb73725e04544fcb2397532be531988e
If they were null, then the Parcelable would fail to work.
Bug: 126726802
Test: manual
Change-Id: I7929ffa2f20e5de1c8e68e8263cca99496e9d014
Exempt-From-Owner-Approval: Trivial API annotations
- Check consolidated zen policy in volume dialog, seek bar volumizer
and ZenModeControllerImpl instead of default notification policy
- Save ZenPolicy changes on restore
Test: atest ZenModeHelperTest
Test: atest ZenModeControllerImplTest
Bug: 111475013
Change-Id: I43b6dc8c6453739c50c874fe37415d425223d8c4
The AndroidX Preference Library is the recommended way to build settings
screens moving forward.
Bug: b/114357488
Test: n/a
Change-Id: I3b3bff2daf43d8239d8bf247a9c2acebbc6374eb
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
Merged-In: I719b5c94e5b1f4fa562dd5d655953422958ad37e
Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
(cherry picked from commit 8c854f86a4)
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
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
Merged-In: Ia1d8070152c7ba2d14cddebcc5844994fe3ab5da
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: I6a39e2a1e1eb65cde9d200fb794c6592982f1272
Merged-In: I31a80552a66554d876edd01950df368c31239c2b
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
