Open Intent without closing the TWA
Hey
Not sure if this is a bug, or something that could potentially be improved/implemented in the future.
In the scenario where my users have Blocked notifications in the past, and we want to instruct them to Unblock once they've changed their mind, I'm trying to send the user to the App Notifications Settings dialog.
What I've done so far is:
<activity android:name="com.mypackage.ReceiverActivity" android:exported="true">
<intent-filter>
<action android:name="openSettings" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data
android:scheme="myscheme"
android:host="myhost" />
</intent-filter>
</activity>
public class ReceiverActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
Intent intent = new Intent();
intent.setAction("android.settings.APP_NOTIFICATION_SETTINGS");
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
//for Android 5-7
intent.putExtra("app_package", getPackageName());
intent.putExtra("app_uid", getApplicationInfo().uid);
// for Android 8 and above
intent.putExtra("android.provider.extra.APP_PACKAGE", getPackageName());
startActivity(intent);
}
}
And then a button in my website that points to:
intent://myhost#Intent;scheme=myscheme;package=com.mypackage;action=openSettings;end
This works well, in terms of opening the App Notifications Settings, but it appears that the TWA activity closed, so if I try to go "Back", I go back to my homescreen. In some situations, I get an Android alert saying that my app "keeps closing".
Is there a way we can preserve the TWA activity open, and this Notifications dialog simply opens as an extra view/layer?
Thank you!
Desktop:
- OS: Windows 11
- Version: 1.17.2
Smartphone:
- Device: LG, Android 10
- Browser: Chrome 101
@nunoperalta do you find any solution for this? I'm having the similar issue. I have an intent-filter like this:
<activity android:name=".TestActivity" android:exported="true">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:host="open-activity" android:scheme="my-app" />
</intent-filter>
</activity>
and in my web application I have a link: href="my-app://open-activity" to start another activity. but when I click on that link application get closed...
@mohammad-zr Unfortunately, I didn't :( But it would be important to get this fixed eventually (I assume, by Google Chrome or Bubblewrap).
Others have had the same issue:
https://stackoverflow.com/questions/68111288/twa-autocloses-on-firing-chrome-intent
https://stackoverflow.com/questions/52042295/how-to-send-data-from-my-twa-webapp-to-my-app/61446352#61446352
I commented on both to ask if they were able to resolve this.
@PEConn do you have any workaround or solution for this issue?
I get an Android alert saying that my app "keeps closing" this implies that something is crashing.
Would it be possible to provide an APK? I've tried reproducing this myself (just adding an Activity to twa-basic), but the TWA activity stays alive underneath the new Activity.
Or alternatively, could you give the output of adb logcat while reproducing this?
Thank you for the advice about using adb logcat.
This actually seems to tell me why it's crashing. Although I'm not very sure how to resolve (I haven't done any investigation yet, but if anything is obvious resolution to you, please let me know).
07-04 20:45:25.312 31405 31405 D AndroidRuntime: Shutting down VM 07-04 20:45:25.312 31405 31405 E AndroidRuntime: FATAL EXCEPTION: main 07-04 20:45:25.312 31405 31405 E AndroidRuntime: Process: com.mywebapp, PID: 31405 07-04 20:45:25.312 31405 31405 E AndroidRuntime: java.lang.IllegalStateException: You need to use a Theme.AppCompat theme (or descendant) with this activity. 07-04 20:45:25.312 31405 31405 E AndroidRuntime: at androidx.appcompat.app.f.Q(Unknown Source:421) 07-04 20:45:25.312 31405 31405 E AndroidRuntime: at androidx.appcompat.app.f.W(Unknown Source:4) 07-04 20:45:25.312 31405 31405 E AndroidRuntime: at androidx.appcompat.app.f.s(Unknown Source:0) 07-04 20:45:25.312 31405 31405 E AndroidRuntime: at androidx.appcompat.app.c.onPostCreate(Unknown Source:7) 07-04 20:45:25.312 31405 31405 E AndroidRuntime: at android.app.Instrumentation.callActivityOnPostCreate(Instrumentation.java:1381) 07-04 20:45:25.312 31405 31405 E AndroidRuntime: at android.app.ActivityThread.handleStartActivity(ActivityThread.java:3374) 07-04 20:45:25.312 31405 31405 E AndroidRuntime: at android.app.servertransaction.TransactionExecutor.performLifecycleSequence(TransactionExecutor.java:221) 07-04 20:45:25.312 31405 31405 E AndroidRuntime: at android.app.servertransaction.TransactionExecutor.cycleToPath(TransactionExecutor.java:201) 07-04 20:45:25.312 31405 31405 E AndroidRuntime: at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:173) 07-04 20:45:25.312 31405 31405 E AndroidRuntime: at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:97) 07-04 20:45:25.312 31405 31405 E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2063) 07-04 20:45:25.312 31405 31405 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:107) 07-04 20:45:25.312 31405 31405 E AndroidRuntime: at android.os.Looper.loop(Looper.java:214) 07-04 20:45:25.312 31405 31405 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7615) 07-04 20:45:25.312 31405 31405 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method) 07-04 20:45:25.312 31405 31405 E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492) 07-04 20:45:25.312 31405 31405 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:964) 07-04 20:45:25.314 963 3001 I SurfaceFlinger: Create BufferLayer(0x728a97c000) Splash Screen com.android.settings@4086#0 (720 x 1560) 07-04 20:45:25.317 4086 31568 I DropBoxManagerService: add tag=data_app_crash isTagEnabled=true flags=0x2 07-04 20:45:25.317 4086 14452 W ActivityTaskManager: Force finishing activity com.mywebapp/.ReceiverActivity 07-04 20:45:25.318 4086 14452 W ActivityTaskManager: Force finishing activity com.android.chrome/org.chromium.chrome.browser.customtabs.TranslucentCustomTabActivity
I wonder how did you do differently, that doesn't cause this crash for you.
Thank you very much.
After doing some quick research about this error,
java.lang.IllegalStateException: You need to use a Theme.AppCompat theme (or descendant) with this activity.
I replaced this:
android:theme="@style/Theme.AppCompat.Light">
With this:
android:theme="@style/Theme.AppCompat.Light.NoActionBar.FullScreen">
Created a file res/values/styles.xml, where I added this:
<?xml version="1.0" encoding="utf-8"?>
<resources>
<style name="Theme.AppCompat.Light.NoActionBar.FullScreen" parent="@style/Theme.AppCompat.Light.NoActionBar">
<item name="android:windowNoTitle">true</item>
<item name="android:windowActionBar">false</item>
<item name="android:windowFullscreen">true</item>
<item name="android:windowContentOverlay">@null</item>
</style>
</resources>
Now the app doesn't seem to crash, but when I go "back" from the "Notifications Settings" view, what shows me is a 100% while fullscreen view.
If I press Back again, I go back to my app.
It'd be nice to not have that intermediary blank/100% white view, though, and go back directly to my webapp.
The other thing is that, with the "fix/workaround" above, once I enable the Notifications in that "Notifications Settings" view, and go back to my webapp, the webapp still thinks the Notifications are not enabled.
So, at the moment, it's actually Good that the app fully crashes, so that the user has to re-open it, which will then take the new permissions in...
So the 100% fullscreen white view is ReceiverActivity, which it looks like you aren't doing anything with (as in, it doesn't have any UI that you want the user to interact with). You should call finish() at the end of onCreate so that ReceiverActivity gets closed once you've launched the Settings Activity.
You're right that there's no way for the TWA shell to tell Chrome "look, my notification permission has updated, please notice" short of restarting the TWA, we could open a feature request for that.
So the 100% fullscreen white view is ReceiverActivity, which it looks like you aren't doing anything with (as in, it doesn't have any UI that you want the user to interact with). You should call finish() at the end of onCreate so that ReceiverActivity gets closed once you've launched the Settings Activity.
Ah, makes total sense - thank you for that.
we could open a feature request for that.
Great. Is this on bubblewrap's side, or Google Chrome side?
If it can be done on bubblewrap's side, is it something that will also work with any other browser, such as Firefox, Brave, etc?
I can open the feature request, once I know in which project :) Thank you very much.
You should file the Feature Request with Chrome, if there are also bubblewrap changes needed, the Chrome FR will be suitable for them too.
It probably won't be picked up by Firefox (but I don't know how Firefox works with TWA notifications at the moment). I'm also not sure about Brave, it depends on how much Chromium code they customize.
You could make this work in bubblewrap by relaunching the TWA when the user returns from settings, but that would be a bad user experience - they'd lose their page.
Closing this as it looks like a feature-request for Chrome instead.
Raised - https://bugs.chromium.org/p/chromium/issues/detail?id=1419651
Please star that Bug, to give a bit of exposure. Thanks!