- Added log statement location info to viewer config
- Fixed a NPE in ProtoLogImpl
- Reworked early return for log calls
- Changed type of message hash field to signed (for Java compat)
- Fix flaky tests for ProtoLogImpl
Bug:
Test: atest protologtool-tests FrameworksServicesTests:com.android.server.protolog
Change-Id: I7874475083ab5d01fe46fd3013a058743acd3884
Creates a new SystemConfig xml entry which allows a device to whitelist
system packages to be installed on users when they are created, based on
the type of user.
System packages will be installed on users when they are created, or
during OTAs, based on this whitelist. The whitelist can be
enabled/disabled via a Config resource.
For any user type, system packages can be whitelisted or blacklisted.
If it is both (for the same user type), the blacklist takes priority.
If it is neither, it won't be installed (since it isn't whitelisted).
If a system package isn't mentioned in the whitelist file at all, for
any user, then its behaviour depends on the Config resource value, which
can optionally implicitly whitelist all such apps on all users.
For now, the list is mostly empty and the default config is set to be
enabled but implicitly whitelist all system packages that are not
mentioned.
Test: atest FrameworksServicesTests:SystemConfigTest
Test: atest com.android.server.pm.UserManagerServicePackageWhitelistTest
Test: manually test user 0 by flashall -w and checking packages
Test: manually test OTA by setting setprop persist.pm.mock-upgrade 1
Bug: 134605778
Change-Id: Ia098c1f597f66a1c946cfcc9b7771c25e8ceabf7
This reverts commit 27c4e658b3.
Reason for revert: <potential performance regression. revert for now and looking for possible optimization from ART team>
Change-Id: I5bf728e4f6789d7e6398cf90f22fbf3a24d481c2
This CL implements the on-device part of ProtoLog
- the new logging system for WindowManager.
Design doc: go/windowmanager-log2proto
Change-Id: I2c88c97dabb3465ffc0615b8017b335a494bca59
Bug:
Test: atest FrameworksServicesTests:com.android.server.protolog protologtool-tests
And also pre-grant it to all apps that currently get any storage
permission pre-granted
cherry-pick for qt-qpr1-dev Ib9f50d25c002036f13cf2d42fc4d1b214f20920c
Test: - straight cherry-pick
- atest SplitPermissionTest
Bug: 141048840,140961754
Change-Id: Ia2219639a2104965a382ffef647e5ebaa0f9d540
So that runtime permisions are less likely to be incorrectly declared.
Bug: 141033226
Test: atest --test-mapping frameworks/base/data/etc/platform.xml:presubmit
atest --test-mapping frameworks/base/core/res/AndroidManifest.xml:presubmit
atest --test-mapping frameworks/base/core/java/android/app/AppOpsManager.java:presubmit
Change-Id: I4cf58d2041b5fda6360ef148edb76c048371cca6
We are still missing a key layout for the original xbox controller with
product id 02dd. Add the missing layout here.
Bug: 140808513
Test: manual test by plugging in the actual joystick and using the
custom tester app
Change-Id: Ib84e3ac04ff58f890ce7743423cc9b869af347db
The Xbox controller (product id 0x02fd) is going to have a new firmware
update this fall that sends a different keycode (316/BUTTON_MODE) for
the Xbox button. The goal is to enable the Xbox button to make it to
apps on all Android versions -- with our without a controller-specific
key mapping file.
Unfortunately, the new Vendor_045e_Product_02fd.kl key mapping file
that was added to Android Q maps the pre-firmware-update
Xbox key code (172) to BUTTON_MODE, yet it makes no mention of key 316.
This results in apps getting a raw 316 scan code instead of
a BUTTON_MODE KeyEvent when using a controller with the latest firmware
on Android Q.
The fix is to add an additional key mapping for 316 that *also* maps to
BUTTON_MODE. With both mappings in place, both pre and post
firmware-updated controllers will get the correct behavior for the
Xbox button on Android Q.
Test: AFAIK, no CTS tests exist for Xbox controller key mappings;
we'll need to add some at a later date. I was unable to test this
change because I'm unable to write to the system directory on any
of my devices, but I know that mapping 316 to BUTTON_MODE will
fix the issue.
Signed-off-by: Jared Henderson <jaredh.microsoft@gmail.com>
Bug: 139512030
Bug: 140808513
Merged-In: I8600ea79a0aa8557267d6ca712e5d56680e7a98b
Change-Id: I8600ea79a0aa8557267d6ca712e5d56680e7a98b
telephony-common is not intended to used by any apps and
being in boot class is not updatability friendly.
We are removing telephony-common from bootclass and apply
<uses-library> in manifest instead.
for apps targeting < R will auto load telephony-common lib
for app compatibility. For apos >=R, only allow usage for
phone UID.
Bug: 135955937
Test: Build
Change-Id: Ia318661546df6d8516328886e5cc0c54d5cfafe6
No need to include the removed permission from the privapp configs.
Bug: 139410948
Test: manual/build
Change-Id: I01db28dc7126c021e5a50bc64f37976b07d79334
The Xbox controller (product id 0x2fd) is going to have a new firmware update this fall that sends a different keycode (316/BUTTON_MODE) for the Xbox button. The goal is to enable the Xbox button to make it to apps on all Android versions -- with our without a controller-specific key mapping file.
Unfortunately, the new Vendor_045e_Product_02fd.kl key mapping file that was added to Android Q maps the pre-firmware-update Xbox key code (172) to BUTTON_MODE, yet it makes no mention of key 316. This results in apps getting a raw 316 scan code instead of a BUTTON_MODE KeyEvent when using a controller with the latest firmware on Android Q.
The fix is to add an additional key mapping for 316 that *also* maps to BUTTON_MODE. With both mappings in place, both pre and post firmware-updated controllers will get the correct behavior for the Xbox button on Android Q.
Test: AFAIK, no CTS tests exist for Xbox controller key mappings; we'll need to add some at a later date. I was unable to test this change because I'm unable to write to the system directory on any of my devices, but I know that mapping 316 to BUTTON_MODE will fix the issue.
Change-Id: I8600ea79a0aa8557267d6ca712e5d56680e7a98b
Signed-off-by: Jared Henderson <jaredh.microsoft@gmail.com>
Bug: 139372370
In order to access system-only cameras client processes need
SYSTEM_CAMERA permissions in addition to CAMERA permissions. A
permission was preferred over other mechanisms such as having private
connections would need to hard-code the package name(s) of clients using
system only camera devices. A system | signature permission on the other hand,
would make this more flexible and would be better for security.
Bug: 133508924
Test: cts CameraManagerTest, CameraDeviceTest
Test: Give cts test SYSTEM_CAMERA permissions by using
adoptShellPermissions and run some camera tests.
Change-Id: Ibcd6ccdb231dcca949ed4fb14712d033a5801d36
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
We are currently missing the key layout for the Xbox One USB controller
with the following meta information:
vendor 045e, product 02ea
This layout was copied from product 02d1.
Also fix the mappings of the middle buttons to generate "select - mode -
start", similar to what has already been done for the other xbox
controllers in ag/4836521 and ag/3162575
Bug: 132451971
Bug: 133514907
Bug: 139512030
Test: tested using custom app. CTS tests will be added later.
Change-Id: Ie18bce987b512211d3e91bd1f7334afe11d83cf8
Merged-In: Ie18bce987b512211d3e91bd1f7334afe11d83cf8
Add layout for Xbox elite controller
Test: tested with a custom app
Bug: 132451971
Bug: 139512030
Change-Id: I1c600bc2c41db9d79d7a4e184ef41abe2b5f860e
Merged-In: I1c600bc2c41db9d79d7a4e184ef41abe2b5f860e
* changes:
Sysui/WifiTracker: Changes to support late starting wifi service
WifiManager: Retrieve IWifiManager service lazily
WifiStackClient: Register wifi API services from system_server
Mainline wifi stack module
NetworkStackClient: Refactor network stack process interaction
As part of getting MediaProvider to compile against supported APIs,
we're moving MTP related logic into its own repository.
Bug: 135340257
Test: manual
Change-Id: Ie274b1c0da435c024385eba1e4301639991a785b
a) Moved wifi service to a separate APK
b) Use the IWifiStackConnector to load the wifi stack from
SystemServer (similar to network stack).
c) Create a new WifiStackClient interface for system server to interact
with the wifi stack (under new services/wifi folder). Note: This not planned
to be updated via wifi-sdk Apex.
d) Add priv-app permissions for the new wifi stack APK.
Bug: 113174748
Test: Device boots up & connects to wifi networks, hotspot toggle, etc.
Test: Will send for regression tests
Change-Id: I54b3a11ed30668bad5a387370484b2bb0eabca5f
Merged-In: I54b3a11ed30668bad5a387370484b2bb0eabca5f
Added a version of the onPermissionUpdated and
onInstallPermissionUpdated methods which will notify
OnPermissionChangedListeners, and added this to the
PermissionManagerService "updatePermissionFlags" and
"updatePermissionFlagsForAllApps" methods. Also adds
OnPermissionsChangedListener to @TestApi
Fixes: 135937566
Test: atest PermissionUpdateListenerTest
Change-Id: I906598c366234c3daaa202261678bca04837cb13
Alarms were removed previously to reduce the space required for the
system image. But we still need a default one for the RingtoneManager
tests.
Bug: 110449143
Test: cts -m CtsMediaTestCases -t android.media.cts.RingtoneManagerTest#testSetType
Change-Id: Iee91156059f3440fbb6a0b28765dd3bb0b997cf5
(cherry picked from commit ecf1bfc3e4109d6f43b3fe4d27bc8035fbd462d8)
This reverts commit 0999f93e4a.
Reason for revert: There is a better choice (ag/8051966) than adding the permission to resolve b/130827484
Bug: 130827484
Change-Id: I1b8fd74a173d4b0ef981e51f7e0a9c5f84d5f416
Linux has defined KEY_ASSISTANT, but it is not currently mapped in
Android by default. Add the missing mapping here.
Bug: None
Test: None
Change-Id: I85dfecf599ebb69dd2b9ac602b1fc425e13f93c4
NETWORK_REQUEST_SCORES is being changed to a privileged permission from
signature only permission. The wifi stack needs to obtain this permission,
so it can no longer be signature only.
Bug: 113174748
Bug: 135480528
Test: Compiles
Change-Id: Ia824676ee4ddc935346ae22b0aabd6ed4661743f
com.android.providers.downloads
Required because DownloadManager needs to whitelist
a broadcast for bg activity starts.
Bug: 135515407
Test: builds, boots (it wouldn't without this)
Change-Id: Id6c22d1397417bbc10e2829e563f29cbccccd8bf
