UMP kills the application after a render process crash, destroying services

[Lee Holmes]

On some devices, swiping away the app in the task list (i.e. closing the Activity) completely kills the application, including background services that are supposed to keep running. It's down to this error in the logs:

chromium: [ERROR:android_webview/browser/aw_browser_terminator.cc:165] Renderer process (30478) crash detected (code -1).

chromium: [ERROR:android_webview/browser/aw_browser_terminator.cc:113] Render process (30478) kill (OOM or update) wasn't handed by all associated webviews, killing application.

I've traced this to the UMP library (3.2.0 and earlier) - even just calling consentInformation.requestConsentInfoUpdate is enough to cause this behaviour, and it disappears if you don't.

I assume what's happening is the consent form is being created (even if it isn't shown), and it has an associated WebView that isn't being managed with the Termination Handling API - so when the renderer crashes as part of the Activity being shut down, the WebView is allowed to take down the entire application.

-----

This seems to happen in very specific circumstances - I can reproduce it every time, but only on an Android 13 MIUI device and not in an emulator. The Activity also needs to be visually updating - I have a custom view that's animating, and swiping away the Activity while that's happening causes this chain of events. Stopping the animation and waiting a moment means it doesn't happen - I assume this relates to whether a render process exists to crash in the first place.

I don't have a workaround for this (besides just not using UMP) because we have no access to that internal WebView  and its termination handling. It deliberately destroys the whole application (as it says in its error log and the documentation I linked) unless that situation is handled - and it seems like it should be, the UMP library shouldn't be able to potentially take down an app that uses it like this. There are situations (like with services) where the application expects to survive an Activity's render process being killed - which is the case when the UMP calls are removed, and everything works fine.

I hope that's enough info to point you in the right direction - thanks!

[Mobile Ads SDK Forum Advisor]

Hi Lee,

Thank you for contacting the Mobile Ads SDK support team.

I will check with our team regarding your query and one of my team members will reach out to you once we have an update on this.

Thanks,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               
[2025-09-26 12:57:28Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01u7cro:ref" (ADR-00333786)

[Mobile Ads SDK Forum Advisor]

Hello there,


Thanks for reaching out.

To confirm my understanding of the issue: after calling the UMP SDK's consentInformation.requestConsentInfoUpdate method, if the app is swiped away from the task list, the app's background processes are terminated instead of persisting as expected.

To help us narrow down the cause, could you clarify the timing of this?
Does the issue occur only if you swipe the app away immediately after the method is called, or does it happen at any point after the method has been called once during the app's lifecycle?

Additionally, to help us investigate further, could you provide the following information?

• A full stack trace from all threads at the time of the crash.
• A minimal, reproducible sample project.
• A screen recording that captures the issue occurring.

If any files are larger than 25MB, you can upload them using this link: https://docs.google.com/forms/d/e/1FAIpQLSfkAiXMeYP-fw1W3Z-tT9uwmATEKO5X6S-th0gR2ezdKaaqfg/viewform?usp=pp_url&entry.400550049=Mobile+Ads+SDK&entry.460850823=500Ht00001u7croIAA&entry.80707362=00333786.

 

Thanks,
 

Joshua Mobile Ads SDK Team

Feedback
How was our support today?
               

[2025-09-29 21:05:24Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01u7cro:ref" (ADR-00333786)

[Lee Holmes]

Hi Joshua - the issue occurs at the moment the Activity is swiped away, if (and only if) consentInformation.requestConsentInfoUpdate has been called at any point prior.

So in the normal running of the app, the UMP calls are made at launch time, and then if the user swipes the Activity away anytime later it terminates with that WebView error message about an unhandled event, every time. It doesn't matter whether you call the loadAndShowForm methods or not - and if you do, it's the same behaviour whether the form is shown and submitted, or if it's not displayed because consent isn't required. It also doesn't seem to matter if you go straight to the task list, or go from the home screen to the task list before swiping, and waiting several minutes with the app in the background before swiping it away makes no difference either.

I also found if you turn on Don't keep activities in the developer options, and background the Activity by say going to the home screen, the Activity gets destroyed cleanly and the WebView error doesn't occur. (Swiping away still causes the same crash.) So the trigger might be related to how MIUI (14 in this case) handles swiping away an Activity - but if you don't call consentInformation.requestConsentInfoUpdate there's no problem, everything works fine.

I was wrong about the animating thing I think - the app runs and binds to a service while "active", and the animation relates to that state. Removing the animation doesn't change anything, so it actually seems related to whether the service is running, and not whether it's rendering View updates just before you swipe.

----

I'll see if I can get a sample project together that demonstrates the issue, but there are a few complicated moving parts in the actual app and I'm not sure if I can pare it down. I tried a quick app with a running service and a requestConsentInfoUpdate call, and that wasn't enough to display this behaviour. (Plus it might be something that only appears on some devices)

I don't have an actual stack trace because the app is being killed outright by the system - the only error messages I get for the app process are the ones I posted. I'll attach a system log with the messages around the event that relate to the process being destroyed - I think I included the relevant stuff, but let me know if you need more.

Also you might want to take a look at this issue with the IMA SDK - I'm not using it but it looks like a very similar issue, an internal unhandled WebView crash taking down the host app, with the same error messages. They say they added a fix, so there might be something useful there.

[Joel Briggs]

So what do you suggest I do?

--

---
You received this message because you are subscribed to the Google Groups "Google Mobile Ads SDK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-admob-ads...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-admob-ads-sdk/2d0d2dad-f1c0-4498-bd11-786fb367ed25n%40googlegroups.com.

[Mobile Ads SDK Forum Advisor]

Re: Joel: Are you encountering the same issue as Lee did?

 

Hello Lee,
 

Thank you for the details.

I was unable to reproduce the issue on my end, which suggests that it may be device-specific. Please also note that the file you provided previously was a system log (logcat), not a full stack trace from all threads.

To help us investigate further, could you please try to reproduce the issue in one of our sample apps? https://github.com/googleads/googleads-mobile-android-examples

As requested in my previous email, could you also provide the following information?

• A full stack trace from all threads at the time of the crash.

• A minimal, reproducible sample project.

• A screen recording that captures the issue occurring.

If any files are larger than 25MB, you can upload them using this link: https://docs.google.com/forms/d/e/1FAIpQLSfkAiXMeYP-fw1W3Z-tT9uwmATEKO5X6S-th0gR2ezdKaaqfg/viewform?usp=pp_url&entry.400550049=Mobile+Ads+SDK&entry.460850823=500Ht00001u7croIAA&entry.80707362=00333786

Thanks,
 

Joshua Mobile Ads SDK Team

Feedback
How was our support today?
               

[2025-10-06 18:53:23Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01u7cro:ref" (ADR-00333786)

[Lee Holmes]

Ok, I managed to get an extremely basic sample project displaying the behaviour - turns out all you need is a foreground service to be running when the Activity is swiped away. This is just an Empty Activity project that does nothing except initialise UMP, and start a foreground service that outputs "working..." to the log every second. It logs "Activity destroyed" in onDestroy so you can see when it's swiped away.

(I uploaded it with the docs link since we can't attach zip files apparently?)

Without calling  consentInformation.requestConsentInfoUpdate:

Activity                         com...le.webviewcrashtest  I  onCreate
Service                          com...le.webviewcrashtest  I  Service started
Service                          com...le.webviewcrashtest  I  working...
Service                          com...le.webviewcrashtest  I  working...
Service                          com...le.webviewcrashtest  I  working...
Activity                         com...le.webviewcrashtest  I  Activity destroyed
Service                          com...le.webviewcrashtest  I  working...
Service                          com...le.webviewcrashtest  I  working...
Service                          com...le.webviewcrashtest  I  working...

With the  consentInformation.requestConsentInfoUpdate  call:

Activity                         com...le.webviewcrashtest  I  onCreate
Service                          com...le.webviewcrashtest  I  Service started
Service                          com...le.webviewcrashtest  I  working...
UserMessagingPlatform            com...le.webviewcrashtest  D  Receive consent action: consent://consent/?action=start_transparency_status_updates
UserMessagingPlatform            com...le.webviewcrashtest  D  Action[start_transparency_status_updates]: {}
UserMessagingPlatform            com...le.webviewcrashtest  D  Receive consent action: consent://consent/?action=configure_app_assets
UserMessagingPlatform            com...le.webviewcrashtest  D  Action[configure_app_assets]: {}
UserMessagingPlatform            com...le.webviewcrashtest  D  Wall html loaded.
...
UserMessagingPlatform            com...le.webviewcrashtest  D  Receive consent action: consent://consent/?action=load_complete&args=%7B%22status%22%3A%22ok%22%7D
UserMessagingPlatform            com...le.webviewcrashtest  D  Action[load_complete]: {"status":"ok"}
Service                          com...le.webviewcrashtest  I  working...
Service                          com...le.webviewcrashtest  I  working...
Activity                         com...le.webviewcrashtest  I  Activity destroyed
cr_ChildProcessConn              com...le.webviewcrashtest  W  onServiceDisconnected (crash or killed by oom): pid=27204 bindings:W  S
chromium                         com...le.webviewcrashtest  E  [ERROR:android_webview/browser/aw_browser_terminator.cc:165] Renderer process (27204) crash detected (code -1).
chromium                         com...le.webviewcrashtest  E  [ERROR:android_webview/browser/aw_browser_terminator.cc:113] Render process (27204) kill (OOM or update) wasn't handed by all associated webviews, killing application.
---------------------------- PROCESS ENDED (26319) for package com.example.webviewcrashtest ----------------------------

Without the UMP call, the service continues to run after the Activity is swiped away. But if you do make the call (it's happening in onCreate here) then when the Activity is swiped away, the process is immediately killed (and the service obviously stops with it). And even if the service is sticky, the system won't restart it because the process didn't shut down normally, it's gone. Which is especially a problem if the user isn't aware that it's happened, and they're relying on the app to do something in the background.

This still only affects the MIUI device and not any emulators I've tested it on, but that's potentially a lot of devices - and if it affects any app using foreground services (media players, health apps etc) then it could be a widespread issue!

[Lee Holmes]

Hi Joel - the specific trigger for the issue might be device specific, but the crash itself is explicitly being caused by a WebView that's deliberately destroying the app process. I'm not using a WebView anywhere in this app, and the issue only arises when consentInformation.requestConsentInfoUpdate is called, which seems to imply the WebView terminating the app is being created and managed inside the UMP library.

Could you confirm if it uses one, and if so, is it making use of the Termination handling API to prevent crashes? From the documentation:

The Termination Handling API handles cases where the renderer process for a WebView object goes away, either because the system kills the renderer to reclaim necessary memory or because the renderer process crashes. By using this API, you let your app continue executing, even though the renderer process goes away.

(Bolding mine.) As a library, if UMP is using an internal WebView, it should be implementing this to allow the host app to carry on working (if it can). By not implementing the API, you would be choosing to crash the host app if that internal WebView ever runs into this issue, whatever the cause. UMP isn't critical to the host app, and I don't think it should be making that kind of decision because of something happening internally.

Do you see what I mean? I don't know if this is actually the case, but this is where the error log, the appearance of the error when using UMP, and the documented behaviour of the WebView are all pointing. And if there's one inside the UMP library, it should be handled safely (especially since the form is almost never actually needed beyond the first run of the app). So could you please check if there's a WebView, and the API is being used to avoid these deliberate terminations?

--------

I'll give you any info I can, but like I said in the last message, I don't have a stacktrace - the WebView system component is terminating the app, seemingly following documented behaviour. The system log is all I have, unless there's some other way to get one that I'm not aware of. If the app itself was throwing an exception, there'd be a possibility I could do something to deal with it, but there's a WebView I don't have access to explicitly killing the app process via the system itself.

I can't give you a video because it would just be the app being swiped away, and the system log I posted appearing. I can't give you a sample application because this particular example of the WebView's render process crashing seems to rely on very specific circumstances - but the point is that the WebView termination should be handled safely when it happens (in this circumstance or any others), and it seems like it's not. And this could be causing issues for other people in other situations, with no easy way to identify what's causing it (what happens if the system WebView component updates while an app that includes UMP is running, for example?)

I really wish I could give you a reproducible example - all I can do is point you to a potential implementation issue that this seems to be a symptom of, and ask you to please check what the library is doing in that situation. Thanks!

[Lee Holmes]

Is it affecting you too? If so, any information you can add (situations where you see the crashes, devices/Android versions it happens on, any steps to replicate it) would be a big help!

If it's a misconfigured WebView in the library then I don't think we can do anything except draw attention to it and wait for them to fix it. 

[Mobile Ads SDK Forum Advisor]

Hello Lee,


Thank you for providing the detailed information and the sample project.

We are actively investigating this issue and expect to have an update for you by the end of next week.

In the meantime, please let us know if you are able to reproduce this crash on any emulators or other physical devices. That information would be very helpful for our investigation.


 

Thanks,
 

Joshua Mobile Ads SDK Team

Feedback
How was our support today?
               

[2025-10-15 15:41:43Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01u7cro:ref" (ADR-00333786)