>Couldn't you get around this by having the user install something using the session API which then installs the malicious app that uses the a11y API - it might

>Couldn't you get around this by having the user install something using the session API which then installs the malicious app that uses the a11y API - it might require convincing the user to click through another install, but I'm not sure how much of a barrier that actually is. Just a note here, but the restriction isn't "chained". The malicious app using the a11y API itself only needs to be installed via an installer using the session-based API. So a "dropper" app implementing the session-based API could pull the APK for the malicious a11y using app from some source and then ask the user to install it. The malicious app's accessibility service could then be enabled. Yes, this is a loophole, but if Google didn't do this, then you wouldn't be able to enable an app's accessibility service no matter where it was sourced from. And Google's already in hot water with the EU, so I don't think they want to get in trouble for hindering 3P app stores. However, I still think this targeted approach is smart. A lot of apps that users use to download and sideload apps (browsers, mail clients, messaging apps) have no reason to go and implement the session-based installer API, so this restriction would add at least one more barrier to apps gaining a11y access.