از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
می توانید کدهای کامپایل شده مشروط را برای خواندن پویا مقادیر از رابط HAL تغییر دهید. به عنوان مثال:
#ifdef TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS
// some code fragment
#endif
سپس کد چارچوب می تواند یک تابع ابزار مناسب تعریف شده در <configstore/Utils.h> را بسته به نوع آن فراخوانی کند.
مثال ConfigStore
این مثال خواندن TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS را نشان می دهد که در ConfigStore HAL به عنوان forceHwcForVirtualDisplays() با نوع بازگشتی OptionalBool تعریف شده است:
#include <configstore/Utils.h>
using namespace android::hardware::configstore;
using namespace android::hardware::configstore::V1_0;
static bool vsyncPhaseOffsetNs = getBool<ISurfaceFlingerConfigs,
ISurfaceFlingerConfigs::forceHwcForVirtualDisplays>(false);
تابع ابزار ( getBool در مثال بالا) با سرویس configstore تماس می گیرد تا دسته پروکسی تابع رابط را دریافت کند، سپس با فراخوانی دسته از طریق HIDL/hwbinder، مقدار را بازیابی می کند.
توابع سودمند
<configstore/Utils.h> ( configstore/1.0/include/configstore/Utils.h ) توابع ابزاری را برای هر نوع بازگشتی اولیه، از جمله Optional[Bool|String|Int32|UInt32|Int64|UInt64] ، به شرح زیر ارائه می دهد:
defValue یک مقدار پیشفرض است که زمانی که پیادهسازی HAL مقداری را برای آیتم پیکربندی تعیین نمیکند، بازگردانده میشود. هر تابع دو پارامتر الگو را می گیرد:
I نام کلاس رابط است.
Func نشانگر تابع عضو برای دریافت آیتم پیکربندی است.
از آنجایی که مقدار پیکربندی فقط خواندنی است و تغییر نمی کند، تابع ابزار به صورت داخلی مقدار پیکربندی را ذخیره می کند. تماسهای بعدی با استفاده از مقدار ذخیرهشده در همان واحد پیوندی، با کارایی بیشتری انجام میشوند.
از configstore-utils استفاده کنید
ConfigStore HAL به گونهای طراحی شده است که برای ارتقاء نسخههای جزئی سازگار باشد، به این معنی که وقتی HAL اصلاح میشود و برخی از کدهای چارچوب از آیتمهای معرفیشده جدید استفاده میکنند، سرویس ConfigStore با یک نسخه فرعی قدیمی در /vendor همچنان میتواند استفاده شود.
برای سازگاری پیش رو، مطمئن شوید که پیاده سازی شما از دستورالعمل های زیر پیروی می کند:
موارد جدید زمانی از مقدار پیش فرض استفاده می کنند که فقط سرویس نسخه قدیمی موجود باشد. مثال:
service = V1_1::IConfig::getService(); // null if V1_0 is installed
value = DEFAULT_VALUE;
if(service) {
value = service->v1_1API(DEFAULT_VALUE);
}
مشتری از اولین رابط استفاده می کند که شامل آیتم ConfigStore است. مثال:
V1_1::IConfig::getService()->v1_0API(); // NOT ALLOWED
V1_0::IConfig::getService()->v1_0API(); // OK
سرویس نسخه جدید را می توان برای رابط نسخه قدیمی بازیابی کرد. در مثال زیر، اگر نسخه نصب شده v1_1 باشد، سرویس v1_1 باید برای getService() برگردانده شود:
V1_0::IConfig::getService()->v1_0API();
هنگامی که توابع دسترسی در کتابخانه configstore-utils برای دسترسی به آیتم ConfigStore استفاده می شود، شماره 1 توسط پیاده سازی و شماره 2 با خطاهای کامپایلر تضمین می شود. به این دلایل، ما قویاً توصیه میکنیم تا جایی که ممکن است از configstore-utils استفاده کنید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# Client-side use\n\n| **Warning:** Android 10 deprecates the ConfigStore HAL and replaces the HAL with system properties. For details, refer to [Configuring](/docs/core/architecture/configuration).\n\nYou can refactor conditionally compiled code to read values dynamically from\nthe HAL interface. For example: \n\n```\n#ifdef TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS\n// some code fragment\n#endif\n```\n\nFramework code can then call an appropriate utility function defined in\n`\u003cconfigstore/Utils.h\u003e` depending on its type.\n\nConfigStore example\n-------------------\n\nThis example shows reading\n`TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS`, defined in ConfigStore HAL\nas `forceHwcForVirtualDisplays()` with return type\n`OptionalBool`: \n\n```\n#include \u003cconfigstore/Utils.h\u003e\nusing namespace android::hardware::configstore;\nusing namespace android::hardware::configstore::V1_0;\n\nstatic bool vsyncPhaseOffsetNs = getBool\u003cISurfaceFlingerConfigs,\n ISurfaceFlingerConfigs::forceHwcForVirtualDisplays\u003e(false);\n```\n\nThe utility function (`getBool` in the example above) contacts the\n`configstore` service to get the handle for the proxy of the\ninterface function, then retrieves the value by invoking the handle via\nHIDL/hwbinder.\n\nUtility functions\n-----------------\n\n`\u003cconfigstore/Utils.h\u003e`\n(`configstore/1.0/include/configstore/Utils.h`) provides utility\nfunctions for each primitive return type, including\n`Optional[Bool|String|Int32|UInt32|Int64|UInt64]`, as listed\nbelow:\n\n| Type | Function *(template parameters omitted)* |\n|------------------|------------------------------------------------------|\n| `OptionalBool` | `bool getBool(const bool defValue)` |\n| `OptionalInt32` | `int32_t getInt32(const int32_t defValue)` |\n| `OptionalUInt32` | `uint32_t getUInt32(const uint32_t defValue)` |\n| `OptionalInt64` | `int64_t getInt64(const int64_t defValue)` |\n| `OptionalUInt64` | `uint64_t getUInt64(const uint64_t defValue)` |\n| `OptionalString` | `std::string getString(const std::string &defValue)` |\n\n`defValue` is a default value returned when the HAL implementation\ndoesn't specify a value for the configuration item. Each function takes two\ntemplate parameters:\n\n- **I** is the interface class name.\n- **Func** is the member function pointer for getting the configuration item.\n\nBecause the configuration value is read-only and doesn't change, the utility\nfunction internally caches the configuration value. Subsequent calls are\nserviced more efficiently using the cached value in the same linking unit.\n\nUse configstore-utils\n---------------------\n\nThe ConfigStore HAL is designed to be forward compatible for minor version\nupgrades, meaning that when the HAL is revised and some framework code\nuses the newly introduced items, the ConfigStore service with an older minor\nversion in `/vendor` can still be used.\n\nFor forward compatibility, ensure that your implementation adheres to the\nfollowing guidelines:\n\n1. New items use the default value when *only* the old version's service is available. Example: \n\n ```\n service = V1_1::IConfig::getService(); // null if V1_0 is installed\n value = DEFAULT_VALUE;\n if(service) {\n value = service-\u003ev1_1API(DEFAULT_VALUE);\n }\n ```\n2. The client uses the first interface that included the ConfigStore item. Example: \n\n ```\n V1_1::IConfig::getService()-\u003ev1_0API(); // NOT ALLOWED\n\n V1_0::IConfig::getService()-\u003ev1_0API(); // OK\n ```\n3. The new version's service can be retrieved for old version's interface. In the following example, if the installed version is v1_1, the v1_1 service must be returned for `getService()`: \n\n ```\n V1_0::IConfig::getService()-\u003ev1_0API();\n ```\n | **Note:** The [current\n | AOSP implementation](https://android-review.googlesource.com/c/393736/) satisfies this requirement.\n\nWhen the access functions in the `configstore-utils` library are\nused for accessing the ConfigStore item, #1 is guaranteed by the implementation\nand #2 is guaranteed by compiler errors. For these reasons, we strongly\nrecommend using `configstore-utils` wherever possible."]]