servicemanager: remove performance hack

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
This commit is contained in:
Steven Moreland 2020-04-30 16:51:56 -07:00
parent d838f6933d
commit d221c25182

View file

@ -72,13 +72,20 @@ static bool meetsDeclarationRequirements(const sp<IBinder>& binder, const std::s
#endif // !VENDORSERVICEMANAGER
ServiceManager::ServiceManager(std::unique_ptr<Access>&& access) : mAccess(std::move(access)) {
#ifndef VENDORSERVICEMANAGER
// can process these at any times, don't want to delay first VINTF client
std::thread([] {
vintf::VintfObject::GetDeviceHalManifest();
vintf::VintfObject::GetFrameworkHalManifest();
}).detach();
#endif // !VENDORSERVICEMANAGER
// TODO(b/151696835): reenable performance hack when we solve bug, since with
// this hack and other fixes, it is unlikely we will see even an ephemeral
// failure when the manifest parse fails. The goal is that the manifest will
// be read incorrectly and cause the process trying to register a HAL to
// fail. If this is in fact an early boot kernel contention issue, then we
// will get no failure, and by its absence, be signalled to invest more
// effort in re-adding this performance hack.
// #ifndef VENDORSERVICEMANAGER
// // can process these at any times, don't want to delay first VINTF client
// std::thread([] {
// vintf::VintfObject::GetDeviceHalManifest();
// vintf::VintfObject::GetFrameworkHalManifest();
// }).detach();
// #endif // !VENDORSERVICEMANAGER
}
ServiceManager::~ServiceManager() {
// this should only happen in tests
@ -547,4 +554,4 @@ Status ServiceManager::tryUnregisterService(const std::string& name, const sp<IB
return Status::ok();
}
} // namespace android
} // namespace android