| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Add the API to call into IServiceManager.registerForNotifications.
Test: pass
Change-Id: Ia74d8a1bd5be767a076560bf8ee4af3095b4623a
|
| |
|
|
|
|
|
|
| |
A couple words on this for ya!
Fixes: 197629711
Test: N/A
Change-Id: I4fbaacb6e123c042919c03f11a0403e041d23a56
|
| |
|
|
|
|
|
| |
ServiceManager.waitForDeclaredService and .isDeclared needed for Wi-Fi mainline module.
Test: boot
Change-Id: I9e82dd1a6663396f1c79bc3f27c36711b0b6f3eb
|
| |
|
|
|
|
|
|
| |
For parity with getService and checkService.
Bug: 194806512
Test: boot
Change-Id: Iecc3f1c6d6ae9bee94252281b416d62f3bf30afd
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similar to how HIDL HALs are here, we don't know the commandline of the
service, so we can dump them based on service name prefixes.
Power stats and lights are added here, for parity w/ HIDL since these
hvae been converted to AIDL.
Fixes: 175322136
Test: after `adb shell am hang`, we can verify the light service is
dumped, when it wasn't before:
vsoc_x86_64:/data/anr # cat anr_2021-01-28-22-42-44-969 | grep light
Cmd line: /vendor/bin/hw/android.hardware.lights-service.example
Change-Id: I8c8b0cff0c102221875114015a5524c03cfb5b5c
|
| |
|
|
|
|
|
|
|
|
|
| |
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Merged-In: I626caf7c1fe46c5ab1f39c2895b42a34319f771a
Change-Id: I54e5ecd11e76ca1de3c5893e3a98b0108e735413
|
| |
|
|
|
|
|
|
|
| |
Corresponding to change in IServiceManager API, for finding out what
instances of a VINTF service are installed.
Bug: 168715768
Test: manual
Change-Id: Ic54b0cfd1bd42e45dc66858dbd614db7ba22083f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We cache the reference to the HAL and use a DeathRecipient to keep track
of whether it's still good.
Adds waitForService and waitForDeclaredService to the ServiceManager
Java implementation because they were missing.
Test: atest LightsManagerTest
Test: atest LightsServiceTest
Bug: 152509747
Bug: 154631113
Bug: 154627432
Bug: 154629168
Change-Id: Ife8471f3a7e47b48bb31015ddf40f1d7fef6240f
|
| |
|
|
|
|
|
|
| |
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I534e3fd1305e2f4af076986770033478448a665c
|
| |
|
|
|
|
|
| |
Bug: 142255256
Bug: 112725883
Test: Boot
Change-Id: Ia02384689b6b5ecb19db27d91d03f06ae2543b91
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
go/cleanup-greylist-txt
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
This is partial merge of aosp/Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09. Telephony greylist cleanup has been done separately. Note that annotations outside of frameworks/base/ have been merged from AOSP.
Bug: 137350495
Test: m
Exempt-From-Owner-Approval: merge
Change-Id: I015c466e8b69cc0fed5e9d394ba865aad11d8ba6
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For packages:
android.os
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I4ece0a3f37f88fc2508cb965092aed7cabc61819
|
| |
|
|
|
|
|
|
| |
The number of services is pretty limited (100ish), use the more
memory efficient Map.
Test: tested on android go
Change-Id: I092c6816afba77fde4195c68a211804d4a561b77
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ServiceManager:
- Do an event log every N getService() calls with total time spent
in getService().
where N = 100 for core UIDs and 200 for other apps.
- Do an event log if getService() takes longer than N ms.
where N = 10 for core UIDs and 50 for other apps.
... with some extra throttling.
NPMS:
- Do the basic "stats logger" log for updateNetworkEnabledNL() and
isUidNetworkingBlocked()
This CL also enhances StatsLogegr so it now can show the slowest call
and the max # of calls per-second.
Bug: 77853238
Test: Manual test:
- Insert a SIM card
- Set data limit
- toggle airplane mode
- toggle wifi
- toggle mobile data
Then
- "dumpsys netpolicy" and "dumpsys activity processes" and check the stats
- also check "adb logcat -b all | grep ' service_manager'"
Change-Id: I5789541063f95d0eac501189816c8604a4571ba0
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- Adds a new DEFAULT priority for services which is treated the same as NORMAL priority but dumpsys does not send "--dump-priority" arguments to the service.
Bug: 27429130
Test: Manually generate bugrepot (default version) and check for any issues
Test: Load bugreport on ABT
Test: mmm -j56 frameworks/native/cmds/dumpstate && \
adb shell /data/nativetest64/dumpstate_smoke_test/dumpstate_smoke_test && \
printf "\n\n#### ALL TESTS PASSED ####\n"
Change-Id: Ia90ae16d56d0144e679cf39ebfbf4473dd21f167
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Adds new PROTO flag which requests services to dump sections in proto format. Modifies PriorityDumper helper class to parse proto arguments and set asProto flags. Registers WM and AM with proto dump supprt.
Bug: 67716082
Test: frameworks/base/services/tests/runtests.py -e class "com.android.server.utils.PriorityDumpTest"
Test: adb bugreport ~/tmp/bug.zip
Test: adb shell dumpsys window --proto
Test: adb shell dumpsys activity --proto
Change-Id: Icfc6857c8a9340110a43343734a27e48d0b5a229
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Modify IServiceManager to accept supported dumpsys priority as a bitmask
with NORMAL being the default priority. Change listServices to return
a list of services filtered by the priority or all services when the
priority is set to ALL.
BUG:27429130
Test: manual verification
Change-Id: If367ace2f37f918043f1b330568d8560676d9b78
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To protect system stability, any Binder calls leaving the
system_server must carefully be performed using FLAG_ONEWAY (or
the 'oneway' verb in AIDL) which prevents the call from blocking
indefinitely on the remote process.
In this CL, the system_server uses the new Binder.setWarnOnBlocking()
method to enable detection by default for all remote Binder
interfaces. It can also use Binder.allowBlocking() to allow
blocking calls on certain remote interfaces that have been
determined to be safe.
This CL adds the 'oneway' verb to several interfaces and methods
where it should have been added, and marks a handful of system
ContentProviders as being safe to call into. Also, we assume that
any services obtained from ServiceManager are part of the core
OS, and are okay to make blocking calls to.
Test: builds, boots, runs with minimal logs triggered
Bug: 32715088
Change-Id: Ide476e120cb40436a94b7faf7615c943d691f4c0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When fetching system services early during boot, if the underlying
binder interface hasn't been published yet, we end up caching a
manager class that is broken for the remainder of the process
lifetime, and innocent downstream callers end up using the broken
cached manager.
Fix this by using an explicit exception to quickly abort manager
creation when the underlying binder is missing. The exception is
only used to skip the remainder of the manager creation, and it
doesn't actually crash the process.
Bug: 28634953
Change-Id: I0cb62261e6d6833660704b93a11185aa11a2ac97
|
| |
|
|
|
|
|
| |
The exception is already caught by the try-catch block.
Change-Id: I0c10fe51d12a10cbc02a25c719d03a4ba6497767
Signed-off-by: Umair Khan <omerjerk@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Services now must explicitly opt in to being accessed by isolated
processes. Currently only the activity manager and surface flinger
allow this. Activity manager is needed so that we can actually
bring up the process; SurfaceFlinger is needed to be able to get the
display information for creating the Configuration. The SurfaceFlinger
should be safe because the app doesn't have access to the window
manager so can't actually get a surface to do anything with.
The activity manager now protects most of its entry points against
isolated processes.
Change-Id: I0dad8cb2c873575c4c7659c3c2a7eda8e98f46b0
|
| |
|
|
|
|
| |
Bug: 5010576
Change-Id: Id450dc83efed4897d1e4ff451530fed14457aace
|
| | |
|
| | |
|
| |
|