Allow custom toasts only if app has resumed activity
Bug linked is a vulnerability where an app starts an external activity that it wants the user to interact with along with repeatedly posting custom toasts with the intent of redressing the UI of the activity just launched. The activity that is being started is translucent, so the check for IMPORTANCE_FOREGROUND wasn't working because activity manager was still considering the process foreground since it had a visible activity. Thus, changing our logic to only enable custom toasts in case the app has a resumed activity. This has the following implications in the cases below: * Translucent activity on top: Block toasts * Multi-window: Allow toasts * Bubble: Allows when bubble is expanded (it's a resumed activity) * SAW: Probably block, but fine since app can already do what they want * onCreate(), onStart(), onResume(): Allow toasts * onPause(), onStop(), onDestroy(): Block toasts Note that custom toasts are deprecated and we haven't specified what exactly "foreground" or "background" meant in this context, so we have some flexibility in the implementation. Bug: 115385786 Test: From an app start a translucent activity from another package and then try to post a toast, verify the toast is blocked. Test: atest ToastUITest android.widget.cts.ToastTest android.widget.cts29.ToastTest android.server.wm.ToastTest Change-Id: Ia434332e066f1ef2cd01e150b087f8e5117f1e63
Loading
Please register or sign in to comment