The same constant is defined today with slightly different names in both
WindowMananagerService and ActivityTaskManagerService. To prevent
proliferation, make a constant in aidl and use it here.
Also, the two constants used to be in either nanoseconds or
milliseconds.
Make all constants in milliseconds because aidl does not support "const
long", and 5 seconds' worth of nanoseconds does not fit into an int.
Bug: 143459140
Test: interact with device after booting
Test: adb shell dumpsys input
Change-Id: Ia9b3f56d8eddcc6f2f0132bac9254655b180837f
Change-Id: If4d40b63c41f6fb54b99d167da8db1924945f3ef
Revert "Add dedicated host side tests for permissions and appops"
Revert submission 12102534-PermAppOpsCrossUserCheck
Reason for revert: b/162582513
Reverted Changes:
I04256a51e:Check cross-user interactions for permissions and ...
Iea58db070:Add dedicated host side tests for permissions and ...
Change-Id: I4823d6660f3ef403451a74612d961a0bdd477116
This change renames arguments and fields added for the purpose of app
enumeration in R to be more inclusive.
Test: atest AppsFilterTest AppEnumerationTests
Change-Id: I97ff73291d328b0ce1bf713c726371932c067c10
We want to be quite permissive here as without being able to check
permissions or appops nothing else works. Hence allow cross-user
interactions if any cross-user permission is granted.
Also we need to prevent infinite recursion as we are checking permission
and appops inside of permission and app-op checks.
Test: atest CtsPermissionHostTestCases CtsAppOpHostTestCases which
execute the new paths for both full users and profiles
Fixes: 153996875
Change-Id: I04256a51e7f6c3658000ca7941654aea698b3199
Show a warning toast when an app starts an activity inside a broadcast
receiver in response to a notification or notification action click.
This is to gather dogfood feedback in preparation for blocking such
activity starts. See go/notification-trampolines for more info. For now,
only taking care of broadcast receivers, the services case will be in a
future CL.
The toast is only shown once per package. This is to avoid annoying
dogfooders.
The actual block will be gated on targetSdk, however since very few
apps (any?) will be targeting the latest SDK on dogfood and we are still
allowing the activity start, we're going to show a toast regardless of
targetSdk to collect more feedback.
A side-effect of the way we implemented the rule that allowed
notification trampolines in BAL is that in the case that the user clicks
on a broadcast/service-trampoline notification of an app that also
happens to be in the foreground (on top for example) we can't
differentiate if an activity start came from the broadcast/service or
from the activity itself (or some other part of the app). Because of
this, in this case, we won't show the warning toast (and I'd say we
might not block the launch in the future, but this discussion can wait).
Implementation:
We determine at PendingIntent fire time if the receiver is allowed to
start activities. However, we pass a boolean to represent the grant to
start activities and this boolean also takes into account another case
that allows such starts. To correctly identify at activity start time
that it was allowed due to notification-click scenario we pass in the
token that was embeded in the PendingIntent (and was validated in the
PendingIntentRecord) by notification manager.
The set of components in ProcessRecord becomes a map to contain the
originating tokens. Since now WindowProcessController needs to have the
token to trace back the grant, I've replaced the boolean flag with the
map from ProcessRecord. We move the grant rule to the bottom of the
method areBackgroundActivityStartsAllowed() to make sure the start was
allowed exclusively due to notification-click interaction.
We then let notification manager register a callback with activity task
manager that will be called whenever a background activity start is
allowed exclusively due to a token provided in that callback. In that
callback we show the warning toast.
Test: atest BroadcastRecordTest BackgroundActivityLaunchTest
ActivityStartControllerTests ActivityStarterTests
RecentsAnimationTest WindowProcessControllerMapTests
WindowProcessControllerMapTests
Test: Posted a broadcast-trampoline notification, clicked on it and
observed the toast was shown.
Change-Id: Ica479d7d2f6b5f2ddaac4c59e12d0b25cd637717
When constructing a classloader for a different app, don't include
it's private data dir in libraryPermittedPath if we don't have access
to it. (Which we often won't, although it depends on target SDK,
whether it has a shared UID, etc.)
This avoids generating SELinux denials at boot and other times,
e.g. when initialising WebView.
Bug: 161356067
Test: Boots, denials not seen, WebView works.
Change-Id: Ib246af979783e80fde3313f8aed6c3b7a886e6b2
Since Android 7.0, partners were able to export some of their native
shared libraries to apps. So far, the native libraries were provided to
all apps regardless of whether they are actually needed or not. Even
worse, it was impossible to prevent the installation of an app to the
device where the some (or all) of the required native libs don't exist;
the apps had to manually handle the case, which sometimes impossible
when the dependency is so fundamental.
This change introduces a new tag <uses-native-library> to the app
manifest. Similary to the existing <uses-library> tag which is for
(java) shared libraries, the new tag is used to describe the depedencies
to the native shared libraries.
Apps targeting Android S or higher are required to use the tag to import
the native shared libraries. Libraries that are not depended on won't be
available to the app even if the libraries are listed in the
public.libraries*.txt files. Furthermore, when the dependency can't be
satisfied for an app, the package manager refejects installing the app.
The dependency can be optional using the `android:required` attribute.
When it is set to true, the absence of the lib on the device doesn't
prevent the app from being installed. However, the app has to gracefully
deal with the absence.
The changed behavior only affects apps targeting S or higher. Existing
apps are unaffected; they still get all the public native libraries
regardless of whether they have <uses-native-library> tags or not; the
tags are simply ignored.
This is the first version of the implementation and therefore needs
further refinements. The followings are two major TODOs.
1) The native shared lib dependencies of the java shared libraries
are not enforced. For example, if an app depends on a java shared
library foo and foo depends on some native shared libraries, the
classloader where code from foo is loaded still gets all native shared
libraries. This should be fixed.
2) New APIs should be added. SharedLibraryInfo should be extended to
represent native shared libraries. The meaning of
ApplicationInfo.sharedLibraryFiles should be revised. Finally, the new
tag should be made public.
Bug: 142191088
Test: atest CtsUsesNativeLibraryTest
Change-Id: Iceb038aa86872d23e9faf582ae91b1fdcaf5c64c
This CL adds a system API to NotificationManager for checking whether
the NotificationListener for the current package name and user id is
enabled or not.
This replaces existing implementation which was using binder calls
directly to NotificationManagerService.
Bug: 160762852
Test: atest CtsMediaHostTestCases:\
android.media.session.cts.MediaSessionManagerHostTest\
#testGetActiveSessions_withSession2
-> MediaSessionManager#getActiveSessions verifies call by checking if
the notification listener is currently enabled.
Change-Id: Ic730b0abfe08c40171062421b2015be9cc05310a
