IssueTracker

I have bugs in my system that I took screenshots of

We have looked into the request you have reported and would like to inform that

• CONFIRM_PERMISSIONS isn't AOSP, it's defined by an app or an OEM so we (Google/Android) could not make any promises regarding its functionality.

• INSTALL_PACKAGE will throw security exceptions if the app doesn't have the REQUEST_APP_INSTALL app op granted therefore the behavior is working as intended.

• Regarding APPLICATION_DETAIL_SETTINGS not working. We recommend reaching out to the respective OEM's as we are trying our best to make sure APPLICATION_DETAIL_SETTINGS is supported.

Could you verify that the intent names listed in the above description are correct? The terms like:

• INSTALL_PACKAGE and not INSTALL_PACKAGES
• USAGE_ACCESS_SETTINGS and not ACTION_USAGE_ACCESS_SETTINGS

@28 I've specified multiple permissions already as examples. Not as the only things that should be checked. Of course you can read more that should be publicly available and working and make sure that OEMs keep them working as well.

As for the specific ones you've mentioned, it's Intent.ACTION_INSTALL_PACKAGE ("android.intent.action.INSTALL_PACKAGE").and Settings.ACTION_USAGE_ACCESS_SETTINGS ("android.settings.USAGE_ACCESS_SETTINGS").

Sadly the links don't show me the exceptions/crashes anymore because it's too far in the past (can reach only up to 90 days). The original request is from 2017... These things should be available for all devices.

ACTION_ADD_DEVICE_ADMIN is covered by cts/DeviceAdminActivationTest.java, if this is failing on a recent Android version, please file a ticket for it specifically, so we can make sure the use case is covered by CTS.

ACTION_INSTALL_PACKAGE requires REQUEST_INSTALL_PACKAGES when targeting API 25+ and is covered by cts/RequiredComponentsTest.java. This was deprecated in 29 in favor of using PackageInstaller. That means it's unlikely that any bugs related to this would get fixed for old Android versions.

CONFIRM_PERMISSIONS sounds like it's not an AOSP expectation per #24

An action string existing does not guarantee there is an intent filter on the device that can handle it, so you should always guard launching intents that are outside of your control with try/catch. If an intent is not required to be handled, the docs should indicate such with "In some cases, a matching Activity may not exist, so ensure you safeguard against this." That's the case for ACTION_ACCESSIBILITY_SETTINGS, ACTION_APPLICATION_DETAILS_SETTINGS, ACTION_USAGE_ACCESS_SETTINGS, etc.

Why don't you add text&button for each such protected Intent (Intent that you promise should work by the tests) into the docs

You could say the same thing for any virtually API in Android ("if it doesn't work as described, report it"), so I don't think it makes sense to put a button in each individual constant. If the problem is that the "In some cases, a matching Activity may not exist, so ensure you safeguard against this" warning isn't clear enough or is missing from Intents where it should be included, then we can fix that.

ACTION_ADD_DEVICE_ADMIN - It's not recent. It's Android 9 that I've shown you the report of it.

Unfortunately, if the OS/phone is ~6 years old, there's not a lot we can do about it, which is why I suggested filing a ticket if it's happening on a newer device. Hopefully if it's only happening on an older device, then that indicates it has since been fixed but that fix didn't roll out to all older devices.

ACTION_INSTALL_PACKAGE - I already have this permission declared.

Is this only happening on the one device that's >10 years old (SecurityException on "JP5s Inmate Media Device" Android 4.2.2)? REQUEST_INSTALL_PACKAGES was introduced in API level 23, which is newer than the OS the device is running, so that wouldn't have any affect. Given that this is an inmate device, I wouldn't be surprised if using a 3rd party app to install an arbitrary APK is specifically locked down and throws an exception.

CONFIRM_PERMISSIONS - Really this should not happen then. I've noticed there are also Admob crashes of this sort:

SecurityException: addOnPermissionsChangeListener: Neither user 10578 nor current process has android.permission.OBSERVE_GRANT_REVOKE_PERMISSIONS.

Is this also not part of AOSP ? If so, why does Admob try to use it?

I don't know where "CONFIRM_PERMISSIONS" is defined. It's not part of AOSP. "android.permission.OBSERVE_GRANT_REVOKE_PERMISSIONS" is a system permission. As far as I know, it's not used by Admob but is probably used by system services such as gmscore.

About guarantee, shouldn't CTS reduce such crashes, so that there would be a better standard ?

Android attempts to balance the need for flexibility from OEMs and users with the need for consistency for app developers. The CTS tests drastically reduce crashes and variability in API behavior, but Android is a massive codebase. Android has millions of CTS tests, but it's impossible to predict every way that every individual API could be changed. We can add new CTS tests as issues are reported to ensure behavior for each new version of Android, but they can't 'fix' old Android versions that have already shipped to the public.

Some intents are very important and there is no way to overcome by having some fallback. Just telling the user it's impossible on the device...

If there's specific intent that you believe should be required to be supported by all devices, then you can file a ticket for that intent with details about your use case and the user impact of not having the functionality on all devices. The more specific a ticket, the more likely it can get routed to the expert for that particular aspect of Android and that person will have much more context on whether that intent makes sense for all possible use cases of AOSP.