Develop Reference

How to make my app pop up when I detect a certain event?

Note: This was originally posted on Android Enthusiasts Stack Exchange but is now moved here because it was found to be off-topic there
Kaspersky Safe Kids, a parental control app, has a feature where it would pop up every time it detects an event that the child was not meant to do (open an app, open anything related to its settings, search something banned on Google and Youtube -- interestingly enough, it doesn't work on other Chromium-based browsers). I've been trying to figure out how it can detect events for my own app, but the usual culprits like the permissions GET_TASKS and READ_LOGS are depreciated (I'm trying to target, and Kaspersky works on, Android 10+). For the actual overlay, I thought it used SYSTEM_ALERT_WINDOW, but in my own experiments in an emulator, when I revoked that permission, it was still able to pop up. So, how does it work, and what permissions do they (and I'm guessing other similar control and productivity apps) work?
The app is Device Admin, so that may play a role, but looking at the permissions a Device Admin has, none of them look like the permissions Kaspersky has.
EDIT: In the comments, Mike M. noted that the app uses Accessibility Services (don't know how I missed that), which makes sense as Accessibility allows you to do quite a lot, including showing your own UI. Coincidentally, a review on the app itself states that the process ends at random times (not sure which process though), probably because it was not whitelisted. I then took a look at its permissions and this one stood out: android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. This permission allows it to be whitelisted, so that power saving modes don't kill the background processes. For the accessibility itself, android.permission.BIND_ACCESSIBILITY_SERVICE is the permission used to grant it (for the record, you must use adb shell appops set com.kaspersky.safekids android.permission.BIND_ACCESSIBILITY_SERVICE [allow|ignore|deny], not adb shell pm [grant|revoke] com.kaspersky.safekids android.permission.BIND_ACCESSIBILITY_SERVICE (though the android may have to be replaced with Manifest) as BIND_ACCESSIBILITY_SERVICE is a signature permission. For completeness, for Admin, it's android.permission.BIND_DEVICE_ADMIN.

I was able to narrow down the exact permission used -- using ADB OTG (I didn't have a computer near me, so I used my spare Pixel) I did appops set com.kaspersky.safekids BIND_ACCESSIBILITY_SERVICE ignore (I belive deny would work too). Restarted it, and no more pop up. Changed the ignore to allow, then rebooted, and it worked again.

Options for dealing with Android 6.0's new permissions requirements from a service or model component?

I'm looking into porting some existing code to take Android M's new way of dealing with permissions into consideration. However the permission API needs to have an activity associated with it (for example the requestPermissions() method's first parameter is an activity).
So how should a service that needs to check if a permissions has been granted and request for permissions use this new API if the service doesn't have an activity?
Is it possible for the service to create a dummy invisible activity just for use with the permissions API? (if its possible I don't like the thought of doing that anyway though).
Or suppose its not a service but a model class that needs to perform a permissions check, in MVC a model shouldn't have any knowledge of the Vs and Cs and yet now either it has to in order to know which Activity to use with the permission API. Or potentially lots of code might have to migrate from model code into Activity code.
Any thoughts on how to migrate non activity based code that needs to check/prompt for permissions over to Android 6.0?
Update: I left out an important piece of information - this is code that is pre-installed (our company provides code that device manufacture's place in rom) and often may be run at device boot time and run in the background. Therefore the usual situation of a user being prompted for permission when they launch the app or later (and there therefore being an activity at that point) does not necessarily apply.

So how should a service that needs to check if a permissions has been granted and request for permissions use this new API if the service doesn't have an activity?
There is almost always an activity, except for pre-installed apps and plugins for other apps. Otherwise, your service is unlikely to ever run, as nothing will have used an explicit Intent to start up one of your app's components, so it will remain in the stopped state.
For the ~99.9% of Android apps that have an activity already, if the permissions are needed for the whole operation of the app, request them on first run. As Snild Dolkow notes, if the user later revokes the permission through Settings, you can detect that without an activity, then use other UI options (e.g., Notification, app widget) to let the user know that operation is suspended until they grant you the permissions again, which they would then do through your activity.
Is it possible for the service to create a dummy invisible activity just for use with the permissions API?
Presumably you can have a Theme.NoDisplay activity use requestPermissions(). However, from the user's standpoint, it will not make much sense, unless there's some alternative UI (app widget?) that they are interacting with. Popping up a permission dialog out of nowhere is unlikely to make you popular.
UPDATE 2019-06-15: Note that Android Q bans services popping up activities frmo the background. Please use a notification instead.
in MVC a model shouldn't have any knowledge of the Vs and Cs and yet now either it has to in order to know which Activity to use with the permission API
Do not touch the models until you have requested the permission, and gracefully fail if the permission is revoked. You already have to gracefully fail in other circumstances (out of disk space, no Internet connection, etc.), so a revoked permission should be handled in much the same way.
using this new 6.0 API seems like an recipe for bad design and tight coupling
You are welcome to your opinion. Based on what I have read, the Android engineers believe that asking the user for permissions is part of the user experience and is best handled at the UI layer as a result.
Again: the vast majority of Android apps will not have a problem with this, as they have a user interface. Apps that do not have a user interface and need dangerous permissions are in for some amount of rework.
this is code that is pre-installed (our company provides code that device manufacture's place in rom) and often may be run at device boot time
First, please understand that this is so far from normal that you can't even see normal from where you are due to the curvature of the Earth. :-) You can't really complain that Google did not optimize this particular scenario.
As I understand it, even system apps should be asking for runtime permissions. The Camera app did, for example, on the 6.0 preview. That being said, there's gotta be some database on the device somewhere that is tracking what has been granted, and presumably there is some way to pre-populate it. However, the user could still revoke it from Settings, presumably. But, the manufacturer could pull some stunts (e.g., messing with the Settings app) to possibly even preclude that scenario. I'd be looking in the same area as "how do I get it so my app cannot be force-stopped?" that device manufacturers can do.
Your alternatives would be to get rid of the dangerous permissions or to migrate your app off the SDK and into a standard Linux binary that would be run as part of the boot process and be put into a Linux user group that has access to the stuff that you need.

Ask for it when the user enables whatever feature your service provides. They'll be in one of your activities at the time. Yes, it means that your activities need knowledge of what permissions your services will require.
The service can always check for the permission by itself, though, since checkSelfPermission() is available in all Context instances. So you don't need an activity for that.
I guess an alternative would be to have your service post a notification saying "feature X requires you to approve more permissions". Actually, that may be a good idea regardless, in case the user goes into settings and revokes any permissions after the fact. That notification would then take the user to some activity with an "enable feature X" button/checkbox -- ask for the permission when that is selected.

You can send a notification. Look this library to manage the permissions: permission library

Which android API calls need these permission?

I'm trying to figure out which android API calls need these permissions:
android.permission.HARDWARE_TEST
android.permission.DEVICE_POWER
android.permission.DIAGNOSTIC
android.permission.GET_TOP_ACTIVITY_INFO
I read the descriptions on the Android developer website, but I found no way to perform the operations that these permissions allow.
EDIT after HexAndBugs answer: I know these permission are not intended for third-party application, but I'd like to use them in a experimental environment, playing the role of the manufacturer.

These aren't intended to be used in your apps (unless you are a device manufacturer), so you won't find things that need them in the API. Note that they all say Not for use by third-party applications. See, for example, DEVICE_POWER

Although these settings are not for usual app but if you have a rooted device and you need to control, lets say hardware test then you would have to add it to your apps permisson and override the ususal CET testing pannel
But FYI it can brick the phone or device if you tweaksomething wrong so beaware;
i personally have used couple of these permisson for e.g getTop Activity info to monitor that my app is always on foreground

how are android security permissions checked at run-time?

This question has been asked before at How does Android enforce permissions?. While the discussions there are good, the question is still not fully answered.
In the development environment, exceptions are thrown when the app tries to do something that requires permissions not declared in AndroidManifest.xml. So how does the run-time system implement the run-time checking?
I guess it's most likely done in the core framework, which may or may not need support from native code. But I don't know what source code files in AOSP are relevant to this.

Android uses a lot of the standard Linux(-kernel?) mechanisms especially when it comes to hardware restrictions.
Every app gets assigned a new unique (Linux-)user id and whenever the app process is created the system creates it with that user id. The id will never change unless you remove the app. That means for accessing the lower system levels your app will appear as a certain user and every (Linux-)permission system that works with users will also apply to your app.
If you request WRITE_EXTERNAL_STORAGE in the manifest your app will also become member of the (Linux-)group (called sdcard_rw) that has permissions to write to that storage. Permissions on the filesystem are enforced to only allow writing to the system user (=owner) and the sdcard_rw group, anyone else (=other) may only read. See also Is Google blocking apps writing to SD cards
By doing that Android has to do pretty much nothing except for setting the correct UID/GIDs of the processes it spawns once the app starts and the rest is handled at lower levels. Apps that are not member of a certain group simply don't get access to certain hardware.
List of permission <> group mappings: platform.xml
There are also some (Android software) restrictions that are based on either the signature of your app and / or simply by looking up the permissions your app requested: e.g. ContextImpl#checkPermission() - but those permissions have to be checked at every entrypoint to code that allows restricted actions.
From time to time people discover ways to e.g. turn on GPS programmatically because a check like that is missing somewhere.

With regard to your second paragraph, "exceptions" are runtime faults. Permissions are not enforced at build time, only at run time.
Accessing hardware, low level operating system resources, and system files generally requires the app userid to be a member of an appropriate group which it may be assigned by the package manager as a result of having a corresponding android permission. (Familiar examples of that would be network sockets, and the sdcard write which zapl mentioned, but also system-only things like talking directly to the GSM modem or reading the raw touchscreen coordinates).
For the majority of android operations that are done by way of calling library functions which are stubs for interprocess communication to services running in a different process, the platform code running in the more privileged process on the receiving end of the ipc request checks with the package manager to find out if the calling application has the necessary android permission.
Many special permissions are only available to apps signed with the system signature - even if another app claims those in its manifest, they will not be applied by the package manager.

Whats are the ten most deadly permissions?

I would like to know what would be the top ten most deadly permissions that can be requested by an android. I know it might be a matter of opinion, but supposing that I had the 10 permission listed in by an application, I would definitely know my application did not generate a whole lot of confidence among users. What would be the permissions I would most likely like to avoid asking the user for.
I am aware of permissions like BRICK and SHUTDOWN but since they don't apply to third party devs I would like to know only of permission which can be requested by a third party developer.
PS: need not necessarily be 10. Any number of permissions you believe might lead to the user being weary of application would be nice.

CALL_PRIVILEGED - call numbers without going through the dialer
SET_ALWAYS_FINISH - controls whether or not applications become finished when put in background. Could lead to some nasty trackers or something.
READ_CONTACTS - could lead to some data stealing for ppl to add to their spammer lists.

Here are some I found that could potentially be very dangerous (not including the ones above :)
GET_ACCOUNTS - Allows access to the list of accounts in the Accounts Service
MOUNT_FORMAT_FILESYSTEMS - Allows formatting file systems for removable storage.
PROCESS_OUTGOING_CALLS - Allows an application to monitor, modify, or abort outgoing calls.
READ_SMS - Allows an application to read SMS messages.
SEND_SMS - Allows an application to send SMS messages.
READ_EXTERNAL_STORAGE - Allows an application to read from external storage
WRITE_EXTERNAL_STORAGE - Allows an application to write to external storage
And of course the best way to transmit some of this data
INTERNET - Allows applications to open network sockets.

I think it depends on what the app is meant to be doing.
Some days ago, for example, I was looking for a task killer app, and I ended not installing any because all the "Task Killers" I saw on the market requested full internet access.
Why would they need internet access in order to kill a task?
If they wanted internet access in order to display ads then they should say so, but otherwise I take the paranoid approach and I assume it is spyware.
Other than that, I am very protective of my SIM card and contacts.

Any app which uses ACCESS_INTERNET and READ_CONTACTS could be stealing your contacts. However, there are thousands of apps in the market that have these permissions and probably aren't...

Access the list of accounts in the Accounts Service
Act as an AccountAuthenticator for the AccountManager
Access information about networks
Request authtokens from the AccountManager
I routinely check permissions before download. If the application has no business doing these, then I would not even download it . Even if it does, I would think twice whether I really, really need the app to reside on my device. And BTW - the above are part of 34 permissions coded in Skype!
If we do not know who and where the developer is, we would tend not to download software on our PC's. Yet, so many don't use this logic for their Android devices.

BRICK - Disable a device