[Android] Mozilla VPN cannot be used after changing the device wallpaper while the VPN is ON

[data-sync-user]

Important details:

• even after several minutes, the VPN still displays a black screen and the app cannot be swipe-killed or used. The VPN can be used only after restarting the device; 

• if the VPN is OFF while changing the device wallpaper, the white screen is still displayed after reopening the app, but after swipe-killing it, the VPN can be used;

• not reproducing if the app is swipe-killed instead of minimized before changing the wallpaper; 

• reproducing on Mozilla VPN 2.16.0 and 2.16.2 as well;

Affected versions:

• 2.17.0 (2.202308241644);

Tested Platforms:

• Android 13; 

Prerequisites:

• Have Mozilla VPN app installed and open;

• Have a Fx account with an active subscription;

• Be signed in;

Steps to reproduce:

1. Turn ON the VPN;
2. Minimize the app (do not swipe-kill the app);
3. Go to device settings and change the wallpaper;
4. After the wallpaper is changed, open Mozilla VPN app;
5. Observe the behavior;
6. Swipe-kill and reopen the app;
7. Observe the behavior;

Expected result:

• The VPN home screen is displayed. There are no issues;

Actual result:

• For step 5: A white screen is displayed, which contains the Mozilla VPN logo and “Mozilla VPN” text as title; 

• For step 7: A black screen with Mozilla VPN logo is displayed. The user is not able to use the VPN;

Notes:

• See the video;

┆Issue is synchronized with this Jira Bug ┆Reporter: Bianca Hidecuti

[data-sync-user]

➤ Lesley Norton commented:

cc Santiago Andrigo for a priority. I’m inclined to say this is a Medium because it strikes me as an edge case, albeit an ugly one.

[data-sync-user]

➤ Santiago Andrigo commented:

I’m on Android 13 (but the OxygenOS 13.1 mod) and I can’t reproduce. It is pretty bad though, as requiring a reboot is more ‘intuitive’ in desktop but really not much of a common thing on mobile, where swipe killing generally fixes everything. I’d put this on High but would like to see if we can reproduce in more devices. If it’s not affecting all Android 13, then maybe a Medium.

[data-sync-user]

➤ Bianca Hidecuti commented:

Santiago Andrigo, we are able to reproduce this on Android 13 while using Pixel 7a and Samsung S22 devices.

Also, we were able to reproduce this on Android 12 as well, while using a Pixel 3a device.

[data-sync-user]

➤ Bianca Hidecuti commented:

I am able to reproduce this issue on Mozilla VPN 2.17, using Android 13 (device: Pixel 7a) if the “Bold text” option from OS settings (Settings - Display - Dispaly size and text) is enabled while the VPN is ON. Attaching a video as well.

!fadffbd7-2a53-4725-bb7f-a913257a886f.mp4|width=576,height=1280!

[data-sync-user]

➤ Matt Cleinman commented:

I can replicate on my Android test device, a Pixel 6a running Android 13

[data-sync-user]

➤ Matt Cleinman commented:

• Nothing that useful in logs.

  • Searching for Qt Android wallpaper background - nothing jumping out at me

  • Tried turning off sentry and super dooper metrics (from feature list in dev menu) and “data collection” from app settings - still replicates it

  • Looking at more logs:

  • Wireguard reported current tunnel: -1 is in daemon logs, worth checking out probably

  • After we come back (and get the white screen), only things in logs are a few lines about some glean work

  • There is literally nothing in the app logs from when we quit and restart (after changing the background, when we get a white screen) - it’s like it never happened

  • This seems similar, but with different repro steps: https://stackoverflow.com/questions/56382729/qt-application-visually-freezes-after-start-or-return-from-background ( https://stackoverflow.com/questions/56382729/qt-application-visually-freezes-after-start-or-return-from-background|smart-link )

  • nah not it

  • It does the same thing when the VPN is turned off - so this is about our app, not our VPN daemon

From logcat, some pertinent lines:

10-02 15:59:22.509 2329 2329 V ActivityThread: getPackageInfo() caused update to cached ApplicationInfo for package org.mozilla.firefox.vpn 10-02 15:59:32.738 14602 16223 D WireGuard/GoBackend/mvpn0: peer(bZQF…gsC0) - Sending handshake initiation 10-02 15:59:32.766 14602 16224 D WireGuard/GoBackend/mvpn0: peer(bZQF…gsC0) - Received handshake response 10-02 15:59:32.767 14602 16224 D WireGuard/GoBackend/mvpn0: peer(bZQF…gsC0) - Sending keepalive packet 10-02 15:59:36.168 1757 13119 W InputManager-JNI: Input channel object '59a8b2b org.mozilla.firefox.vpn/org.mozilla.firefox.vpn.qt.VPNActivity (client)' was disposed without first being removed with the input manager! 10-02 15:59:36.169 1757 2842 E WindowManager: setOnBackInvokedCallback(): No window state for package:org.mozilla.firefox.vpn 10-02 15:59:36.199 14523 14523 D mozillavpn: [02.10.2023 15:59:36.199] (Rust) Debug: uniffi_glean_fn_func_glean_handle_client_active 10-02 15:59:36.199 14523 14572 D mozillavpn: [02.10.2023 15:59:36.199] (Rust) Info: Glean disabled: not submitting any pings. 10-02 15:59:36.199 14523 14572 D mozillavpn: [02.10.2023 15:59:36.199] (Rust) Info: baseline ping not submitted on active 10-02 15:59:36.200 14523 14523 D mozillavpn: [02.10.2023 15:59:36.199] (Rust) Debug: uniffi_glean_fn_method_countermetric_add 10-02 15:59:36.204 1757 9995 D CoreBackPreview: Window{dcecbad u0 org.mozilla.firefox.vpn/org.mozilla.firefox.vpn.qt.VPNActivity}: Setting back callback OnBackInvokedCallbackInfo{mCallback=android.window.IOnBackInvokedCallback$Stub$Proxy@1adb273, mPriority=0} 10-02 15:59:36.204 14523 14523 E ActivityThread: Activity org.mozilla.firefox.vpn.qt.VPNActivity has leaked IntentReceiver org.qtproject.qt.android.network.QtNetwork$ProxyReceiver@196062e that was originally registered here. Are you missing a call to unregisterReceiver()? 10-02 15:59:36.204 14523 14523 E ActivityThread: android.app.IntentReceiverLeaked: Activity org.mozilla.firefox.vpn.qt.VPNActivity has leaked IntentReceiver org.qtproject.qt.android.network.QtNetwork$ProxyReceiver@196062e that was originally registered here. Are you missing a call to unregisterReceiver()? 10-02 15:59:36.204 14523 14523 E ActivityThread: Activity org.mozilla.firefox.vpn.qt.VPNActivity has leaked ServiceConnection org.mozilla.firefox.vpn.qt.VPNActivity$1@856d5cf that was originally bound here 10-02 15:59:36.204 14523 14523 E ActivityThread: android.app.ServiceConnectionLeaked: Activity org.mozilla.firefox.vpn.qt.VPNActivity has leaked ServiceConnection org.mozilla.firefox.vpn.qt.VPNActivity$1@856d5cf that was originally bound here 10-02 15:59:36.204 14523 14523 E ActivityThread: at org.mozilla.firefox.vpn.qt.VPNActivity.initServiceConnection(VPNActivity.java:154) 10-02 15:59:36.204 14523 14523 E ActivityThread: at org.mozilla.firefox.vpn.qt.VPNActivity.connectService(VPNActivity.java:69) 10-02 15:59:36.212 1757 2842 D ConnectivityService: requestNetwork for uid/pid:10221/14523 activeRequest: null callbackRequest: 412 [NetworkRequest [ REQUEST id=413, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VCN_MANAGED Uid: 10221 RequestorUid: 10221 RequestorPkg: org.mozilla.firefox.vpn UnderlyingNetworks: Null] ]] callback flags: 0 order: 2147483647 10-02 15:59:36.213 1757 2256 D UntrustedWifiNetworkFactory: got request NetworkRequest [ REQUEST id=413, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VCN_MANAGED Uid: 10221 RequestorUid: 10221 RequestorPkg: org.mozilla.firefox.vpn UnderlyingNetworks: Null] ] 10-02 15:59:36.213 1757 2256 D OemPaidWifiNetworkFactory: got request NetworkRequest [ REQUEST id=413, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VCN_MANAGED Uid: 10221 RequestorUid: 10221 RequestorPkg: org.mozilla.firefox.vpn UnderlyingNetworks: Null] ] 10-02 15:59:36.213 1757 2256 D MultiInternetWifiNetworkFactory: got request NetworkRequest [ REQUEST id=413, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VCN_MANAGED Uid: 10221 RequestorUid: 10221 RequestorPkg: org.mozilla.firefox.vpn UnderlyingNetworks: Null] ] 10-02 15:59:36.224 1757 13119 I WindowManager: finishDrawing of relaunch: Window{dcecbad u0 org.mozilla.firefox.vpn/org.mozilla.firefox.vpn.qt.VPNActivity} 60ms 10-02 15:59:36.233 14523 14587 D mozillavpn: [02.10.2023 15:59:36.233] (Rust) Debug: uniffi_glean_fn_func_glean_get_upload_task 10-02 15:59:36.233 14523 14587 D mozillavpn: [02.10.2023 15:59:36.233] (Rust) Info: No more pings to upload! You are done. 10-02 15:59:36.237 3665 3665 I GoogleInputMethodService: GoogleInputMethodService.onStartInput():1889 onStartInput(EditorInfo{EditorInfo{packageName=org.mozilla.firefox.vpn, inputType=0, inputTypeString=NULL, enableLearning=false, autoCorrection=false, autoComplete=false, imeOptions=0, privateImeOptions=null, actionName=UNSPECIFIED, actionLabel=null, initialSelStart=-1, initialSelEnd=-1, initialCapsMode=0, label=null, fieldId=-1, fieldName=null, extras=null, hintText=null, hintLocales=[]}}, false) 10-02 15:59:37.243 2546 2546 D MediaPlayerList: Name of package changed: org.mozilla.firefox.vpn 10-02 15:59:37.274 2719 2719 D CarrierSvcBindHelper: onPackageModified: org.mozilla.firefox.vpn 10-02 15:59:37.278 2719 2719 D ImsResolver: maybeAddedImsService, packageName: org.mozilla.firefox.vpnLine one of this snippet happens right as the wallpaper switches. Also getPackageInfo only exists within the Adjust library. Are they screwing us here? Also seems to mention IntentReceiver and ServiceConnection.

Next up:

• Try removing adjust

  • In android/sources.cmake, I commented out lines 11-35 (the stuff about Adjust)
  • OK, so this gave a crash. But also Adjust doesn’t happen after the first run, nor if telemetry is turned off - and it still crashed with telemetry turned off. Hmmm, probably not that.

• is it app icons? something about teh dynamic way of doing them?

• look into IntentReciver and ServiceConnection

[data-sync-user]

➤ Matt Cleinman commented:

Did another search, and this seems super-relevant: https://9to5google.com/2021/11/03/android-12-wallpaper-crash-apps-games/ ( https://9to5google.com/2021/11/03/android-12-wallpaper-crash-apps-games/|smart-link )

Following down this path.

[data-sync-user]

➤ Matt Cleinman commented:

• So assuming it’s an activity restart issue, why can’t it connect with the VPN daemon activity? VPN daemon activity is still working as expected, from looking at whatismyip

  • When there is a hang, the app logs show absolutely nothing from restarting the app (where it hangs on the launch screen). Only relevant line in daemon logs: (VPNService) - Client Disconnected, VPN is up

  • SEARCH AROUND THIS, WHAT IS THIS BINDING DOING?

  • AndroidController::initialize isn’t reached when doing a cold launch in this bad state, from looking at logs. Which means ConnectionManager::initialize isn’t called either. Why?

  • This makes it feel Qt-ish.

  • There is some Glean stuff in logs - WHY? SHOULDN’T BE - IS THIS THE ISSUE?

  • Would a later Qt handle this okay?

  • Looking at Qt change logs: Wallpaper doesn't pop up, but Android and config have a lot of entries.

  • COULD JUST TRY RUNNING THIS ON LATER VERSION QT

  • Let’s logcat this and see what happens when the wallpaper changes - grep on VPN - see all these below

got this around the time of wallpaper switch: 10-04 13:08:04.859 1732 1732 V ActivityThread: getPackageInfo() caused update to cached ApplicationInfo for package org.mozilla.firefox.vpn

When go back to the app (and get the white screen):

10-04 13:08:48.047 1257 4034 D CoreBackPreview: Window{12876d1 u0 org.mozilla.firefox.vpn/org.mozilla.firefox.vpn.qt.VPNActivity}: Setting back callback null 10-04 13:08:48.047 1257 1480 W InputManager-JNI: Input channel object '12876d1 org.mozilla.firefox.vpn/org.mozilla.firefox.vpn.qt.VPNActivity (client)' was disposed without first being removed with the input manager! 10-04 13:08:48.075 14566 14566 E ActivityThread: Activity org.mozilla.firefox.vpn.qt.VPNActivity has leaked IntentReceiver org.qtproject.qt.android.network.QtNetwork$ProxyReceiver@6fca364 that was originally registered here. Are you missing a call to unregisterReceiver()? 10-04 13:08:48.075 14566 14566 E ActivityThread: android.app.IntentReceiverLeaked: Activity org.mozilla.firefox.vpn.qt.VPNActivity has leaked IntentReceiver org.qtproject.qt.android.network.QtNetwork$ProxyReceiver@6fca364 that was originally registered here. Are you missing a call to unregisterReceiver()? 10-04 13:08:48.075 14566 14566 E ActivityThread: Activity org.mozilla.firefox.vpn.qt.VPNActivity has leaked ServiceConnection org.mozilla.firefox.vpn.qt.VPNActivity$1@6b239cd that was originally bound here 10-04 13:08:48.075 14566 14566 E ActivityThread: android.app.ServiceConnectionLeaked: Activity org.mozilla.firefox.vpn.qt.VPNActivity has leaked ServiceConnection org.mozilla.firefox.vpn.qt.VPNActivity$1@6b239cd that was originally bound here 10-04 13:08:48.075 14566 14566 E ActivityThread: at org.mozilla.firefox.vpn.qt.VPNActivity.initServiceConnection(VPNActivity.java:154) 10-04 13:08:48.075 14566 14566 E ActivityThread: at org.mozilla.firefox.vpn.qt.VPNActivity.connectService(VPNActivity.java:69) 10-04 13:08:48.075 1257 1932 D CoreBackPreview: Window{a8cf81a u0 org.mozilla.firefox.vpn/org.mozilla.firefox.vpn.qt.VPNActivity}: Setting back callback OnBackInvokedCallbackInfo{mCallback=android.window.IOnBackInvokedCallback$Stub$Proxy@9617d28, mPriority=0} 10-04 13:08:48.087 1257 1932 D ConnectivityService: requestNetwork for uid/pid:10221/14566 activeRequest: null callbackRequest: 350 [NetworkRequest [ REQUEST id=351, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VCN_MANAGED Uid: 10221 RequestorUid: 10221 RequestorPkg: org.mozilla.firefox.vpn UnderlyingNetworks: Null] ]] callback flags: 0 order: 2147483647 10-04 13:08:48.089 1257 1634 D UntrustedWifiNetworkFactory: got request NetworkRequest [ REQUEST id=351, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VCN_MANAGED Uid: 10221 RequestorUid: 10221 RequestorPkg: org.mozilla.firefox.vpn UnderlyingNetworks: Null] ] 10-04 13:08:48.089 1257 1634 D OemPaidWifiNetworkFactory: got request NetworkRequest [ REQUEST id=351, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VCN_MANAGED Uid: 10221 RequestorUid: 10221 RequestorPkg: org.mozilla.firefox.vpn UnderlyingNetworks: Null] ] 10-04 13:08:48.089 1257 1634 D MultiInternetWifiNetworkFactory: got request NetworkRequest [ REQUEST id=351, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VCN_MANAGED Uid: 10221 RequestorUid: 10221 RequestorPkg: org.mozilla.firefox.vpn UnderlyingNetworks: Null] ] 10-04 13:08:48.093 1257 4035 I WindowManager: finishDrawing of relaunch: Window{a8cf81a u0 org.mozilla.firefox.vpn/org.mozilla.firefox.vpn.qt.VPNActivity} 51ms 10-04 13:08:48.111 14566 14691 D mozillavpn: [04.10.2023 13:08:48.111] (Rust) Debug: uniffi_glean_fn_func_glean_get_upload_task 10-04 13:08:48.111 14566 14691 D mozillavpn: [04.10.2023 13:08:48.111] (Rust) Info: No more pings to upload! You are done. 10-04 13:08:48.115 3107 3107 I GoogleInputMethodService: GoogleInputMethodService.onStartInput():1889 onStartInput(EditorInfo{EditorInfo{packageName=org.mozilla.firefox.vpn, inputType=0, inputTypeString=NULL, enableLearning=false, autoCorrection=false, autoComplete=false, imeOptions=0, privateImeOptions=null, actionName=UNSPECIFIED, actionLabel=null, initialSelStart=-1, initialSelEnd=-1, initialCapsMode=0, label=null, fieldId=-1, fieldName=null, extras=null, hintText=null, hintLocales=[]}}, false) 10-04 13:08:49.102 1938 1938 D MediaPlayerList: Name of package changed: org.mozilla.firefox.vpn 10-04 13:08:49.145 2103 2103 D CarrierSvcBindHelper: onPackageModified: org.mozilla.firefox.vpn 10-04 13:08:49.145 2103 2103 D ImsResolver: maybeAddedImsService, packageName: org.mozilla.firefox.vpnHard quit, restart (first few lines might be before I actually launched the app:

10-04 13:09:36.499 1257 2264 I InputDispatcher: Channel [Gesture Monitor] swipe-up (server) is stealing touch from [a8cf81a org.mozilla.firefox.vpn/org.mozilla.firefox.vpn.qt.VPNActivity (server), [Gesture Monitor] edge-swipe (server)] 10-04 13:09:38.454 14566 14575 W lla.firefox.vpn: Cleared Reference was only reachable from finalizer (only reported once) 10-04 13:09:39.753 14705 15374 D WireGuard/GoBackend/mvpn0: peer(fU4o…sCmU) - Receiving keepalive packet 10-04 13:09:43.397 1257 1421 I ActivityTaskManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=org.mozilla.firefox.vpn/.qt.VPNActivity bnds=[298,1920][540,2235]} from uid 10205 10-04 13:09:43.417 1257 1421 D CoreBackPreview: Window{5c0533a u0 Splash Screen org.mozilla.firefox.vpn}: Setting back callback OnBackInvokedCallbackInfo{mCallback=android.window.IOnBackInvokedCallback$Stub$Proxy@831d48, mPriority=0} 10-04 13:09:48.465 1257 1473 W ActivityTaskManager: Activity destroy timeout for ActivityRecord{2ac9db2 u0 org.mozilla.firefox.vpn/.qt.VPNActivity} t531 f}} 10-04 13:09:48.466 1257 1473 W InputManager-JNI: Input channel object 'a8cf81a org.mozilla.firefox.vpn/org.mozilla.firefox.vpn.qt.VPNActivity (client)' was disposed without first being removed with the input manager! 10-04 13:09:48.477 1257 1482 W UsageStatsService: Unexpected activity event reported! (org.mozilla.firefox.vpn/org.mozilla.firefox.vpn.qt.VPNActivity event : 23 instanceId : 16139197) 10-04 13:09:54.736 14705 14722 D WireGuard/GoBackend/mvpn0: peer(fU4o…sCmU) - Sending keepalive packet 10-04 13:10:24.788 14705 15374 D WireGuard/GoBackend/mvpn0: peer(fU4o…sCmU) - Sending keepalive packet 10-04 13:10:44.373 1257 1592 W InputDispatcher: Not sending touch gesture to 6b47830 ActivityRecordInputSink org.mozilla.firefox.vpn/.qt.VPNActivity because it is not responsive 10-04 13:10:45.440 1257 1592 W InputDispatcher: Not sending touch gesture to 6b47830 ActivityRecordInputSink org.mozilla.firefox.vpn/.qt.VPNActivity because it is not responsiveRestart again:

10-04 13:11:13.978 1257 4176 I ActivityTaskManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=org.mozilla.firefox.vpn/.qt.VPNActivity bnds=[298,1920][540,2235]} from uid 10205 10-04 13:11:14.002 1257 4176 D CoreBackPreview: Window{3846f14 u0 Splash Screen org.mozilla.firefox.vpn}: Setting back callback OnBackInvokedCallbackInfo{mCallback=android.window.IOnBackInvokedCallback$Stub$Proxy@1fd6103, mPriority=0}

[data-sync-user]

➤ Matt Cleinman commented:

So it seems like it’s being killed so quickly it can’t disconnect something. Is that it? If so, how do we reconnect?

Yeah, definitely seems like ( https://commonsware.com/blog/2021/10/31/android-12-wallpaper-changes-recreate-activities.html ) the activity is being restarted. So why aren’t we recovering gracefully? And how does that Activity lifecycle work? Time to research.

Oh, there is a QTActivity, which VPNActivity extends. Let’s look into that as well. Nothing that changed in that file in the last few years jumps out at me as important to that.

[data-sync-user]

➤ Matt Cleinman commented:

Same behavior w/ or w/o the tile - so that’s not relevant

First three log lines when on a good start:

10-04 16:19:10.697 1257 2951 I ActivityTaskManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=org.mozilla.firefox.vpn/.qt.VPNActivity bnds=[298,1920][540,2235]} from uid 10205 10-04 16:19:10.725 1257 4034 D CoreBackPreview: Window{99104ee u0 Splash Screen org.mozilla.firefox.vpn}: Setting back callback OnBackInvokedCallbackInfo{mCallback=android.window.IOnBackInvokedCallback$Stub$Proxy@7ea481c, mPriority=0} 10-04 16:19:10.730 1257 1484 I ActivityManager: Start proc 22370:org.mozilla.firefox.vpn/u0a221 for next-top-activity {org.mozilla.firefox.vpn/org.mozilla.firefox.vpn.qt.VPNActivity}That third line isn’t there on the bad start. Because the Activity is already there somehow. Let’s focus on making sure that activity is dead when we start the app?

(Yes, this is focusing on the restart scenario, which is only one of the two scenarios - but if it’s easy to fix, it may be an okay compromise.)

Why do we have both VPNActivity.java and androidvpnactivity.cpp?

Adding android:clearTaskOnLaunch="true" to the manifet (in VPNActivity section) didn’t do anything here.

[data-sync-user]

➤ Matt Cleinman commented:

Per discussion in stand up, I’ve done a bit more digging in here, and am now unassigning myself from this one.

Summary of where I’m at:

• Android 12 is recreating the activities when setting new wallpaper (a source ( https://commonsware.com/blog/2021/10/31/android-12-wallpaper-changes-recreate-activities.html )), and we can’t opt out of it. (I saw some reference that Android fixed this crash issue in a future version, but was unable to find more information about this.)
• Our app isn’t handling that activity recreation well. I’m not sure if this is a Qt thing or a thing our app should handle. (I did not try upgrading Qt, but did look at all future release notes after 6.2.4 and nothing jumped out at me that would fix this.)
• What is more worrisome to me: Hard quit and relaunch the app, and it hangs on the launch screen. There is nothing in the logs, and I’m not quite sure how to debug this. (See below for Android Studio attempts.) The only way to fix this (and be able to use our app) is turn off the VPN in the system settings, or reboot the device.
• My personal opinion, yet to be OK’d by product: If we can get a fix that allows for a successful quit and relaunch, that may be good enough here. Apparently this “change wallpaper, apps crash” is an Android thing that now just happens, and relaunching an app is something most users know to check.

I tried timeboxing getting our project to run on Android Studio to access better debugging tools, and ran into issues. Surprisingly, I could find nothing on the internet about using Qt with Android Studio. However, according to this page ( https://developer.android.com/studio/projects/add-native-code ), C++ code needs to be in a cpp directory in our project. Which obviously it’s not. I’m going to stop working on Android Studio integration for now.

[data-sync-user]

➤ Basti commented:

I tried timeboxing getting our project to run on Android Studio to access better debugging tools, and ran into issues. Surprisingly, I could find nothing on the internet about using Qt with Android Studio.

Yes that is a can of worms q_q - sadly qt’s take on “how this should build” is hiding as much as possible from gradle and just abuse it as a bundler. If there is interest, we might pick this branch up again https://github.com/mozilla-mobile/mozilla-vpn-client/tree/basti/prototype/sadCmake ( https://github.com/mozilla-mobile/mozilla-vpn-client/tree/basti/prototype/sadCmake|smart-link ) , yolo sprint is coming up… I experimented with writing a gradle plugin that can replace the androiddeployQt binary, which would allow us to completly have the android client inside a gradle dep graph, making android studio “just work”.

Back onto the bug! Thanks for the investigation, super helpful! The problem is in https://sourcegraph.com/github.com/qt/qtbase@6.4/-/blob/src/android/jar/src/org/qtproject/qt/android/QtActivityDelegate.java?L1298 ( https://sourcegraph.com/github.com/qt/qtbase@6.4/-/blob/src/android/jar/src/org/qtproject/qt/android/QtActivityDelegate.java?L1298|smart-link ) >:c I’m not quite understanding this. It seems we’re in the else branch when crating the surface and just calling:

m_activity.getResources().getDrawable()

We can see this throws an exception, due to a missing resource. However given that the theme is OS provided… i’m not sure it’s our fault? It seems qt is missing a try catch with a default value here.

Anyway, so the creation of the surface throws therefore qt has no canvas to paint the client onto, which is the reason we’re seeing the “default app” window.

I’m trying today to check that with a local patching qt 🙂

[data-sync-user]

➤ Basti commented:

Yea, so this seems to be fixed in combination of fixing a connection leak + upgrading qt to 6.6 - so marking this as blocked until we do so.

[data-sync-user]

➤ Santiago Andrigo commented:

Basti AFAIK, we are moving to 6.5.2 though (https://mozilla-hub.atlassian.net/browse/VPN-5519 ( https://mozilla-hub.atlassian.net/browse/VPN-5519|smart-link )). Do you really mean 6.6?

[data-sync-user]

➤ Basti commented:

Santiago Andrigo , yep 6.6

[data-sync-user]

➤ Basti commented:

The patch has been merged, however until we upgrade the client with 6.6.0, this will still be broken and cannot be verified.

[data-sync-user]

➤ Bianca Hidecuti commented:

We will verify this after https://mozilla-hub.atlassian.net/jira/software/c/projects/VPN/issues/VPN-5836 ( https://mozilla-hub.atlassian.net/jira/software/c/projects/VPN/issues/VPN-5836 ) will be done.

[data-sync-user]

➤ Bianca Hidecuti commented:

We are blocked in verifying this due to the following issue: https://mozilla-hub.atlassian.net/browse/VPN-5986 ( https://mozilla-hub.atlassian.net/browse/VPN-5986|smart-link )

[data-sync-user]

➤ Bianca Hidecuti commented:

Verified this on Mozilla VPN 2.21.0 (2.202402081611) - NEXT build from +Treeherder+ ( https://treeherder.mozilla.org/jobs?repo=mozilla-vpn-client&fromchange=4f377fa5ac6b96db48232209752fc7966fef0e69&selectedTaskRun=LZWVjCa3R3GYT5AwHcRv9A.0 ) (QT 6.6.0), using Android 14, and the issue is no longer reproducible while changing the device wallpaper / if the “Bold text” option from OS settings is enabled while the VPN is ON - attaching postfix video.

!fixed b0fca3e6-62d4-4b26-a7b1-994d7fb0ec1e.mp4|width=576,height=1280!

However, I’m noticing that the VPN remains in Connecting state when attempting to turn ON the VPN after changing the device wallpaper / after the “Bold text” option from OS settings is enabled. Basti, should we track this separately as reopen the issue? I am attaching a video and logs as well.

Thanks in advance!

!Connecting media_20240209_093834_6283169220080496425.mp4|width=576,height=1280!

[^Connecting MozillaVPN_Logs_2024-38-09-9-38-10.txt]

[data-sync-user]

➤ Basti commented:

Bianca Hidecuti

Thank you! Please file a diffrent issue for that, it’s similar but certainly a diffrent thing 😕

[data-sync-user]

➤ Bianca Hidecuti commented:

Thanks, Basti!

Logged a separate ticket for described behavior: https://mozilla-hub.atlassian.net/browse/VPN-6206 ( https://mozilla-hub.atlassian.net/browse/VPN-6206|smart-link )

As the initial issue no longer reproduces while using qt 6.6.0 builds from Treeherder, I am marking this verified as fixed.