The new hidden app detail activity was being added to all packages being
installed, even static shared libraries, which may not have any
activities and which we do not want to surface to the user in launcher.
Change-Id: I80e7d379abed04f2464d1dc7e8b75456e43063f4
Fixes: 118145903
Test: atest android.os.cts.StaticSharedLibsHostTests
Bug: 117841084
Test: atest CtsAtraceHostTestCases:AtraceHostTest
Allow apps to opt-in to important profiling features (systrace, binder
tracing), without requiring debuggable=true. Debuggable has
significant performance overhead, and is undesirable for profiling.
Profileable is set to true when debuggable is true.
Change-Id: I16aaa7bc60dee4b1b262e169ac285759d57d8198
To support teamfooding of the new storage privacy features coming
in Q, we need apps to request new AUDIO/VIDEO/IMAGES permissions, but
most of those apps are prebuilts that won't land updates until
several months in the future.
So add system properties so teamfooders can "force" apps to request
these permissions, making them work on Q builds. Only takes effect
when isolated feature is enabled, and guarded with STOPSHIP to ensure
we remove it.
Here's a typical set of commands to use with this CL:
adb shell setprop persist.fw.force_legacy 1
- or -
adb shell setprop persist.fw.force_audio com.google.android.music
adb shell setprop persist.fw.force_video com.google.android.apps.photos
adb shell setprop persist.fw.force_images com.google.android.apps.photos,com.google.android.apps.messaging
- then -
adb shell setprop persist.sys.isolated_storage 1
adb reboot
Bug: 118504670
Test: manual
Change-Id: I631819648334994255256b6046bb4c8aec07ce3a
A role is a unique name within the system associated with certain
privileges. There can be multiple applications qualifying for a role,
but only a subset of them can become role holders. To qualify for a
role, an application must meet certain requirements, including
defining certain components in its manifest. Then the application will
need user consent to become the role holder.
Upon becoming a role holder, the application may be granted certain
privileges that are role specific. When an application loses its role,
these privileges will also be revoked.
Bug: 110557011
Test: build
Change-Id: Icd453a3b032857a8fd157048de8b9609f04e28b8
As part of the storage changes in Q, we're removing the ability for
apps to directly access storage devices like /sdcard/. (Instead,
they'll need to go through ContentResolver.openFileDescriptor() to
gain access.) However, in several places we're returning raw
filesystem paths in the "_data" column. An initial attempt to simply
redact these with "/dev/null" shows that many popular apps are
depending on these paths, and become non-functional.
So we need to somehow return "_data" paths that apps can manually
open. We explored tricks like /proc/self/fd/ and FUSE, but neither
of those are feasible. Instead, we've created a cursor that returns
paths of this form:
/mnt/content/media/audio/12
And we then hook Libcore.os to intercept open() syscalls made by
Java code and redirect these to CR.openFileDescriptor() with Uris
like this:
content://media/audio/12
This appears to be enough to keep most popular apps working! Note
that it doesn't support apps that try opening the returned paths
from native code, which we'll hopefully be solving via direct
developer outreach.
Since this feature is a bit risky, it's guarded with a feature flag
that's disabled by default; a future CL will actually enable it,
offering a simple CL to revert in the case of trouble.
Bug: 111268862, 111960973
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: Ied15e62b46852aef73725f63d7648da390c4e03e
Instead of maintaining local copy of all appIds and sandboxIds,
StorageManagerService will just get required packages info
from PackageManagerService when an user starts and passes it
to vold.
Bug: 117988901
Test: manual
Change-Id: Ib7411645bd0c5e2801bc998d92fda00bceb9c258
- Create a check file for each database in order to detect
1) an unexpected DB file removal
2) DB wipe caused by a DB corruption.
- Either case, do a WTF to collect information on APR.
- Also print file timestamps in "dumpsys dbinfo". Example:
=====================
Database files in /data/system:
locksettings.db 20480b ctime=2018-10-23T22:48:35Z mtime=2018-10-23T22:48:35Z atime=2018-10-23T18:54:12Z
locksettings.db-wipecheck 0b ctime=2018-10-23T18:54:12Z mtime=2018-10-23T18:54:12Z atime=2018-10-23T18:54:12Z
notification_log.db 45056b ctime=2018-10-23T22:48:08Z mtime=2018-10-23T22:48:08Z atime=2018-10-23T18:54:13Z
:
=====================
Change-Id: I77fbeb0bb635c787aba797412f116475fecbe41c
Fixes: 117886381
Test: manual test
Test 1: corruption
1. Stop CP2 process (adb shell killall android.process.acore)
2. shell 'echo abc > /data/user/0/com.android.providers.contacts/databases/contacts2.db'
3. Launch the contacts app.
Test 2: Unexpected file removal
1. Stop CP2 process (adb shell killall android.process.acore)
2. shell 'rm -f /data/user/0/com.android.providers.contacts/databases/contacts2.db'
3. Launch the contacts app.
In both cases, logcat shows a client side stacktrace and also a WTF. (am_wtf)
Process BOOT_COMPLETED on this new queue
Change-Id: I14e7e7cc42f02b38a9becb47f7913684f55979fa
Test: boot device, dumpsys activity broadcasts
Bug: 111368744
ContentProvider has a getCallingPackage() method, which verifies
the remote package name against the current Binder identity. When a
provider wants to clear that IPC identity, they need to clear both
the Binder state and the ContentProvider.getCallingPackage() state
together, so add methods to facilitate that.
Also fix subtle bug so we don't try translating relative paths.
Bug: 117627072
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: Ifa3e1f745334abf625fdcc314b308a047c49ce73
This intent is used by the Permissions Hub.
We also give PermissionController the GET_APP_OPS_STATS permission.
Bug: 63532550
Test: Used the Permissions Hub.
Change-Id: If1254f67c12fc5052d6ad5ff8260778a7c59dccc
Obtaining a thumbnail for a Uri requires opening it with the slightly
obscure openTypedAssetFileDescriptor(), passing in "image/*" with the
right Bundle of EXTRA_SIZE to hint the target area on screen, and
defensively scaling any returned results.
This is pretty tedious to get right, so offer a convenience method
that does all this for the developer. Internally uses ImageDecoder
to follow best-practices, and replaces older getDocumentThumbnail()
implementation by delegating to this one.
A future CL will teach ImageDecoder about how to read any embedded
EXIF thumbnails, including any required rotation.
Bug: 111268862
Test: atest FrameworksCoreTests:android.content.ContentResolverTest
Change-Id: I5c9c09ddf9b480f3b5c6ade0a078cccb68de2f2b
These two libraries:
android.hidl.base-V1.0-java
android.hidl.manager-V1.0-java
were removed from BOOT_JARS. This change disallows them to be used on
the classpath >= Q. They are still allowed to be used <= P for legacy
reasons.
Test: atest android.content.pm.AndroidHidlUpdaterTest
Test: build & boot Pixel 2
Fixes: 77307025
Change-Id: I7752812318030cbaa15f42301c168371ceade901
Any app loading untrusted strings should make the strings face. Hence make
the method publicly available.
Test: atest CtsTextTestCases:MakeSafeForPresentationTest GtsContentTestCases:PackageItemInfoTests
Change-Id: Ib0679fe892181535339dac77583c427e0d64dd05
Fixes: 113856697
ContextImpl has an internal rule that when ContextImpl#mDisplay is
null the Context is associated with the default display. The problem
is that, as discussed in Bug 117709581, when ContextImpl#mDisplay is
null ContextImpl#getDisplay() tries to get some non-null Display
object by making an IPC to the system server, which is redundant when
the display ID is the only thing that the caller wants to know.
By having an @hide method Context.getDisplayId(), we can ensure that
display ID can be obtained without any IPC. This enables us to
re-submit my CL [1] that aimed to instantiate InputMethodManager (IMM)
for each display but then got reverted due to a performance regression
(Bug 117434607).
There should be no developer-observable behavior change.
[1]: I7242e765426353672823fcc8277f20ac361930d7
c53d78e992
Fix: 117712745
Test: atest FrameworksCoreTests:android.content.ContextTest
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/tests/coretests/src/android/content/ContextTest.java
Change-Id: I2534530a5ce90e2620c5039d793a6454a0a1e154
The suspending app has more context about why a particular app was
suspended by the user, but we do not want to delegate the interception
of the suspended activity out of the system.
Hence allowing it further customizations to the dialog to make
it clearer.
Test: atest com.android.server.pm.SuspendDialogInfoTest \
com.android.server.pm.SuspendPackagesTest \
com.android.server.pm.PackageUserStateTest \
com.android.server.pm.PackageManagerSettingsTests \
com.android.server.am.ActivityStartInterceptorTest
atest GtsSuspendAppsPermissionTestCases GtsSuspendAppsTestCases
Bug: 112486945
Bug: 113150060
Change-Id: If9f4d14587a2b75bb572e7984a90e300a2c72d16
This CL implements the biggest chunk of launch bounds logic in Android
branch and combine ActivityLaunchParamsModifier logic into
TaskLaunchParamsModifier. It left some things to be implemented:
1) It didn't yet consider persisting/recovering data;
2) It didn't implement letterboxing/pillarboxing, but according to
offline chat this should be enforced after launch bounds policies by
system;
3) Immersive mode is not yet implemented, but that's more tied to
recovering previous immersive mode and we won't launch apps to immersive
mode directly in any case;
4) No last seen non-fullscreen bounds are set if display is fullscreen,
which could be useful when display windowing mode changes from
fullscreen to freeform at later time.
There are also some topics that for sure need future discussions, so I
left them out of this CL as well:
1) App controlled apps (not only bounds specified in ActivityOptions);
2) Metadata indicating that the app prefers tablet-like bounds for
freeform windows (i.e. w/o limiting window size to Nexus 5x screen
size);
3) Fixed maximized size, which indicates that the maximized size
shouldn't be changed due to display resolution or orientation changes;
4) What to do if app requests to launch an activity without any flag
that indicates a new task should be used, but with a preferred display
ID/bounds set to a different value than its current window;
5) Should insets be considered in launch bounds (AM side) or on WM side,
IIUC freeform windows don't need to consider insets, and fullscreen
windows are covered by WM.
Our policy also has special treatment for Chrome snapped windows
(side-by-side mode in our tablet), which may not make much sense in
Android.
Bug: 113252871
Test: go/wm-smoke. Try launching some freeform windows on secondary
displays.
atest FrameworksServicesTests:TaskLaunchParamsModifierTests
atest ActivityManagerManifestLayoutTests
Change-Id: I974031725015b6283f33b9076788e7ce45134690
1. migrate set/get roamingType from ServiceState to
NetworkRegState.set/get roamingType
2. migrate set/get roamingStateFromRegstate from ServiceState
to NetworkRegState.regState
3. new System API for neworkRegistration.isRoaming().
Bug: 116127096
Test: ServiceStateTest, ServiceStateProviderTest
Change-Id: Ib89744089c98713819c8d313240d629ddb77d0bf
... as requested per API review.
- Sets require iteration via iterators
- Sets are more expensive to construct
- The advantage of sets (faster .contains) is not used
- The system ensures uniqueness of the entires in the list
Test: Built
Bug: 116798569
Change-Id: I2c3b5c6801b78e0bf942073bde1e90299aee39f6
If a normal app does not have launcher icon, launcher api
will return app details activity instead, so user will
be noticed that the app is still installed.
Bug: 111348460
Test: Installed an app without launcher activity, an app icon is being
shown in launcher allapps, and it forwards user to app details page.
Change-Id: I9c17f5edfdefe19727145e7176d7e113286c997d
