Work profile uses the same instance of PrintManager and DPM
as the primary user. We have to explicitly check restriction for calling user.
Bug: 73768054
Test: Set restriction in Work profile, check that it applies only in work profile.
Change-Id: Iaa63ce000fc84b7d0ee2bd0ff008f1c0f7272a87
This guarantees that the print job is created before the print activity
deals with it.
Test: CtsPrintTestCases
Change-Id: I3451fff71bd981beb45882b7b42d4cc49d63a91c
Fixes: 73127052
Add @GuardedBy for simple functions that require a single lock
and are named XYZLocked.
Derived by errorprone.
Bug: 73000847
Test: m
Test: m javac-check-framework RUN_ERROR_PRONE=true
Change-Id: Id1d9fbe5018250e3b9d1466fc5f670d5ad902fa3
Use existing API instead of creating new method.
Bug: 64140119
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.MixedDeviceOwnerTest#testPrintingPolicy
Change-Id: I9ff94f4d73824e7bf9aedbb64811ad60fccf9779
This allows to dump the USB state as proto-buf. This in turn allows to
automatically process this data.
Test: adb shell dumpsys usb
incident_report usb
No automated test possible as no field is guaranteed to be set
Change-Id: Ifdf22bfaf9c78226c420b11c43278013ce69f849
Sometimes app inside profile can't get package info for its owner.
Instead of relying on calling user id, we make PrintManagerService switch to
system id and pass user that called print() explicitly.
Bug: 72309652
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.MixedDeviceOwnerTest#testPrintingPolicy
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testPrintingPolicy
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.MixedProfileOwnerTest#testPrintingPolicy
Test: bit FrameworksServicesTests:com.android.server.devicepolicy.DevicePolicyManagerTest
Change-Id: Ib97018f56693549fbca506dba6efaadb6dd010b3
This adds a new "isPrintingEnabled" policy (true by default)
and hooks it into PrintManagerService.
Bug: 64140119
Test: manual
Change-Id: Ifb0f6772af51e6185135e9dcf5551e9ef0d88af3
Beside addressing the comments on this change, this adds a check that
the token in end( is correct and prints a message if not. This is useful
when creating new dumping methods.
Test: adb shell dumpsys print
Change-Id: Ic2e6152cbd82f98d9d305a15edffc69c55fd1fd3
Add a class DualDumpOutputStream that maps proto-dump commands onto
print writer commands.
The effect of this is that there is only one - very proto dump like -
way to dump the print manager which is much easier to maintain.
The DualDumpOutputStream tries to produce a result similar to the
incident-report tool.
Test: adb shell dumpsys print
Change-Id: I1f0c56651eaa59f0ce90cdb08c71e89a96c48dd4
This introduces PooledLambda - a way of obtaining lambdas without the
allocations overhead.
See PooledLambda javadoc for a guide and PooledLambdaSample for code samples
of useful usages.
Test: ensure samples of PooledLambdaSample work as described.
Change-Id: I46f8ad27bc1de07e19f6e39f89d2cafe4238497a
Symptom:
Global reference table overflow happens on system_server.
Root cause:
When a listener is added to the PrintManager, death notification for
the listener is registered. So the listener is added to global
reference table.
But the death notification is not unregistered when the listener is
removed from PrintManager. The listener isn't removed from the global
reference table until client process die. If client process repeatedly
add/remove listener, the global reference table overflow.
Solution:
Call unlinkToDeath() when the listener is removed from PrintManager.
Test: cts-tradefed run cts-dev -m Print
Bug: 68746445
Change-Id: I0b133e4607317a15e51bdf6e1248552dcc920d6d
This causes ANRs as we are trying to the the print spooler connection
while holding a lock that can also be aquired on the system server's
main thread.
Fixes: 63159459
Test: cts-tradefed run singleCommand cts-dev -m Print
adb shell dumpsys print
incident_report print
Change-Id: I228fc5ddc10c1c89f61e8a6d8eb8ea9e384197a8
We should only need to prune services if the package that changed
had a print service or has been changed to have a print service.
Bug: 63019430
Test: Manual; observed that the print spooler isn't started up.
Test: run cts -m CtsPrintTestCases
Change-Id: I32df27e4b1d11615cf6053dd3d35c2b60068d0d3
The permission is preinstalled as we want to leave the PrintSpooler
unpriviledged.
Test: Checked that Settings, PrintSpooler and BuiltInPrintService still
behave as expected.
Fixes: 62350107
Change-Id: Id33896f2899533f2d05cafa926df29cf1c6bfa77
Apps with a normal UID are typically isolated enough to not require
socket tagging; we're mostly interested in tracking down internal
UIDs that have lots of code sharing the same UID.
Also fix up everyone doing manual string checks of Build.TYPE, since
we now have first-class fields for those.
Bug: 38126076
Test: builds, boots
Change-Id: I3a40348196bd8459289f2b9355d9783a07f1e7dd
As in the change: I4f4cdaba65132dc2ef054877cbb097b499a723f6
the lock object is removed when calling RemotePrintSpooler
and so as it in the method prunePrintService(). But in the
constructor of UserState, the mLock is still held when calling
prunePrintService(), it may also block the main thread
It is better to take it out of the synchronized block
Test: null
Change-Id: I709b491d611dbcbf21a5fd493b879ed290dd0247
Signed-off-by: yangbingqian <yangbingqian@xiaomi.com>
Test: 1. Trigger the confitrmation dialog.
Ensure it looks exactly like the one from settings.
2. Call an API without associating the appa first
Ensure exception is thrown with a message mentioning the need to associate 1st
Change-Id: I94d4116e1988db869ed445ae3fd018c50590e3f4
There mas a missing defensive copy causing false positive detections of
"associations not changed" case, leading to xml file not being updated once
at least one record is present
Bug: 30932767
Test: Associate at least two different devices and ensure the xml has both.
Change-Id: Ic0dc615dd2b847e137555c1084c616831b4dde83
This effectively treats chooser activity pause event as cancel.
Bug: 30932767
Test: Install two toy apps and call associate API from both.
Ensure foreground app always end up showing fresh data.
Change-Id: I7f5742e9878245550f678efd244bf84c427baef3
... by extending the RecommendationInfo to store the inet addresses not
just the count. Thankfully the recommendation plugins already contained
all the printers, not only the count.
Also expose the print service state as system APIs as they will be used
by the default print service.
Bug: 35765644
Test: Ran AddPrinterActivity on network that had printers to discover
Change-Id: I929a177adb75f6848848ba30a472cf0343d2e67e
This change introduces new methods on DumpUtils that can check if the
caller has DUMP and/or PACKAGE_USAGE_STATS access. It then moves all
existing dump() methods to use these checks so that we emit
consistent error messages.
Test: cts-tradefed run commandAndExit cts-dev -m CtsSecurityTestCases -t android.security.cts.ServicePermissionsTest
Bug: 32806790
Change-Id: Iaff6b9506818ee082b1e169c89ebe1001b3bfeca
1. Listen to calling package binder death stopping the scanning on that.
2. Don't restart scanning when a request with the same values was made.
Bug: 30932767
Test: 1.:
- Using a test app start scanning and kill the app.
- In debug mode ensure that DeviceDiscoveryService#stopScan gets triggered
2.:
- Start scanning and rotate the device while device chooser is visible
- Ensure no visible loss of state is happening
Change-Id: If126a2c963da90172a956fbd88e6b3dcd7ac8b01
1. On package removed -> remove all its associations
2. On package updated -> if had associations, update special access permission
in accordance with (potentially changed) permission entries in manifest
Bug: 30932767
Test: 1. Remove app, and ensure xml entries for it got removed.
2. adb install new version of app without special permissions in manifest, and
ensure whitelist removal method got called
Change-Id: I87261c05ddcf40a18332d160b44ee2f8284df5e4
By supporting multiple filters per one request we should be able to cover
multiple kinds of use cases such as:
- Letting the user select from a list of devices of more then one medium
type (e.g. Bluetooth and BLE)
- Allowing to provide multiple criteria for any field (e.g. filtering by
more than one service UUID)
Bug: 30932767
Test: Provide multiple filters and ensure that devices matching either are
shown in the list to choose from.
Ensure wifi SSIDs are shown in the list if wifi filter is provided
Change-Id: I0a978787551a1ee5750ec5544b241d3bbfed5a7c
By supporting multiple filters per one request we should be able to cover
multiple kinds of use cases such as:
- Letting the user select from a list of devices of more then one medium
type (e.g. Bluetooth and BLE)
- Allowing to provide multiple criteria for any field (e.g. filtering by
more than one service UUID)
Bug: 30932767
Test: Provide multiple filters and ensure that devices matching either are
shown in the list to choose from.
Ensure wifi SSIDs are shown in the list if wifi filter is provided
Change-Id: I6621da388e2bf4ed97c5af2692629a321d0b63c7
Bug: 30932767
Test: Ensure file not exists -> query associations -> ensure result is empty list
Associate device -> cat xml file -> ensure record appears as extected
Disassociate device -> cat xml file -> ensure record is no longer present
Change-Id: Ibe456a6d9292e05e2391f5138e43fdaa37f87e1b
Companion apps can declare they want background access and
background execution exceptions via dedicated permissions
in their manifest. If such a permission is requested we
auto-grant the corresponding exception after the user has
chosen a device from the companion UI. These permissions
are appop ones allowing us to use the app ops for gauging
whether the user has made a change after we auto-granted
the permission since we would like to revoke these special
privileges when the app disassociates itself from the
companion device if the user did not make an excplicit
choice otherwise.
While at this auto-grant fixed location permission to the
companion device discovery service.
Test: manual
Change-Id: I46ee4291e5e5a8f7613f0dd75eb61d6b9341f306
This introduces an API for apps that support companion devices to provide a
more streamlined flow for pairing and setting up the device
Bug: 30932767
Test: Using a toy app, invoke the newly introduced API (CompanionDeviceManager),
and go through the flow. Ensure filtering works, and device is returned to
the calling app. Ensure the calling app can pair to the selected device.
Change-Id: I0aeb653afd65e4adead13ea9c7248ec20971b04a
When calling out to dump services hosted by external apps, use
dumpAsync() to avoid hanging if the remote process is wedged.
Test: builds, boots, runs with minimal logs triggered
Bug: 32715088
Change-Id: I70aa2666ae21dae8f09ded2063bed359c0b210c5
When calling out to dump services hosted by external apps, use
dumpAsync() to avoid hanging if the remote process is wedged.
Test: builds, boots, runs with minimal logs triggered
Bug: 32715088
Change-Id: I70aa2666ae21dae8f09ded2063bed359c0b210c5
isUserUnlockingOrUnlocked should be enforced for calls made by apps.
Calls from system server should be handled gracefully.
Test: manual
Bug: 31833240
Change-Id: If56b0f9994209eb45a47072e0377d11293a9cbad
The calls might be blocking and need the main thread of to be unblocked
to finish. Hence do not call while holding any monitors that might need
to be acquired the main thread.
The calls that have been moved out of the lock:
- Icon related calls: These are just caches. Hence we flush the cache we
just request the icon again
- Prune call: This just removes not installed print service from some
data structure. The order of two of these calls does not matter as
the end result of both removals will be the same, regardless of order.
Testing done: Reinstalled a print service multiple times. Before the
first reinstallation locked up the userState, now not anymore
Change-Id: I4f4cdaba65132dc2ef054877cbb097b499a723f6
Fixes: 31043684
The calls might be blocking and need the main thread of to be unblocked
to finish. Hence do not call while holding any monitors that might need
to be acquired the main thread.
The calls that have been moved out of the lock:
- Icon related calls: These are just caches. Hence we flush the cache we
just request the icon again
- Prune call: This just removes not installed print service from some
data structure. The order of two of these calls does not matter as
the end result of both removals will be the same, regardless of order.
Testing done: Reinstalled a print service multiple times. Before the
first reinstallation locked up the userState, now not anymore
Change-Id: I4f4cdaba65132dc2ef054877cbb097b499a723f6
Fixes: 31043684
