21

I'm working on an SDK that is putting a popup view on the WindowManager using the TYPE_TOAST LayoutParams type. The last version of Android Nougat (7.1.1) made some change to the WindowManager (I don't know yet what change exactly - would be grateful if someone could elaborate) but this change causes all views that were added with the TYPE_TOAST type to be removed from the window after activity transition.

I can't add a request for any permissions, so I can't use the types that require the SYSTEM_ALERT_WINDOW permission.

Tried to add the view each time after the transition is made, but those views are removed almost as soon as I added them. (again I'm guessing because of some change that was made to the WindowManager)

So the question is: Does someone know of some alternative I can use to show the popup view as an overlay on the application for as long as the application is alive and on foreground?

halfer
  • 19,824
  • 17
  • 99
  • 186
Emil Adz
  • 40,709
  • 36
  • 140
  • 187
  • 1
    You do not need to request `SYSTEM_ALERT_WINDOW`, [much to my great irritation](https://commonsware.com/blog/2017/05/11/system_alert_window-updates.html). However, in my work to fix [this bug](https://github.com/commonsguy/cwac-presentation/issues/9), I did not see any alternative to `TYPE_TOAST`. In my case, since I am trying to display content on an external display, Android O solves this with its new multi-display approach, leaving Android 7.1 as the only troublesome release. – CommonsWare May 29 '17 at 11:19
  • @CommonsWare in case of TYPE_TOAST you don't need to ask SYSTEM_ALERT_WINDOW permission. but in case you use any other type like TYPE_SYSTEM_ALERT, TYPE_APPLICATION_OVERLAY, TYPE_SYSTEM_DIALOG, TYPE_SYSTEM_OVERLAY or TYPE_SYSTEM_ERROR this permission is required. You are right regarding your case, but what will you do about Android 7.1? – Emil Adz May 29 '17 at 13:07
  • "this permission is required" -- sorry, by "do not need to request", I meant that the user does not need to do anything to grant the permission to you. You still need the `` element in the manifest, though. "what will you do about Android 7.1?" -- use `TYPE_SYSTEM_ALERT` and therefore require `SYSTEM_ALERT_WINDOW`. – CommonsWare May 29 '17 at 13:16
  • From my tests I saw that setting is not enough. On devices with Android 6 and above you also need to place the requestPermission functionality in the first activity... what results in new screen that opens up before the application with a switch button that the use has to tick in order to allow the application to draw those views. failure to request this permission will result in a crash, when you try to present such a view. – Emil Adz May 29 '17 at 13:21
  • "On devices with Android 6 and above you also need to place the requestPermission functionality in the first activity" -- `SYSTEM_ALERT_WINDOW` is not a `dangerous` permission (see [the manifest](https://android.googlesource.com/platform/frameworks/base/+/master/core/res/AndroidManifest.xml)) and therefore does not work with `requestPermissions()`. In theory, the user needs to grant this permission manually through Settings. However, that is opt-out (not opt-in) as of Android 6.0.1. – CommonsWare May 29 '17 at 13:26
  • I was talking about ACTION_MANAGE_OVERLAY_PERMISSION: "If the app targets API level 23 or higher, the app user must explicitly grant this permission to the app through a permission management screen. The app requests the user's approval by sending an intent with action {@link android.provider.Settings#ACTION_MANAGE_OVERLAY_PERMISSION}. The app can check whether it has this authorization by calling {@link android.provider.Settings#canDrawOverlays Settings.canDrawOverlays()}." – Emil Adz May 29 '17 at 13:29
  • Right. That's what is needed in theory. In practice, apps are granted draw-overlays rights automatically, requiring the user to opt out, rather than opt in. It's why I have an app (my `SAWMonitor` book sample) installed on my "daily driver" device, just to watch for apps that I might install that might request the `SYSTEM_ALERT_WINDOW` permission in the manifest, so I can go into Settings and opt out. – CommonsWare May 29 '17 at 13:33
  • Weird, because I was facing a crash (can't remember right now the exact exception) when I did used the TYPE_SYSTEM_OVERLAY and didn't explicitly requested this permission using the requestPermissions. If I'm not mistaken it was something like this: https://stackoverflow.com/questions/7569937/unable-to-add-window-android-view-viewrootw44da9bc0-permission-denied-for-t – Emil Adz May 29 '17 at 13:35
  • It's possible that the opt-in/opt-out default varies by device model or something. Check Point, as I mentioned in my blog post, seems to think it is fairly common. I have not been able to reliably reproduce a scenario where an app *doesn't* automatically get it, but I have tested this mostly on Nexus devices. – CommonsWare May 29 '17 at 13:40
  • Ok, I will keep testing. But correct me if I wrong, right now there is no way to reproduce the functionality that was provided using TYPE_TOAST.... without requesting the user for any permission and without specifying any permission in the manifest file? – Emil Adz May 29 '17 at 13:46
  • 1
    I have not found a way to reproduce the Android 7.0-and-earlier `TYPE_TOAST` functionality. I cannot rule out the possibility that there is a way to do so, as it's not like I spent weeks and weeks on the problem. :-) – CommonsWare May 29 '17 at 13:48
  • Ok, then I will keep looking... Thanks for your help @CommonsWare :) – Emil Adz May 29 '17 at 13:49
  • @EmilAdz were you lucky? – natario Oct 04 '17 at 15:10
  • @natario, no, I wasn't. – Emil Adz Oct 30 '17 at 14:36

0 Answers0