On 21/10/2024 21:32, Luiz Augusto von Dentz wrote:
Hi Bartosz,
On Wed, Oct 9, 2024 at 3:36 PM Bartosz Fabianowski
<bartosz@xxxxxxxxxxxxxx> wrote:
On 09/10/2024 12:30, Marijn Suijten wrote:
On 2024-10-07 11:56:06, Luiz Augusto von Dentz wrote:
Hi Marijn,
<snip>
diff --git a/src/main.conf b/src/main.conf
index fff13ed2f..b6b32a720 100644
--- a/src/main.conf
+++ b/src/main.conf
@@ -316,6 +316,15 @@
# notifications.
#VolumeCategory = true
+# Require peer AVRCP controllers to have at least version 1.4 before
+# accessing category-2 (absolute volume) features (depending on the value
+# of VolumeCategory above). It is common for Android-powered devices to not
+# signal the desired minimum version of 1.4 while still supporting absolute
+# volume based on the feature category bit, as mentioned in this comment:
+# https://android.googlesource.com/platform/system/bt/+/android-12.0.0_r1/bta/
+# av/bta_av_main.cc#621
+#VolumeVersion = false
I'd change this to have the version e.g. #VolumeVersion = 1.4, so the
user can switch to 1.3 or "any" in case he want to bypass version
checking
We can surely change this to parse a version which would override the version
of the remote CT, and rename it to CTVersion since it's no longer only affecting
volume? Maybe add a TGVersion as well, and/or something else entirely?
That would save the ugly combinatorial explosion. Maybe the same works for
VolumeCategory introduced in the previous patch as well?
also perhaps we should create an issue for Android folks to
fix their version, as it seems they do support browsing features
channel for TG they should be able to do the same for CT.
I don't think this patch aged particularly well as hinted by the testing
steps in the cover letter: on my Android 14 phone AVRCP 1.5 is the default in
developer settings, so they might have realized that this was a problem in the
past. Don't think we need to report it anymore, and we should perhaps start
discussing whether this patch is still desired in the first place? Either way
I'd appreciate to land the first and second patch.
Even if current Android versions report AVRCP 1.5, there will be a lot
of phones stuck on older versions for many years to come. Compatibility
with these should still be very desirable.
They didn't bother backporting it? I wonder if we could somehow detect
this behavior based on the Android version if that is available
somewhere.
Looks like Android 14 and newer report AVRCP 1.5. Android 13 (which was
released two years ago and is still on many phones) still uses AVRCP 1.3.
- Bartosz
- Marijn
+
[Policy]
#
# The ReconnectUUIDs defines the set of remote services that should try
--
2.46.2
--
Luiz Augusto von Dentz
