There is an app on the Google "Play Store" called "Screen Filter", which is designed to cover the entire screen with some translucent black, to allow the screen to be dimmer than the minimum brightness.
It does this using a permission called "Display System-Level Alerts".
Where is the documentation that allows me to do this in my app?
Can this "system-level alert" intercept touch events? This is so I can get my app to take over an Android that is supposed to stay in our building.
I like this approach because it prevents the phone from being turned off before it is turned over (which would trigger an alarm), unless of course there is a hammer involved.
Docs for Manifest.Permission show that the SYSTEM_ALERT_WINDOW is the permission you are looking for. You would declare this permission in the Manifest and then in a Dialog or any other kind of Window you would set this flag WindowManager.LayoutParams.TYPE_SYSTEM_ALERT. So for a Dialog it would look like this:
dialog.getWindow().setType(WindowManager.LayoutParams.TYPE_SYSTEM_ALERT);
Yes, it will be able to intercept touch events. System alerts, like a low battery warning, always open on top of all other applications, so whatever Window you pop up will take focus, etc. Based on what you want to do with this, I'd imagine you could do something like: pop up a Dialog (as a system level alert) which needs a password to make it go away.
Related
iam developing screenlock app for android using a React Native and a little annoyed with the screen pinned dialog that always appears, is there a way to just get rid of it? so what I really want is no dialogue interaction at all with the user
enter image description here
If you're calling startLockTask() and your device isn't set up as a dedicated device with your app whitelisted, then no you can't prevent it:
Otherwise, the current task will be launched into screen pinning mode. In this case, the system will prompt the user with a dialog requesting permission to use this mode. The user can exit at any time through instructions shown on the request dialog.
The dialog is there to help users understand what's happening, give permission for the app to take over their screen, and know how to get out of it later. It's baked into Android by design, so malicious apps can't cause problems - it's just a limitation you have to deal with, unless you're working with a dedicated device (which can be set up to give apps more control and users less)
Have you thought about immersive mode instead, where you hide the nav bar? The user can get out of that too by swiping to reveal the controls, but it's less intrusive. There's no way to automatically lock the user's screen with no interaction though
Basically what's happening here is an overlay being displayed on any screen (meaning it is not a dialog, nor a notification, nor a ui service)
The closest I can think of is a custom toast message, where toasts usually lasts on any screen at any app, but toasts can't last more than 3.5 seconds as shown here
I need to do something like this, since I need the user to be alerted about an incoming order that he needs to be responding to.
Anything close is welcomed
read about SYSTEM_ALERT_WINDOW permission. it will allow you to drawn on screen on top on your/other apps
BUT afaik above perm will let you draw on top other apps, but not covering system GUI. on your GIF sticky widget with timer is drawn also on top of notifications, thats not possible in Android system even with SYSTEM_ALERT_WINDOW. so yet again Samsung (in fact any manufacturer) modified Android and adjusted to own purposes, made some new possibilities and gave proper permissions for own apps... and you won't use them as you don't know/have API and don't have privileges, which you can't even ask for
With the new Android 12 operating system, the user now has the ability to completely disable microphone and camera usage from ALL apps. This is actually a good thing, letting users easily control privacy.
If an app starts and has permission to use the microphone and the camera AND the user has disabled all access to either of these hardware, Android 12 automatically pops up an alert asking the user to re-enable the microphone or camera, or to continue with the hardware disabled for the app.
Also, on creation, the app can simply check when starting to see if the needed hardware is enabled, and can also prompt the user further or handle the condition as the app sees fit.
But what if the user disables the microphone or camera while the app is running? I can't seem to find any interfaces for something like onMicrophoneEnabled() or even a Broadcast of such an event.
It's possible to check every time onResume() is called, but I was hoping there'd be a more elegant solution.
If anyone knows of something that my app can use to capture this when the user has made changes either way, please let me know.
After carefully reading the google docs (https://developer.android.com/training/permissions/explaining-access#toggles) on their implementation of the user enable/disable of the camera and microphone I discovered something very interesting:
Apps are explicitly forbidden from knowing if the user has done any of these actions. So of course there is no way to get notified of these changes: it is by design.
If the user turns off the camera this way, the app will still get a camera feed, but it will be black. Similarly the microphone will still work, but we'll get only silence. This is a feature--a way to ensure privacy.
The operating system will remind users that they have disabled the microphone or camera and provide a chance to re-enable the hardware, which is nice. But the app is completely in the dark (hehe).
Another way to think of it: Just like putting a piece of tape over your camera or your thumb over the microphone. Only this time it's done by the operating system. This way a spy program or some other nefarious software will still think it's working and not try to bypass or give up.
This also explains why testing during onResume() or onWindowFocusChanged() didn't work either. I was getting results that didn't align with the settings (they aligned with current permissions).
So to answer my question: There is no way to be notified. That is the point.
I am trying to set priority for a payment card in a foreground activity, but setPreferedPaymentService() won't work until categoryAllowsForegroundPreference() returns true. However, this is tied to the "Foreground priority" (NFC_PAYMENT_FOREGROUND) system setting.
Has someone encountered a similar problem? How can I change that setting programmatically?
The whole point of the the setting "Foreground priority: Use payment app in foreground, even over default" (Settings.Secure.NFC_PAYMENT_FOREGROUND) is to give the device user an option to prevent apps from doing exactly this. Consequently, if there was a programmatic way to re-enable this option (after the user intentionally disabled it), having this option would be pointless.
Therefore, the answer is: You can't programmatically enable that system setting from your app.
However, what you can do is ask the user to reconsider their choice. You could do this, for instance, by sending a CardEmulation.ACTION_CHANGE_DEFAULT intent to let the user select your app as the default. Or you could navigate the user to the Tap & pay settings (using a Settings.ACTION_NFC_PAYMENT_SETTINGS intent).
I'm facing a issue on the devices with Marshmallow + and i'm trying to find out a solution programmatically. When ever the code executes for asking user a dangerous permission a "screen overlay detected" popUp appears and takes the user to "Draw Over apps" Settings. It's hard for a user to determine which app to select to turn off the overlay feature. A very ordinary user might get confused what to do and could see it as a gimmick, would simply press back button and kill the app. Turn out to be a bad user experience.
It may be not rally necessary to turn off this feature. Is there a way to handle this programmatically. By pass this Popup and stay on the main track?