CellBroadcastService is bound to by the platform to handle cell
broadcasts.
Bug: 135956699
Test: manual
Change-Id: Ib1b20da03d271fc0b2736774b2ca6c6514944093
This reverts commit 6f22c2a9fd.
Reason for revert: Error messages are not friendly when something goes wrong.
Change-Id: I13a6a2908a44ebd4599138cd2a61ff4b3cf055eb
First batch of around 20% Slog calls changed to ProtoLog.
365 log statements converted to ProtoLog, including 295 that
were previously disabled with a compile time constant (excluded from
resultant binary).
Size impact: +33kB on services.jar, +99kB on services.odex
(around 100b per added log call). By using ProtoLog we save +21kb
compared to Slog on both files.
Bug:
Test: atest WmTests
Change-Id: Idd712135e81997df84f323ba9a7585d54ba20d23
Having line numbers in log statement location info in protolog viewer
config makes the config file invalid after every code merge.
Bug:
Test: atest protologtool-tests
Change-Id: I7e9ae434517bc94ecfc7f421e71d21b07f3c233f
- 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
And also pre-grant it to all apps that currently get any storage
permission pre-granted
Test: atest SplitPermissionTest
m -j gts && gts-tradefed run commandAndExit gts-dev -m GtsPermissionTestCases --test=com.google.android.permission.gts.DefaultPermissionGrantPolicyTest#testDefaultGrantsWithRemoteExceptions
Manual testing:
All combinations of
- App targetSdk = 28 and 29 (and 22 for extra credit)
- App having the <uses-permission> tag for
ACCESS_MEDIA_LOCATION or not
- Upgrade from P->Q-QPR and from vanilla Q->Q-QPR
Further upgrade of targetSdk from 28->29 while on Q-QPR
==> All permission behavior should make sense. Sometimes there
are weird, but expected behaviors. Hence we need to
collect the results and then look at the unexpected ones.
See SplitPermissionTest for some tests I added for the
location-background permission which was split from
the fine/coarse-location permissions
Fixes: 141048840,140961754
Change-Id: Ib9f50d25c002036f13cf2d42fc4d1b214f20920c
Instead NotoSansMyanmar*-ZawDecode (Unicode-Zawgyi hybrid) fonts,
go back to NotoSansMyanmar and NotoSansMyanmarUI (pure Unicode) fonts.
Bug: 141019225
Change-Id: Ib2494b9b5cb148f598e69271c5676e7104f66ae3
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)