These logs are critical to understand the operation of the system, and
do not spam (1/hal start or 1/hal request). Most importantly, if a
manifest fails to be read for whatever reason, this is logged (null
manifest case).
Bug: 151696835
Test: boot, and verify logs of successful hal retrivals
Test: boot, and verify logs w/ patch which causes VINTF to fail the
first time, and verify that this causes a single crash which gives us
the ability to still find and detect a critical error, but allows the
system functionality to continue to work.
Change-Id: I0a26b875947878656d6eda03ffebce97ebb6139e
Merged-In: I0a26b875947878656d6eda03ffebce97ebb6139e
See details in TODO.
This hack is either causing a bug or may be preventing us from solving
another bug. Until the more critical bug can be fixed, avoiding
early-boot reads of VINTF manifest files.
Bug: 151696835
Test: run, boot, check manifest logs that HAL services register
Change-Id: Iba34afe451026a30e695d6728b4172007aaf7fbd
Merged-In: Iba34afe451026a30e695d6728b4172007aaf7fbd
If tryUnregisterService is called while a service has set guaranteeClient to true, it should not succeed. The flag means that a client exists and is about to be counted. Not checking this flag can lead to a race.
Bug: 151485917
Test: aidl_lazy_test
Change-Id: If7ef7a5c7521ea40521bd351385fb8bd650aba08
This flag can be used to temporarily prevent dynamic services from being killed. For example, if a service needs to perform a task in the background it can set this flag and then disable it once the task is complete. The service will then go back to standard lazy behavior.
Bug: 150967269
Test: aidl_lazy_test
Change-Id: I840bbe4b6b0406f0e4de610367290448e7edd3de
37f70cc102
Reason for revert: This undoes the previous reversion, which was made to fix b/148282665.
Change-Id: Ie855de284969af5dc937dc95daae84c3df107d32
Revert "Add aidl_lazy_test_server to Cuttlefish"
Revert "Move aidl_lazy_test_server to system_ext"
Revert submission 1209453-aidl-lazy-presubmit
Reason for revert: b/148282665. A test has begun to fail on git_stage-aosp-master, and I need to verify whether these changes are responsible.
Reverted Changes:
Ib09a2460e: Add aidl_lazy_test to general-tests
Ib08989356: Move aidl_lazy_test_server to system_ext
I694e6ad35: Add aidl_lazy_test_server to Cuttlefish
I65db12c63: Add aidl_lazy_test to presubmit
I7ec80a280: Dynamically stop services with multiple interfaces...
Change-Id: I6d3b589bf2861f68d2852c8def7a1f51eea7cf97
This fixes a couple workflow bugs with dynamic services that had multiple interfaces in use at once. Attempting to stop one could affect the reference count of the other, and re-adding it after a failed removal yielded duplicate registrations.
Bug: 146903840
Test: aidl_lazy_test
Change-Id: I7ec80a280dabf7c576b7b00dff404a68c24ae5f1
Renamed CallbackMap as ServiceCallbackMap to better distinguish it from the newly added ClientCallbackMap.
Bug: N/A
Test: aidl_lazy_test
Change-Id: I890ddbed5734dfeb9f7265fd424098f2bac2ffca
Services can choose to register with the new LazyServiceRegistrar.
ServiceManager perpetually checks the reference counts of services
registered in this way. If ServiceManager detects that a service no
longer has any clients, it will notify the LazyServiceRegistrar, which
will attempt to shut down the service.
Bug: 143108344
Test: aidl_lazy_test
Change-Id: Ic01981b767ab4402e7aecdf1cdf9ed64df1f5af4
The pointer to the iterator in this function wasn't properly dereferenced, leading to an inifinite loop in ServiceManager::binderDied.
Bug: 144534962
Test: Manual (boot and dynamically start services)
Change-Id: Ie7b8685b5de31ab7c9ba5877b6df3af08aab0c0f
Doing this asynchronously since it was delaying first client by ~6ms on
crosshatch and other devices.
Bug: 144282062
Test: on walleye, StartVibratorService ~9ms -> ~4ms.
Change-Id: I6cc65e74922b32c2e7135f583fa892fa26f85e2b
A device like this should fail VTS or other tests, but a segfault is
counterproductive.
Bug: 143744480
Test: TH
Change-Id: I71c42f1f8d5288152c6db43c33f44a7235df1265
Most of the time, AIDL services exist in client/service pairs. In this
context, `while(true) getService` or `waitForService` makes sense.
However, for VINTF services, this client/server coupling isn't
guaranteed. A device may or may not have specific hardware. So, now
IServiceManager can tell a client when a server will exist so it will
know if it needs to wait for this service during boot-up. The function
waitForDeclaredService is provided for this.
These functions are generic (not referring to VINTF specifically)
because they may be expanded to include information about APEX services
in the future OR the infrastructure may be made generic to work, if
desired, on system services.
Bug: 141828236
Test: binderStabilityTest, using waitForDeclaredService function
Change-Id: Ia230625e44e1685cc3fa9230ece8f0a25c88585e
So that servicemanager isn't treated any differently for things like
dumpsys or other utilities that need to iterate over all services.
Bug: 136027762
Test: dumpsys -l
Change-Id: I82cc5e5261ff86d36da4fe49b434e88aa5368005
Type 0 actually corresponds file_contexts backend. Use type
SELABEL_CTX_ANDROID_SERVICE instead.
d4828b3ba4/include/selinux/label.h (27)
Test: boot cuttlefish; no denials to any service
Change-Id: I1c33c31ecbd46168998606c3463837a9c6f39f3a
For interfaces that are exported API to vendor, check that the
interfaces are declared in the manifest before allowing them to
register.
Implements this relationship:
Device using VINTF instance => instance in manifest
The manifest is used for two things:
- understand which HAL interfaces are used so that we don't deprecate
them too early.
- understand which interfaces are on the device: this allows clients to
depend on a HAL interface IFF it is installed.
Bug: 136027762
Test: try registering interface that is and isn't in the VINTF manifest
Change-Id: I8aa09a56c638a6cc3aa93f102caf09da401a143b
This allows services to be disabled at boot and dynamically enabled as
they are needed. When servicemanager receives a getService request,
it will check whether the service is running. If it is not,
servicemanager will attempt to start the service by signaling init with
the ctl.interface_start control message.
Bug: 138756857
Test: Manual (using mediaextractor as a test service), test_sm
Change-Id: Ic2d47d21769b936381e3fae2f2cf739d3b7501a4
You can now register and receive notifications for new services.
Eye towards:
- avoiding while(true) getService loops
- need it to make AIDL dynamic HALs
- need it for feature parity w/ HIDL
Bug: 136027762
Test: servicemanager_test
Change-Id: Iffbf984e87214aa9c9b7af8a5ae682e127ba40a5
Documenting some invariants. Since I am adding some more APIs, I want
this to be explicit.
Bug: 136027762
Test: servicemanager_test
Change-Id: I67da9d92c3a457926739fb1f02411a57caefa5b8
To work as instance name separater consistently w/ HIDL.
In HIDL, people are used to writing something like:
android.hardware.light@2.0::ILight/default
In AIDL, the same thing would look like:
android.hardware.light.ILight/default
Bug: 136027762
Test: use '/' in service name
Change-Id: Ie108029bd37b09647b761c5c5ce3a901dbfd4f19
unlinkToDeath happens automatically when the last strong ref to a proxy
goes away (see 80d23935ff).
Bug: 136027762
Test: boot and check for log:
"onLastStrongRef automatically unlinking death recipients"
Change-Id: Iec16013548d9bda24f6e96d5cf80c69071953cb0
We won't move the check up because doing so doesn't appear to add much
of a benefit.
Fixes: 136023468
Test: N/A
Change-Id: Id3dea9e5a3a8bcc19c21b31ae7e4af0c3017e2a1
This makes checking multiple things in the policy painful (which we may
need to do in the future). Also, it makes the APIs around listing
services somewhat bad.
Bug: 135768100
Test: servicemanager_test
Change-Id: I29cac39f6b63934740aa07a192e06b74ce8580ed
This is in order to, in the future, potentially have special policy
like:
vendor$vendor_service u:object_r:...:s0
universal$hal_foo_service u:object_r:...:s0
Currently, there are no special characters that could be used for this
purpose.
How safe is this? In all context files in our internal tree, only the
following characters are used in service names:
-._12aAbBcCdDeEfFgGhHiIjkKlmMnNoOpPqQrsStTuUvwWxyz
'.' appears everywhere to mean '\.'.
Test: servicemanager_test
Bug: 136027762
Change-Id: Idd6698a68bbbe825dd5a25d92baf81fae473ea2a
Import libbinder tests. Due to the global nature of the SM, these tests
frequently make use of the servicemanager.
Bug: 137203409
Test: TH
Change-Id: I40777d7e859ac7fdba686e12ef515406eace2c07
vndservicemanager was calling 'self' before 'initWithDriver':
ProcessState::self()->initWithDriver(...);
However, 'self' inits the driver. On devices with the VNDK, this caused
no problem because libbinder automatically inits to the correct driver
node. However, on legacy devices, vndservicemanager tried to use
/dev/binder unsuccessfully.
Bug: 137216568
Test: TH
Change-Id: I8dc9dac0592784a16ae0abd270718ae353aa81c3
These weren't enabled because of the below bug causing denials.
Bug: 113083310
Bug: 121035042
Test: no denials
Change-Id: Ie32a5c99f1488fdbfcabb19aff8fa1f3ff2c7b63
1) restart thermalservice if servicemanager dies
2) restart zygote if thermalservice dies as we don't have death notifier
registered for this native service
3) set to foreground task for thermalservice to speed the callback
Fixes: 118495176
Bug: 113037689
Bug: 118509057
Test: kill and see service restarts
Change-Id: I50785592a19b7a667a4f1ff42bc9ea218e81f758
Unlike android.os.WorkSource, we only support the leaf UID of the work
chain here for performance reasons.
We use a similar mechanism to how we propagate the StrictMode flags. The
enforceInterface and writeInterfaceToken are used to pass the worksource
through the parcel. enforceInterface/writeInterfaceToken is at least
used by all the services using AIDL.
It might break code which is reading/writing raw parcels. For instance,
a client calling an AIDL service and replicating what enforceInterface
is doing, e.g. service_manager.c. This is the only client which seems to
do that.
Here is an example of how this API is supposed to be used:
Binder.setThreadWorkSource(uid);
try {
// Call an API.
} finally {
Binder.clearThreadWorkSource();
}
An alternative would be to clear the work source automatically on behalf
of the caller. Manually setting the work source has been chosen to give
more control to callers of the API:
- they might choose to call setThreadWorkSource once and do multiple binder calls
- callers can also decide whether they want to restore the work source
to the orginal
value.
We do not throw an exception when #setThreadWorkSource overrides an
existing work source. It would be really hard to figure when it is safe
to call #setThreadWorkSource. For instance, adding a binder transaction
might make some code down the line that calls #setThreadWorkSource throw
an exception (because the binder transaction would set the work source
on the thread).
Ran the binder performance test suite
(test/vts-testcase/performance/binder_benchmark/binder_performance_test/).
There is no difference in terms of cpu/real time:
- without patch
{
"name": "BM_sendVec_binder/4",
"iterations": 43088,
"real_time": 3.0151086752702871e+04, // yes, time is higher without patch
"cpu_time": 1.4715999326958785e+04,
"time_unit": "ns"
{
"name": "BM_sendVec_binder/8",
"iterations": 48335,
"real_time": 2.8371138740033064e+04,
"cpu_time": 1.3710703486086690e+04,
"time_unit": "ns"
},
- with patch
{
"name": "BM_sendVec_binder/4",
"iterations": 48214,
"real_time": 2.8613625191853276e+04,
"cpu_time": 1.4305279856473226e+04,
"time_unit": "ns"
},
{
"name": "BM_sendVec_binder/8",
"iterations": 49998,
"real_time": 2.8749066382655215e+04,
"cpu_time": 1.4422315992639707e+04,
"time_unit": "ns"
},
Test: unit tests and manually tested on my phone
Change-Id: I167abbbfa6e7c4b0933c4cafa04df810f4814e2b
This function only uses vendor APIs even on non-VNDK devices. This
is to support the usecase of vndservicemanager on a legacy device
which has the VNDK disabled.
Bug: 113083310
Test: boot up device and see usage of /system/etc/event-log-tags
denials go away.
Change-Id: I0fd86cce303bf169f6d5b1b873221302e5b260b1
libselinux now becomes a vendor_available:true library.
Bug: 66914194
Test: lunch aosp_arm64_ab-userdebug; m vndservicemanager
Change-Id: I9885c8656f42f79cf218d978feff79a47d16e1b3
Modify IServiceManger 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: mmm -j32 frameworks/native/cmds/dumpsys && \
adb sync data && adb shell /data/nativetest/dumpsys_test/dumpsys_test && \
adb shell /data/nativetest64/dumpsys_test/dumpsys_test && \
printf "\n\n#### ALL TESTS PASSED ####\n"
Change-Id: Ibccba63035ace9970c2967a621ee2ad8d15cbeea
libselinux_vendor is part of VNDK. No need to statically link
to it anymore.
Bug: 37343404
Test: Build and boot
Test: 'vndservice list' to ensure all services are listed as before
Change-Id: I5b3151f44f7b77ce0f2ff4bba38550a3d7e35375
Signed-off-by: Sandeep Patil <sspatil@google.com>
Merged-In: I5b3151f44f7b77ce0f2ff4bba38550a3d7e35375
