IssueTracker

Running into a similar issue, any update on this?

This is a platform behavior change.

b/236862874 is related.

Any progress?

Thanks for the comment#1 report. The bug in how those older versions of the framework dispatch insets does make handling insets difficult. It's on our roadmap for early 2025 to prepare an AndroidX-side workaround.

This issue is also stopping us from being able to support edge-to-edge in Android 15. Given it's a enforced requirement for targeting Android 15, couldn't this be prioritised higher? Companies like us have hundreds of screens to fix so waiting until 2025 for a workaround is going to be tough work.

Maybe you can create a static method, com.your.company.ViewGroupCompat#installCompatInsetsDispatch, like this: https://android-review.googlesource.com/c/platform/frameworks/support/+/3310617/2/core/core/src/main/java/androidx/core/view/ViewGroupCompat.java ?

After creating the method, you need to call ViewGroupCompat.installCompatInsetsDispatch(getWindow().getDecorView()) in onCreate() of your activity to make the behavior compatible with API 30+.

When the new library with the API is released, you can replace com.your.company.ViewGroupCompat with androidx.core.view.ViewGroupCompat.

Wow quick response, thanks! I just tried applying that workaround to our root view and can confirm it fixes the issue. (Also FYI there's a typo in the PR; "comsumed")

I'm getting a crash when using new version of ktx-core 1.16.0-alpha01 with fixed ViewCompat and ViewGroupCompat on API < 30. This is related to FragmentContainerView:

java.lang.NullPointerException: Parameter specified as non-null is null: method androidx.fragment.app.FragmentContainerView.setOnApplyWindowInsetsListener, parameter listener
	at androidx.fragment.app.FragmentContainerView.setOnApplyWindowInsetsListener(Unknown Source:2)
	at androidx.core.view.ViewGroupCompat.dispatchApplyWindowInsets(ViewGroupCompat.java:255)
	at androidx.core.view.ViewGroupCompat.dispatchApplyWindowInsets(ViewGroupCompat.java:264)
	at androidx.core.view.ViewGroupCompat.dispatchApplyWindowInsets(ViewGroupCompat.java:264)
	at androidx.core.view.ViewGroupCompat.dispatchApplyWindowInsets(ViewGroupCompat.java:264)
	at androidx.core.view.ViewGroupCompat.dispatchApplyWindowInsets(ViewGroupCompat.java:264)
	at androidx.core.view.ViewGroupCompat.dispatchApplyWindowInsets(ViewGroupCompat.java:264)
	at androidx.core.view.ViewGroupCompat.dispatchApplyWindowInsets(ViewGroupCompat.java:264)
	at androidx.core.view.ViewGroupCompat.lambda$installCompatInsetsDispatch$0(ViewGroupCompat.java:218)
	at androidx.core.view.ViewGroupCompat$$ExternalSyntheticLambda1.onApplyWindowInsets(D8$$SyntheticClass:0)
	at android.view.View.dispatchApplyWindowInsets(View.java:10499)
	at android.view.ViewGroup.dispatchApplyWindowInsets(ViewGroup.java:7191)
	at android.view.ViewRootImpl.dispatchApplyInsets(ViewRootImpl.java:1925)
	at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2030)
	at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1721)
	at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:7598)
	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:966)
	at android.view.Choreographer.doCallbacks(Choreographer.java:790)
	at android.view.Choreographer.doFrame(Choreographer.java:725)
	at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:951)
	at android.os.Handler.handleCallback(Handler.java:883)
	at android.os.Handler.dispatchMessage(Handler.java:100)
	at android.os.Looper.loop(Looper.java:214)
	at android.app.ActivityThread.main(ActivityThread.java:7356)
                                                                                                    	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)

Re comment#13:

I think the @NonNull annotation of androidx.fragment.app.FragmentContainerView.setOnApplyWindowInsetsListener has been removed since If694a3b70bf84f03c95d67d20e58485135ab7d86 which has been included since androidx.fragment 1.4.0-alpha09.

Do you mind upgrading your androidx.fragment version to 1.4.0-alpha09 or above? The latest version is 1.8.5.

This bug has been fixed by I111590881991b94e5cd5f2100bf88dd4468bc781 since core#1.16.0-alpha01. Let's mark it as fixed.

See: https://developer.android.com/jetpack/androidx/releases/core#1.16.0-alpha01

I'm sure I was using the latest androidx.fragment 1.8.5. It can be reproduced here, could you check it?

Ah, you are right. It still requires a non-null object since the required type is not OnApplyWindowInsetsListener? but OnApplyWindowInsetsListener.

    public override fun setOnApplyWindowInsetsListener(listener: OnApplyWindowInsetsListener) {
        applyWindowInsetsListener = listener
    }

Hi Jeremy,

Do you mind checking why androidx.fragment.app.FragmentContainerView.setOnApplyWindowInsetsListener requires a non-null parameter? The restriction was added in this CL.

Project: platform/frameworks/support
Branch: androidx-main
Author: Jeremy Woods <jbwoods@google.com>
Link:      https://android-review.googlesource.com/3443279

Change the nullability of setOnApplyWindowInsetsListener

Change the nullability of setOnApplyWindowInsetsListener 
 
Since setOnApplyWindowInsetsListener overrides a method from the View 
class which is in java and has no nullability, we did not know the 
proper nullability. 
 
It seems there are cases when the inset listener could indeed be null, 
so we can make that nullable now. 
 
RelNote: "FragmentContainerView's `setOnApplyWindowInsetsListener` 
override now takes a null listener." 
Test: All tests pass 
Bug: 282790626 
 
Change-Id: I575f0b5da72d096b14393afd9819ab66e061b002

Hey Tiger,

I made it nullable again. We will release this in the next couple of weeks or so.

Thank you Jeremy.

Since comment#13 is an issue different from comment#1, and it will be fixed by a new version of androidx.core as mentioned at comment#19, let's close this issue for now.

If the issue mentioned at comment#13 still happens, please feel free to file a new bug for it.

Any update on this to fix the crashing? Also does this new API will also fix the callback not being triggered after configuration change (orientation) for Android Tablet running on Android 21? We noticed another fragmented behavior between phone at tablet size devices where the setOnApplyWindowInsetsListener callback is not being triggered in Fragments after configuration change.

Activity (callback is being triggered on both phone and tablet after configuration change)

            ViewCompat.setOnApplyWindowInsetsListener(root) { _: View, insets: WindowInsetsCompat ->
                
                // Return WindowInsetsCompat.CONSUMED if you don't want the window insets to keep passing down
                // to descendant views including all views of Fragment(s) under this Activity
                insets
            }

Fragment with Jetpack Navigation (callback is being triggered regardless of Android version on phone size device after configuration change, but not on tablet running on Android 21)

            ViewCompat.setOnApplyWindowInsetsListener(root) { _: View, insets: WindowInsetsCompat ->
                
                // Return WindowInsetsCompat.CONSUMED if you don't want the window insets to keep passing down
                // to descendant views including all views of Fragment(s) under this Activity
                WindowInsetsCompat.CONSUMED
            }

Also hoping this to get fixed by this new API.

Any chance this issue gets higher priority? It's a shame that Google is forcing developers to migrate to Android 15 and setup edge-to-edge while still having critical compatibility issues with older Android versions even in apps with relatively modern stack (Fragment + Compose)

Hi Jeremy,

Do you have any update about the new release?

Build cut is this Wednesday and it will be released next week as part of Fragment 1.8.6.

OMG! Why is updatePadding API removed from Core KTX 1.16.0-beta01? It is the recommended approach to update padding in the docs. Its removal was not even mentioned in the release note and where did the ViewGroupCompat.installCompatInsetsDispatch(rootView) go? What is happening in the Android API?

Re comment#27:

Which library do you mean? If you mean fragment, I think you can find it here: https://developer.android.com/jetpack/androidx/releases/fragment#1.8.6

a short term fix while you are looking for a better solution?

I'll talk about it on our weekly meeting on Tuesday.

dm...@gmail.com this is a complex project and it's not an easy job to keep it bug-free. I clearly see it's improving and onboarding more features. I also have a chance to work with Xcode and believe me - Android studio is way way better than apple's product - refactoring, hotkeys out of the box, WYSIWIG and overall performance are just a few areas with a big difference

I found a TODO: Be able to disable audio input/output separately but so far I can't figure out how to pass a runtime value into the sound card init functions (goldfish_audio_realize, hda_audio_setup).

I figured out how to pass runtime values into virtio-snd and hda-duplex, we should be able to avoid opening the microphone in those devices. When I tried the same with goldfish_audio, the QEMU says -device goldfish_audio,debug=42: Parameter 'driver' expects pluggable device type. We probably want to retire (not sure if we can just disable it) this device instead of hacking it further.

I merged a change to disable the microphone in Intel HDA and virtio-snd. Not sure how we can disable it goldfish_sound in a proper way. We probably want to disable it unconditionally.

"Sounds like" (pun intended) a very good improvement! BTW: What decides which audio driver to use (I mean with which logic virtio-snd or hda-duplex or goldfish_audio is used) ?

What decides which audio driver to use?

virtio-snd is a drop-in replacement for Intel HDA, but the linux driver is required. If the system image says it has the driver, then we use the virtio-snd device, otherwise we use some ancient magic to decide between Intel HDA and goldfish_audio.

if this fix will apply to me (I'm using an M1 mac) and

Yes, it will apply for Apple M1.

when the fix will go out?

I still need to figure out what to do with goldfish_audio if our leads will not buy my change to disable the microphone permanently on goldfish_audio. One everything is merged, we should release the changes into the canary channel in weeks.

Cool thanks!

If the system image says it has the driver, then we use the virtio-snd device

Do you know from which API do system images ship with the linux virtio driver?

T is the first system image with virtio-snd drivers.

Super! To sum it up: with any emu image with at least api26 the mic will obey the hw.audioInput setting in the .ini file otherwise (for older emu images) the mic will always be disabled. Correct?

Unfortunately we create the goldfish_audio device unconditionally, it is not even a sound card from the qemu point of view, it just happens to call the audio API. I disabled the microphone in goldfish_audio here, so old API levels on ARM will not have a microphone until we figure out a better approach.

All changes are merged and available in the 8513367 emulator build. I checked our system images, on x86 the microphone issue should be fixed on API23 and later, on arm ones - API29 and later. We will see if we can fix our older arm system images (API28 and older).

To disable the microphone you want to add hw.audioInput=no to config.ini in the AVD folder.

Following along from #43, I figured I should mention I recently opensourced the tool I built to quickly enable and disable the hw.audio* (and other) settings on the various emulators I use for day to day development: https://github.com/morris86/avdedit

A checkbox just makes life a bit easier than constantly going in and hand editing .ini files.

Thanks for your work on this ticket and #37095756 over the last couple of years, appreciate it.

All changes are merged and available in the 8513367 emulator build.

Is this build downloadable somewhere?

Is there a target version in which we can expect this fix to land in (I'm currently using emulator v 31.3.2)?

Is this build downloadable somewhere?

While there is nothing secret there, I am not sure how to share it with you until we release the usual way.

Is there a target version

I don't know yet. Our emulator version is something like 31.3.7-8408431, the build number is after the dash.

Thank you, I was able to access a build and I could verify on my machine that the issue has been resolved. thank you very much everyone again for listening to our comments until here!

Hello, emulator 31.3.8 build 8598121 just landed in the canary channel. Can you please check if it includes this fix? Writing hw.audioInput=no in config.ini and using an API32 image still produces the BT audio switch when launching the emu.

Got log says 31.3.8 should include my change to fix this issue. Unfortunately I am out of the office and cannot check this.

I confirm, 8513367 does not affect BT audio quality, while 8598121 does affect.

It looks like I was late for two days for 31.3.8:

https://android-review.googlesource.com/c/platform/external/qemu/+/2056841 - 31.3.8 https://android-review.googlesource.com/c/platform/external/qemu/+/2078228 - my change

The fix should be in the next emulator version.

Here is what happened: the last time we cut a new release was April, 4. Since then we have been doing cherry-picks which I have not requested before. With the cherry-picks requested this fix is available in 31.3.9 which should be published by the end of this week or the next week.

Ranjit, could you please confirm this fix is available in 31.3.9?

You need bluetooth headphones for it.

1. Connect the headphones to the host.
2. Start some audio on the host (e.g. a youtube video with good audio quality).
3. Coldboot an emulator (you can use any system image, e.g. S), notice host's audio quality drops when the emulator starts.
4. Add hw.audioInput=no to the AVD's config.ini.
5. Coldboot the emulator again, check if host's audio quality is unaffected.

Thank you, Ranjit.

I can confirm 31.3.9 is now available from the canary channel and that it includes this fix. Thanks a lot for making this happen!

The fix should be available on M1 as well, it is in the 31.3.9 version. What is your emulator version?

I confirm I've tested it with 31.3.9 on M1 processor and it's working.

Did you tweak the .ini file as it was explained in this long thread?

Hi Jamie, it should be fixed, please add hw.audioInput=no to AVD's config.ini file for API32 and below. It is not required for API33 and above. There are some other quirks there (in API33) as I am learning about QEMU audio API behavior (the QEMU and kernel disagree on how audio is consumed).

It is not required for API33 and above

Using API 33 but the sound quality still drops

shalva258, could you please elaborate? I just created API30 and API33 on Mac and I can hear that API30 affects audio in my bt headphones when the emulator starts and API33 does not. Maybe update the emulator? I tried on 32.1.3.

I have API 33 and Android Emulator version is 31.3.14. How did you install 32.1.3? In Android Studio it does not say there is update available. On their website latest version is 31.3.13 and I dont know how AS downloaded 31.3.14 version :D

Is not this the version that should have fixed this?

Okay I found https://developer.android.com/studio/emulator_archive and installed (32.1.7) Canary 1 version. Now it is working fine

حذف الكل

It's freaking 2024, the original issue from 2016 that was marked as fixed was definitely not fixed, this one wasn't either. Windows 10, using emulator 34.2.14-11834374 and this beyond intrusive problem is still there. Good luck trying to share your emulator screen on a meeting and keep your audio and mic working without problems, you won't because this insanely dumb bug is still present to this day and it takes over your audio input forcing hour headset into hands-free mode when you don't want to.

Hi particlecore,

It's freaking 2024, the original issue from 2016 that was marked as fixed

The original issue is fixed.

Good luck trying to share your emulator screen on a meeting and keep your audio and mic working without problems

This is a separate problem which we have never heard before. Please file a new bug (specify which meeting software you use).