Add an internal method to ApplicationInfo to get all APK files that may
be required by an application. This moves assumptions about how apps are
constructed out of Zygote.allowAppFilesAcrossFork and into a more
appropriate place where it can be shared.
Bug: 124116212
Test: atest android.webkit.cts.WebViewTest
Change-Id: I79add98c4922c4f97263bff78cf808bc38274755
Because the layout looks pretty much the same as when awake, we're
going back to the regular group layout.
Test: atest SystemUiTests
Fixes: 127697886
Change-Id: I5eafaf74435151faab13d8f84850b4939196edd9
Add single direct share row this is always present, prepare for
expanding to 2. Show message about missing direct share targets
if none are found in the first XX seconds. Use animations to
transition between the states. Add border dividers between sections
Bug: 126565347
Test: atest ChooserActivityTest
Change-Id: I31963375530433c3d6e9069402b5a20df5766034
* changes:
Check for empty arguments in setWhitelist().
Implemented a WhitelistHelper for whitelisting packages/activities for Augmented Autofill and Content Capture.
Displays Settings button instead of always button for all intents that
have http or https scheme, as opposed to only intents that have
BROWSABLE as category.
This fixes an inconsistent and confusing behaviour that users were
experiencing, as sometimes they saw the Always button and sometime the
Settings button.
Fixes: 126499502
Test: open a mail.google.com from Facebook Messenger - used to display
Always button and now displays Settings button
Test: use shell command to send https intent without BROWSABLE category
- used to display Always button and now displays Settings button
Change-Id: I1084fd716ba8e584c2b17d8fe1500dbc641cab46
The resolver prompt now redirects users to the Default Browser page when
they tap a browser app and choose [Settings]. In that page, they can
choose the default browser (even if the tapped browser app is already
the default browser).
Bug: 124721947
Test: manual
Change-Id: I31518510fa382bd49c61ee494bf585dec0c762f8
The latest plan is only system apps with a certain privilege permission
could become NAS. And DeviceConfig could specify any of these valid
candidate to be the default NAS.
So the logic would be like this:
1. If user has set the NAS manually, NMS will persist the user_set bit
and never mess with it.
2. If it is not the case, NMS will try the NAS defined in DeviceConfig,
and then the one defined in config.xml
Also added some new shell commands for easy debugging.
Test: atest NotificationAssistantTest.java
Test: atest NotificationManagerServiceTest.java
Test: Use "device_config put" command to set a valid one. Observe that
NAS is updated and persisted across reboot.
Test: Repeat the command with an invalid one, observe that NAS is not
updated.
Test: Go to settings, set a NAS, and repeat the device_config command,
observe that NAS is not changed.
Test: Go to settings, set NAS to be none. Reboot the device, and "none"
is persisted.
FIXES: 123566150
Change-Id: Ibf8e498944afd5d1fa8659a856a8abdcce41f092
The logic was only there for the system server before, it is now
moved to ProcessList (the correct location).
Test: manual
Bug: 123524494
Bug: 124437687
Change-Id: Ie259a13617981bcbced144f1514c43f32d06102b
Direct share targets can update after they have been initially
displayed. This modifies the logging that was there to indicate when the
direct targets are displayed for the first time and when they are being
reordered.
Bug: 126920281
Test: successfully ran atest ChooserActivityTest
Change-Id: I1d16c0fb2b5631473879ba9758128e6f482567c2
Appops can be peformed by an app on its behalf and also on
behalf of another app, i.e. an app can perform a proxy op
and blame the work on another app. The proxy mechanims is
for apps doing work on behalf of other apps where GCore is
one example since the app doing the work needs to check if
the caller has access to the functionality - specifically
the app op backing a runtime permission in case the calling
app does not support runtime permissions.
Apps being able to blame work on other apps is a problem now
that we would be using historical op data to show permission
usage in the UI as apps can start blaming each other to gain
a competitive advantage.
To address the issue we are adding APIs for querying portions
of the app op data - last and historical. One can now get
the ops for work the app did for itself, work the app blamed
on other apps if the app is trusted, work the app blamed on
other apps if the app is not trusted, work other trusted apps
blamed on the app, work other untrusted apps blamed on the app.
A trusted app is one holding the permisison to update app op
stats which is privileged.
The data slicing API allow us to show in the UI only the trusted
poriton of the data which is work the app did for itself, work
trusted apps balmed on the app, and work the app if untrusted
blamed on other apps.
Test: atest CtsAppOpsTestCases
bug:111061782
Change-Id: I9a2bcaea272cb06f38ba742cf601a6dc3b287d5e
UX desires for this are: when IME appears for a freeform window,
1. Temporarily push the freeform window up to make room for IME
1a. However, do not push the top of the window off the screen
2. Any part of the window left under the IME becomes inset and
thus handled by adjustPan or adjustResize.
3. Return the window to its original position when IME closes.
3a. Unless the window is moved while IME is up.
4. If the window is moved around while IME is up, do not change
the content (ie. don't adjust insets).
This CL includes some fixes to related bugs as well:
- During adjustPan, the caption is now "unscrolled" so that
it remains at the top of the window. Previously, the caption
would be scrolled out of the window along with the content.
This is done via setTranslation so it won't trigger relayout.
- The starting bounds of task-drag uses the task bounds instead
of dim bounds. Dim bounds was based on the visible frame
which excludes the IME inset; so, it was causing the window
to be resized if the user tried to drag the window while IME
was open. Going through the history, this was done to resolve
some issue with resizing dialog activities. I've verified
that behavior in this case is the same before and after this
CL.
Bug: 119375946
Test: Manual since UX: open desktop display, open apps that
use IME (both adjustPan and adjustResize).
Also, atest WindowFrameTests
Change-Id: Id81d0b0a5f82be28fabed3ad22e713fc4fa7536d
Test: checked SecurityException is thrown for my custom app
Test: whiltelisted my custom app, checked no SecurityException is thrown
Bug: 126541701
Change-Id: Id0b61ccc1adf40bcb455d3b59b640f4b160bdd84
Also migrate MediaProvider logging to more general-purpose location
on the ContentProvider.Transport, where we can log exact input/output
values to aid debugging.
Bug: 124347872
Test: manual
Change-Id: I6aba60879ded4e0892d2d1cdd717c23cebaaabd8
Test: `adb shell device_config put systemui compact_media_notification_seekbar_enabled true`
and observed that seekbar appeared on the next layout, or disappeared if set
back to false.
Bug: 123698590
Change-Id: I0f2469aa17e66fb0d5bedce93582fc45812a0c30
