2. 程式人生 > >AndroidO Treble架構下Hal程序啟動及HIDL服務註冊過程--不全

AndroidO Treble架構下Hal程序啟動及HIDL服務註冊過程--不全

阿新 • • 發佈：2018-12-16

通過前面對Treble架構的介紹，我們知道，Android Framework程序和Hal分離，每個Hal獨立執行在自己的程序地址空間，那麼這些Hal程序是如何啟動的呢？本文以composer hal為例展開分析。

在以下路徑有composer hal的rc啟動指令碼：

hardware/interfaces/graphics/composer/2.1/default/[email protected]

  1. service hwcomposer-2-1 /vendor/bin/hw/[email protected]
  2.     class hal animation
  3.     user system
  4.     group graphics drmrpc
    5.  
  5.     capabilities SYS_NICE
  6.     onrestart restart surfaceflinger

編譯後，會將該指令碼檔案copy到vendor/etc/init目錄，在開機時，init程序會讀取並解析這個指令碼，然後啟動[email protected]程序：

system         661     1   32288   7832 0                   0 S [email protected]

該程序的可執行檔案是：vendor/bin/hw/[email protected]，

該可執行檔案對應的原始碼為：hardware/interfaces/graphics/composer/2.1/default/service.cpp

composer Hal啟動過程

hardware/interfaces/graphics/composer/2.1/default/service.cpp

  1. int main() {
  2.     // the conventional HAL might start binder services
  3.     android::ProcessState::initWithDriver("/dev/vndbinder");
  4.     android::ProcessState::self()->setThreadPoolMaxThreadCount(4);
  5.     android::ProcessState::self()->startThreadPool();
    6.  
  6.     // same as SF main thread
  7.     struct sched_param param = {0};
  8.     param.sched_priority = 2;
  9.     if (sched_setscheduler(0, SCHED_FIFO | SCHED_RESET_ON_FORK,
  10.                 ¶m) != 0) {
  11.         ALOGE("Couldn't set SCHED_FIFO: %d", errno);
  12.     }
  13.     return defaultPassthroughServiceImplementation<IComposer>(4);
  14. }
前面我們分析了Treble架構下的binder通訊變化，在Treble架構下，存在了3個binder裝置，分別是/dev/binder、/dev/vndbinder、/dev/hwbinder，上層需要通過binder庫來訪問這些binder裝置，而/dev/binder和/dev/vndbinder都是由libbinder來訪問，因此需要指定開啟的binder裝置。
android::ProcessState::initWithDriver("/dev/vndbinder");
這句說明composer hal通過vndbinder來通訊的，接下來就是設定binder執行緒個數為4，並啟動binder執行緒池，然後呼叫
defaultPassthroughServiceImplementation<IComposer>(4)

完成composer hal的啟動。

system\libhidl\transport\include\hidl\LegacySupport.h

  1. template<class Interface>
  2. __attribute__((warn_unused_result))
  3. status_t defaultPassthroughServiceImplementation(std::string name,
  4.                                             size_t maxThreads = 1) {
  5.     configureRpcThreadpool(maxThreads, true); //配置binder執行緒個數
  6.     status_t result = registerPassthroughServiceImplementation<Interface>(name);
  7.     if (result != OK) {
  8.         return result;
  9.     }
  10.     joinRpcThreadpool();
  11.     return 0;
  12. }
  1. template<class Interface>
  2. __attribute__((warn_unused_result))
  3. status_t registerPassthroughServiceImplementation(
  4.         std::string name = "default") {
  5.     sp<Interface> service = Interface::getService(name, true /* getStub */); //從當前程序空間中拿到IComposer介面類物件
  6.     if (service == nullptr) {
  7.         ALOGE("Could not get passthrough implementation for %s/%s.",
  8.             Interface::descriptor, name.c_str());
  9.         return EXIT_FAILURE;
  10.     }
  11.     LOG_FATAL_IF(service->isRemote(), "Implementation of %s/%s is remote!",
  12.             Interface::descriptor, name.c_str());
  13.     status_t status = service->registerAsService(name);//將IComposer註冊到hwservicemanager中
  14.     if (status == OK) {
  15.         ALOGI("Registration complete for %s/%s.",
  16.             Interface::descriptor, name.c_str());
  17.     } else {
  18.         ALOGE("Could not register service %s/%s (%d).",
  19.             Interface::descriptor, name.c_str(), status);
  20.     }
  21.     return status;
  22. }

Hal程序獲取IComposer類物件

在composer hal程序啟動時，首先呼叫IComposer 的getService(“default”,true)來獲取IComposer的類物件。

composer\2.1\[email protected]_genc++\gen\android\hardware\graphics\composer\2.1\ComposerAll.cpp

  1. ::android::sp<IComposer> IComposer::getService(const std::string &serviceName, const bool getStub) {
  2.     using ::android::hardware::defaultServiceManager;
  3.     using ::android::hardware::details::waitForHwService;
  4.     using ::android::hardware::getPassthroughServiceManager;
  5.     using ::android::hardware::Return;
  6.     using ::android::sp;
  7.     using Transport = ::android::hidl::manager::V1_0::IServiceManager::Transport;
  8.     sp<IComposer> iface = nullptr;
  9.     const sp<::android::hidl::manager::V1_0::IServiceManager> sm = defaultServiceManager(); //獲取hwservicemanager的代理
  10.     if (sm == nullptr) {
  11.         ALOGE("getService: defaultServiceManager() is null");
  12.         return nullptr;
  13.     }
  14.     Return<Transport> transportRet = sm->getTransport(IComposer::descriptor, serviceName);//查詢IComposer的Transport
  15.     if (!transportRet.isOk()) {
  16.         ALOGE("getService: defaultServiceManager()->getTransport returns %s", transportRet.description().c_str());
  17.         return nullptr;
  18.     }
  19.     Transport transport = transportRet;
  20.     const bool vintfHwbinder = (transport == Transport::HWBINDER);
  21.     const bool vintfPassthru = (transport == Transport::PASSTHROUGH); //Transport型別判斷
  22.     #ifdef __ANDROID_TREBLE__
  23.     #ifdef __ANDROID_DEBUGGABLE__
  24.     const char* env = std::getenv("TREBLE_TESTING_OVERRIDE");
  25.     const bool trebleTestingOverride =  env && !strcmp(env, "true");
  26.     const bool vintfLegacy = (transport == Transport::EMPTY) && trebleTestingOverride;
  27.     #else // __ANDROID_TREBLE__ but not __ANDROID_DEBUGGABLE__
  28.     const bool trebleTestingOverride = false;
  29.     const bool vintfLegacy = false;
  30.     #endif // __ANDROID_DEBUGGABLE__
  31.     #else // not __ANDROID_TREBLE__
  32.     const char* env = std::getenv("TREBLE_TESTING_OVERRIDE");
  33.     const bool trebleTestingOverride =  env && !strcmp(env, "true");
  34.     const bool vintfLegacy = (transport == Transport::EMPTY);
  35.     #endif // __ANDROID_TREBLE__
  36.     //hwbinder方式下獲取IComposer物件
  37.     for (int tries = 0; !getStub && (vintfHwbinder || (vintfLegacy && tries == 0)); tries++) {
  38.         if (tries > 1) {
  39.             ALOGI("getService: Will do try %d for %s/%s in 1s...", tries, IComposer::descriptor, serviceName.c_str());
  40.             sleep(1);
  41.         }
  42.         if (vintfHwbinder && tries > 0) {
  43.             waitForHwService(IComposer::descriptor, serviceName);
  44.         }
  45.         Return<sp<::android::hidl::base::V1_0::IBase>> ret = 
  46.                 sm->get(IComposer::descriptor, serviceName);
  47.         if (!ret.isOk()) {
  48.             ALOGE("IComposer: defaultServiceManager()->get returns %s", ret.description().c_str());
  49.             break;
  50.         }
  51.         sp<::android::hidl::base::V1_0::IBase> base = ret;
  52.         if (base == nullptr) {
  53.             if (tries > 0) {
  54.                 ALOGW("IComposer: found null hwbinder interface");
  55.             }continue;
  56.         }
  57.         Return<sp<IComposer>> castRet = IComposer::castFrom(base, true /* emitError */);
  58.         if (!castRet.isOk()) {
  59.             if (castRet.isDeadObject()) {
  60.                 ALOGW("IComposer: found dead hwbinder service");
  61.                 continue;
  62.             } else {
  63.                 ALOGW("IComposer: cannot call into hwbinder service: %s; No permission? Check for selinux denials.", castRet.description().c_str());
  64.                 break;
  65.             }
  66.         }
  67.         iface = castRet;
  68.         if (iface == nullptr) {
  69.             ALOGW("IComposer: received incompatible service; bug in hwservicemanager?");
  70.             break;
  71.         }
  72.         return iface;
  73.     }
  74.    //passthrough方式下獲取IComposer物件
  75.     if (getStub || vintfPassthru || vintfLegacy) {
  76.         const sp<::android::hidl::manager::V1_0::IServiceManager> pm = getPassthroughServiceManager();
  77.         if (pm != nullptr) {
  78.             Return<sp<::android::hidl::base::V1_0::IBase>> ret = 
  79.                     pm->get(IComposer::descriptor, serviceName);
  80.             if (ret.isOk()) {
  81.                 sp<::android::hidl::base::V1_0::IBase> baseInterface = ret;
  82.                 if (baseInterface != nullptr) {
  83.                     iface = IComposer::castFrom(baseInterface);
  84.                     if (!getStub || trebleTestingOverride) {
  85.                         iface = new BsComposer(iface);
  86.                     }
  87.                 }
  88.             }
  89.         }
  90.     }
  91.     return iface;
  92. } 

這裡通過hwservicemanager獲取當前服務的Tranport型別，Treble中定義的Tranport包括passthrough和binderized，每個hidl服務都在/system/manifest.xml或者/vendor/manifest.xml中指定了對應的Tranport型別：


manifest.xml檔案的讀取和解析都是由hwservicemanager來完成的，此時[email protected]作為hwservicemanager的client端，通過hwservicemanager的binder代理物件來請求hwservicemanager程序查詢IComposer的Transport型別，從上圖可以看出IComposer的Transport被定義為hwbinder，因此：

vintfHwbinder=true
vintfPassthru=false
vintfLegacy=false

hidl服務物件獲取方式包括2中：

1. 通過查詢hwservicemanager來獲取；

2.通過PassthroughServiceManager從本程序地址空間中獲取；

那如何選擇獲取方式呢？ 其實就是vintfHwbinder、vintfPassthru、vintfLegacy、getStub這4個變數值來決定hidl服務的獲取方式。

1. 當getStub為true時，不管hal屬於什麼傳輸模式，都採用PassthroughServiceManager獲取介面物件；

2.當getStub為false時，則根據hal傳輸模式來選擇介面獲取方式；

       《1》 當hal模式為Hwbinder時，則從hwservicemanager中查詢；

       《2》當hal傳輸模式為Passthru或Legacy時，則採用PassthroughServiceManager來獲取；

那什麼是Hwbinder，什麼是Passthru及Legacy呢？下圖是google提供的hal的roadmap圖：


  1.     if (getStub || vintfPassthru || vintfLegacy) {
  2.         const sp<::android::hidl::manager::V1_0::IServiceManager> pm = getPassthroughServiceManager();
  3.         if (pm != nullptr) {
  4.             Return<sp<::android::hidl::base::V1_0::IBase>> ret = 
  5.                     pm->get(IComposer::descriptor, serviceName);
  6.             if (ret.isOk()) {
  7.                 sp<::android::hidl::base::V1_0::IBase> baseInterface = ret;
  8.                 if (baseInterface != nullptr) {
  9.                     iface = IComposer::castFrom(baseInterface);
  10.                     if (!getStub || trebleTestingOverride) {
  11.                         iface = new BsComposer(iface);
  12.                     }
  13.                 }
  14.             }
  15.         }
  16.     }
sp<Interface> service = Interface::getService(name, true /* getStub */)所以getStub=true. 這裡通過PassthroughServiceManager來獲取IComposer物件。其實所有的Hal 程序都是通過PassthroughServiceManager來得到hidl服務物件的，而作為Hal程序的Client端Framework程序在獲取hidl服務物件時，需要通過hal的Transport型別來選擇獲取方式。system\libhidl\transport\ServiceManagement.cpp
  1. sp<IServiceManager> getPassthroughServiceManager() {
  2.     static sp<PassthroughServiceManager> manager(new PassthroughServiceManager());
  3.     return manager;
  4. }
這裡只是簡單的建立了一個PassthroughServiceManager物件。PassthroughServiceManager也實現了IServiceManager介面。然後通過PassthroughServiceManager詢服務：
  1. Return<sp<IBase>> get(const hidl_string& fqName,
  2.                           const hidl_string& name) override {
  3.         std::string stdFqName(fqName.c_str());
  4.         //fqName looks like [email protected]::IFoo
  5.         size_t idx = stdFqName.find("::");
  6.         if (idx == std::string::npos ||
  7.                 idx + strlen("::") + 1 >= stdFqName.size()) {
  8.             LOG(ERROR) << "Invalid interface name passthrough lookup: " << fqName;
  9.             return nullptr;
  10.         }
  11.         std::string packageAndVersion = stdFqName.substr(0, idx);
  12.         std::string ifaceName = stdFqName.substr(idx + strlen("::"));
  13.         const std::string prefix = packageAndVersion + "-impl";
  14.         const std::string sym = "HIDL_FETCH_" + ifaceName;
  15.         const android_namespace_t* sphal_namespace = android_get_exported_namespace("sphal");
  16.         const int dlMode = RTLD_LAZY;
  17.         void *handle = nullptr;
  18.         // TODO: lookup in VINTF instead
  19.         // TODO(b/34135607): Remove HAL_LIBRARY_PATH_SYSTEM
  20.         dlerror(); // clear
  21.         for (const std::string &path : {
  22.             HAL_LIBRARY_PATH_ODM, HAL_LIBRARY_PATH_VENDOR, HAL_LIBRARY_PATH_SYSTEM
  23.         }) {
  24.             std::vector<std::string> libs = search(path, prefix, ".so");
  25.             for (const std::string &lib : libs) {
  26.                 const std::string fullPath = path + lib;
  27.                 // If sphal namespace is available, try to load from the
  28.                 // namespace first. If it fails, fall back to the original
  29.                 // dlopen, which loads from the current namespace.
  30.                 if (sphal_namespace != nullptr && path != HAL_LIBRARY_PATH_SYSTEM) {
  31.                     const android_dlextinfo dlextinfo = {
  32.                         .flags = ANDROID_DLEXT_USE_NAMESPACE,
  33.                         // const_cast is dirty but required because
  34.                         // library_namespace field is non-const.
  35.                         .library_namespace = const_cast<android_namespace_t*>(sphal_namespace),
  36.                     };
  37.                     handle = android_dlopen_ext(fullPath.c_str(), dlMode, &dlextinfo);
  38.                     if (handle == nullptr) {
  39.                         const char* error = dlerror();
  40.                         LOG(WARNING) << "Failed to dlopen " << lib << " from sphal namespace:"
  41.                                      << (error == nullptr ? "unknown error" : error);
  42.                     } else {
  43.                         LOG(DEBUG) << lib << " loaded from sphal namespace.";
  44.                     }
  45.                 }
  46.                 if (handle == nullptr) {
  47.                     handle = dlopen(fullPath.c_str(), dlMode);
  48.                 }
  49.                 if (handle == nullptr) {
  50.                     const char* error = dlerror();
  51.                     LOG(ERROR) << "Failed to dlopen " << lib << ": "
  52.                                << (error == nullptr ? "unknown error" : error);
  53.                     continue;
  54.                 }
  55.                 IBase* (*generator)(const char* name);
  56.                 *(void **)(&generator) = dlsym(handle, sym.c_str());
  57.                 if(!generator) {
  58.                     const char* error = dlerror();
  59.                     LOG(ERROR) << "Passthrough lookup opened " << lib
  60.                                << " but could not find symbol " << sym << ": "
  61.                                << (error == nullptr ? "unknown error" : error);
  62.                     dlclose(handle);
  63.                     continue;
  64.                 }
  65.                 IBase *interface = (*generator)(name.c_str());
  66.                 if (interface == nullptr) {
  67.                     dlclose(handle);
  68.                     continue; // this module doesn't provide this instance name
  69.                 }
  70.                 registerReference(fqName, name);
  71.                 return interface;
  72.             }
  73.         }
  74.         return nullptr;
  75.     }

根據傳入的fqName=([email protected]::IComposer")獲取當前的介面名IComposer，拼接出後面需要查詢的函式名HIDL_FETCH_IComposer和庫名字[email protected],然後查詢"/system/lib64/hw/"、"/vendor/lib64/hw/"、"/odm/lib64/hw/"下是否有對應的so庫。接著通過dlopen載入/vendor/lib/hw/[email protected]，然後通過dlsym查詢並呼叫HIDL_FETCH_IComposer函式，最後呼叫registerReference(fqName, name)向hwservicemanager註冊。

hardware/interfaces/graphics/composer/2.1/default/Android.bp

  1. cc_library_shared {
  2.     name: "[email protected]",
  3.     defaults: ["hidl_defaults"],
  4.     proprietary: true,
  5.     relative_install_path: "hw",
  6.     srcs: ["Hwc.cpp"],
  7.     static_libs: ["libhwcomposer-client"],
  8.     shared_libs: [
  9.         "[email protected]",
  10.         "[email protected]",
  11.         "libbase",
  12.         "libcutils",
  13.         "libfmq",
  14.         "libhardware",
  15.         "libhidlbase",
  16.         "libhidltransport",
  17.         "liblog",
  18.         "libsync",
  19.         "libutils",
  20.         "libhwc2on1adapter"
  21.     ],
  22. }
從上面的編譯指令碼可知，[email protected]的原始碼檔案為Hwc.cpp：
hardware/interfaces/graphics/composer/2.1/default/Hwc.cpp
  1. IComposer* HIDL_FETCH_IComposer(const char*)
  2. {
  3.     const hw_module_t* module = nullptr;
  4.     int err = hw_get_module(HWC_HARDWARE_MODULE_ID, &module);
  5.     if (err) {
  6.         ALOGE("failed to get hwcomposer module");
  7.         return nullptr;
  8.     }
  9.     return new HwcHal(module);
  10. }
hw_get_module就和AndroidO以前的Hal模式一致，這正是Passthrough複用原有hal的原理。載入hal庫後，得到hw_module_t，然後使用HwcHal來包裹hw_module_t，而HwcHal實現了IComposer介面。

registerPassthroughClient

得到IComposer介面物件HwcHal後，需要註冊相關資訊到hwservicemanager中。


system\libhidl\transport\ServiceManagement.cpp

  1. static void registerReference(const hidl_string &interfaceName, const hidl_string &instanceName) {
  2.     sp<IServiceManager> binderizedManager = defaultServiceManager();
  3.     if (binderizedManager == nullptr) {
  4.         LOG(WARNING) << "Could not registerReference for "
  5.                      << interfaceName << "/" << instanceName
  6.                      << ": null binderized manager.";
  7.         return;
  8.     }
  9.     auto ret = binderizedManager->registerPassthroughClient(interfaceName, instanceName);
  10.     if (!ret.isOk()) {
  11.         LOG(WARNING) << "Could not registerReference for "
  12.                      << interfaceName << "/" << instanceName
  13.                      << ": " << ret.description();
  14.         return;
  15.     }
  16.     LOG(VERBOSE) << "Successfully registerReference for "
  17.                  << interfaceName << "/" << instanceName;
  18. }
這裡通過hwservicemanager的代理物件跨程序呼叫registerPassthroughClient。

[email protected]_genc++\gen\android\hidl\manager\1.0\ServiceManagerAll.cpp

  1. ::android::hardware::Return<void> BpHwServiceManager::registerPassthroughClient(const ::android::hardware::hidl_string& fqName, const ::android::hardware::hidl_string& name){
  2.     ::android::hardware::Return<void>  _hidl_out = ::android::hidl::manager::V1_0::BpHwServiceManager::_hidl_registerPassthroughClient(this, this, fqName, name);
  3.     return _hidl_out;
  4. }
  1. ::android::hardware::Return<void> BpHwServiceManager::_hidl_registerPassthroughClient(::android::hardware::IInterface *_hidl_this, ::android::hardware::details::HidlInstrumentor *_hidl_this_instrumentor, const ::android::hardware::hidl_string& fqName, const ::android::hardware::hidl_string& name) {
  2.     #ifdef __ANDROID_DEBUGGABLE__
  3.     bool mEnableInstrumentation = _hidl_this_instrumentor->isInstrumentationEnabled();
  4.     const auto &mInstrumentationCallbacks = _hidl_this_instrumentor->getInstrumentationCallbacks();
  5.     #else
  6.     (void) _hidl_this_instrumentor;
  7.     #endif // __ANDROID_DEBUGGABLE__
  8.     atrace_begin(ATRACE_TAG_HAL, "HIDL::IServiceManager::registerPassthroughClient::client");
  9.     #ifdef __ANDROID_DEBUGGABLE__
  10.     if (UNLIKELY(mEnableInstrumentation)) {
  11.         std::vector<void *> _hidl_args;
  12.         _hidl_args.push_back((void *)&fqName);
  13.         _hidl_args.push_back((void *)&name);
  14.         for (const auto &callback: mInstrumentationCallbacks) {
  15.             callback(InstrumentationEvent::CLIENT_API_ENTRY, "android.hidl.manager", "1.0", "IServiceManager", "registerPassthroughClient", &_hidl_args);
  16.         }
  17.     }
  18.     #endif // __ANDROID_DEBUGGABLE__
  19.     ::android::hardware::Parcel _hidl_data;
  20.     ::android::hardware::Parcel _hidl_reply;
  21.     ::android::status_t _hidl_err;
  22.     ::android::hardware::Status _hidl_status;
  23.     _hidl_err = _hidl_data.writeInterfaceToken(BpHwServiceManager::descriptor);
  24.     if (_hidl_err != ::android::OK) { goto _hidl_error; }
  25.     size_t _hidl_fqName_parent;
  26.     _hidl_err = _hidl_data.writeBuffer(&fqName, sizeof(fqName), &_hidl_fqName_parent);
  27.     if (_hidl_err != ::android::OK) { goto _hidl_error; }
  28.     _hidl_err = ::android::hardware::writeEmbeddedToParcel(
  29.             fqName,
  30.             &_hidl_data,
  31.             _hidl_fqName_parent,
  32.             0 /* parentOffset */);
  33.     if (_hidl_err != ::android::OK) { goto _hidl_error; }
  34.     size_t _hidl_name_parent;
  35.     _hidl_err = _hidl_data.writeBuffer(&name, sizeof(name), &_hidl_name_parent);
  36.     if (_hidl_err != ::android::OK) { goto _hidl_error; }
  37.     _hidl_err = ::android::hardware::writeEmbeddedToParcel(
  38.             name,
  39.             &_hidl_data,
  40.             _hidl_name_parent,
  41.             0 /* parentOffset */);
  42.     if (_hidl_err != ::android::OK) { goto _hidl_error; }
  43.     _hidl_err = ::android::hardware::IInterface::asBinder(_hidl_this)->transact(8 /* registerPassthroughClient */, _hidl_data, &_hidl_reply);
  44.     if (_hidl_err != ::android::OK) { goto _hidl_error; }
  45.     _hidl_err = ::android::hardware::readFromParcel(&_hidl_status, _hidl_reply);
  46.     if (_hidl_err != ::android::OK) { goto _hidl_error; }
  47.     if (!_hidl_status.isOk()) { return _hidl_status; }
  48.     atrace_end(ATRACE_TAG_HAL);
  49.     #ifdef __ANDROID_DEBUGGABLE__
  50.     if (UNLIKELY(mEnableInstrumentation)) {
  51.         std::vector<void *> _hidl_args;
  52.         for (const auto &callback: mInstrumentationCallbacks) {
  53.             callback(InstrumentationEvent::CLIENT_API_EXIT, "android.hidl.manager", "1.0", "IServiceManager",  
 
    
            
      
    
           
    
              
              
    
            
    
            
    相關推薦
    
			   
            
            
            
 

    

    
    
    
    AndroidO Treble架構下Hal程序啟動及HIDL服務註冊過程--不全
    
     
     
                通過前面對Treble架構的介紹，我們知道，Android Framework程序和Hal分離，每個Hal獨立執行在自己的程序地址空間，那麼這些Hal程序是如何啟動的呢？本文以composer hal為例展開分析。在以下路徑有composer hal的rc啟動指令碼：hard 
    

    
  
 

    

    
    
    
    AndroidO Treble架構下Hal程序啟動及HIDL服務註冊過程
    
     
     
                通過前面對Treble架構的介紹，我們知道，Android Framework程序和Hal分離，每個Hal獨立執行在自己的程序地址空間，那麼這些Hal程序是如何啟動的呢？本文以composer hal為例展開分析。在以下路徑有composer hal的rc啟動指令碼：hard 
    

    
  
 

    

    
    
    
    AndroidO Treble架構下的變化--
    
     
      
  
  
  
   
    
    
   AndroidO引入Treble架構後，有那些變化呢？    1. 增加了多個服務管家，AndroidO之前版本有且只有一個servicemanager，現在增加到3個，他們分管不同的服務。  2. 增加了binder通訊庫，這是為了適配binder域的 
    

    
  
 

    

    
    
    
    AndroidO Treble架構下Tranport型別查詢過程
    
     
     
                通過前面文章的分析，我們知道，Client程序在查詢hidl服務介面物件時，會根據該hidl服務的Tranport型別選擇載入方式，如果是HWBINDER，那麼就從hwservicemanager中查詢，如果是PASSTHROUGH，那麼就通過PassthroughServi 
    

    
  
 

    

    
    
    
    AndroidO Treble架構下的變化
    
     
     
							
							
							AndroidO引入Treble架構後，有那些變化呢？ 
 
1. 增加了多個服務管家，AndroidO之前版本有且只有一個servicemanager，現在增加到3個，他們分管不同的服務。 
2. 增加了binder通訊庫，這是為了適配binder域的擴充套件 
    

    
  
 

    

    
    
    
    AndroidO Treble架構下HIDL服務Java框架實現
    
     
     
							
							
							
                    
            
                前面介紹了HIDL服務在native層的實現過程，包括HIDL服務載入建立、服務註冊、服務查詢過程等，那麼Java層是否也實現了相關的服務框架呢？ 通常情況下， 
    

    
  
 

    

    
    
    
    AndroidO Treble架構下Binder物件的轉換過程
    
     
     
                上文中詳細分析了Hal的整個啟動過程，這裡將補充上文中沒有詳細分析的Binder物件轉換過程，下圖為hidl服務的完整註冊過程：1.  HwcHal繼承於IBase類，是對hw_module_t的封裝，該物件位於Hal程序空間；2.  通過hwservicemanager的b 
    

    
  
 

    

    
    
    
    AndroidO Treble架構下HIDL服務查詢過程
    
     
     
                通過前面的分析我們知道，Hal程序啟動時，會向hwservicemanager程序註冊hidl服務，那麼當Framework Server需要通過hal訪問硬體裝置時，首先需要查詢對應的hidl服務，那麼Client程序是如何查詢hidl服務的呢？這篇文章將展開分析，這裡再次 
    

    
  
 

    

    
    
    
    mac下mysql的啟動及連線
    
     
     
                錯誤：

can't connect to local MySQL server throught socket '/tmp/mysql.sock'(2)

錯誤形式1:



錯誤形式2:

 

解決：

mysql -uroot -h 127.0.0.1 -p

 

 
    

    
  
 

    

    
    
    
    AndroidO Treble架構分析【轉】
    
     
     本文轉載自:https://blog.csdn.net/yangwen123/article/details/79835965 
從AndroidO開始，google引入了Treble架構，目的是為了方便系統升級，將oem定製的東西和Framework分離。AndroidO之前的版本：在此之前的Android 
    

    
  
 

    

    
    
    
    Linux下安裝openldap 啟動及配置一站式搞定
    
     
     
                


外鏈：Tomcat+LDAP完成認證：http://my.oschina.net/xpbug/blog/198765


1、安裝Berkeley DB
wget http://download.oracle.com/berkeley-db/db-4.6.21.tar. 
    

    
  
 

    

    
    
    
    Linux 下Java 程序啟動停止shell指令碼
    
     
     
								
								            
							
							
							1.start.sh



appname=paas-portal
apppath=/data/docker/shared/apps/paas/$appname
configlocation=--spr 
    

    
  
 

    

    
    
    
    linux下檢視程序啟動、執行的時間
    
     
     
								
								            
							
							
							可通過ps 來檢視，通過引數 -o 來檢視 
例：



ps -eo pid,tty,user,comm,lstart,etime | grep init

引數說明：

pid：程序ID

tty： 
    

    
  
 

    

    
    
    
    Android系統init程序啟動及init.rc全解析
    
     
     
							
							
							這是一篇用心寫的部落格，也希望大家用心看並幫忙找到文章的改進之處，謝謝；



服務啟動機制


system/core/init/init.c檔案main函式中parse_config_file(init.rc)讀取並解析init.rc檔案內容。將servic 
    

    
  
 

    

    
    
    
    AndroidO Treble架構分析
    
     
     
                



從AndroidO開始，google引入了Treble架構，目的是為了方便系統升級，將oem定製的東西和Framework分離。

AndroidO之前的版本：




在此之前的Android系統架構當中，Android Framework與Android HAL是 
    

    
  
 

    

    
    
    
    微服務架構下，如何打造別具一格的服務治理體驗？(上)
    
     
     


一、經典微服務架構的特點以及問題


經典的微服務架構一般包含兩個部分：API閘道器，一組微服務。API閘道器是唯一的請求入口，它還要負責負載均衡，路由編排，失效切換等工作。
經典的微服務架構圖（來源網路）:

關於經典微服務架構的文章很多，這裡重點想分享一些我們實踐經典微服務架構的一些問題：



“ 
    

    
  
 

    

    
    
    
    Linux核心啟動及檔案系統載入過程
    
     
     
                



當u-boot開始執行bootcmd命令，就進入linux核心啟動階段
與u-boot類似，普通Linux核心的啟動過程也可以分為兩個階段，但針對壓縮了的核心如uImage就要包括核心自解壓過程了。第一階段為核心自解壓過程，第二階段主要工作是設定ARM處理器 
    

    
  
 

    

    
    
    
    微服務架構幸運28出售理解及微服務架構局限性
    
     
     負載平衡器   資源池   一點   學習   進行   模塊通信   存在   來看   資源   雖然微服務幸運28出售 <Q> 2952777280【源碼鏈接】 hxforum.com  是降低整體結構的最佳方式。然而，它有其自身的一些缺點。但在得出任何結論之前，讓我們來看看其中的一些。
1 
    

    
  
 

    

    
    
    
    vscode原始碼分析【七】主程序啟動訊息通訊服務
    
     
     第一篇： vscode原始碼分析【一】從原始碼執行vscode
第二篇：vscode原始碼分析【二】程式的啟動邏輯，第一個視窗是如何建立的
第三篇：vscode原始碼分析【三】程式的啟動邏輯，效能問題的追蹤
第四篇：vscode原始碼分析【四】程式啟動的邏輯，最初建立的服務
第五篇：vsco 
    

    
  
 

    

    
    
    
    系統架構設計：程序快取和快取服務，如何抉擇？
    
     
     概述
我們所說的快取分為程序內部快取（系統內部快取）和 快取服務（如redis/memcache）。計算機服務從原來的單體結構，到多例項，到現在流行的微服務，快取服務變得原來越流行了。  
程序快取
先說說程序快取，它將資料儲存在站點、服務的程序內。在Web的發展歷史上，這樣的方式備受歡迎