راه‌اندازی کیوسک اندروید: چه کاری انجام دهید وقتی مالک دستگاه شما را از تنظیمات خارج می‌کند

ا تبلت اندرویدی ۱۰٫۱ اینچی برای استفاده در حالت کیوسک با ADB، یک راه‌انداز سفارشی و مالک دستگاه پیکربندی شده بود. پس از راه‌اندازی مجدد، برنامه به‌درستی اجرا شد، اما دستگاه دیگر نتوانست به رابط عادی تنظیمات اندروید دسترسی پیدا کند.

این موضوع چالشی رایج در پیاده‌سازی کیوسک ایجاد کرد: پس از محدود کردن قابلیت‌های ناوبری سیستم و کنترل‌های مدیریت دستگاه، چگونه می‌توان تبلت را برای تست‌های بعدی بازیابی کرد؟ و اگر برنامه نیاز داشت Wi-Fi یا سایر قابلیت‌های سیستمی را باز کند، کدام Intentهای اندروید هنوز قابل استفاده هستند؟

مشتری ابتدا از دستورات ADB برای تغییر رفتار رابط کاربری سیستم استفاده کرد:

adb shell settings put system hide_navbar 1

adb shell settings put system statusbar_disp 1

adb shell settings put system swipe_show_nav_bar 0

adb shell settings put system power_button_show 0

سپس برنامه به‌عنوان صفحه اصلی (Home screen) پیش‌فرض تنظیم شد و بعد از آن، برنامه به‌عنوان مالک دستگاه (Device Owner) برای فعال‌سازی عملکردهای مدیریت دستگاه مورد نیاز.

پس از راه‌اندازی مجدد، تبلت کیوسک اندروید به‌صورت خودکار وارد برنامه شد، همان‌طور که انتظار می‌رفت. با این حال، مشتری دیگر نمی‌توانست از صفحه اصلی برنامه خارج شود تا به تنظیمات اندروید یا سایر عملکردهای سیستم دسترسی پیدا کند. دکمه‌های تنظیمات و وای‌فای که درون برنامه گنجانده شده بودند نیز دیگر صفحات مربوطه سیستم را باز نمی‌کردند.

سوال فوری این نبود که چگونه از برنامه خارج شویم. بلکه مشتری به روشی قابل اعتماد برای بازیابی تابلت اندروید برای آزمایش‌های بیشتر نیاز داشت و همچنین می‌خواست بداند کدام اینتندهای سیستمی می‌توانند توسط برنامه‌شان استفاده شوند.

دلیل سخت‌شدن دسترسی به تبلت اندروید چیست؟

این مشکل ناشی از اعمال همزمان چند لایه کنترل دستگاه بود.

راه‌انداز سفارشی تعیین می‌کرد که کدام برنامه به‌عنوان صفحهٔ اصلی نمایش داده شود، در حالی که مالک دستگاه کنترل گسترده‌تری بر سیاست‌های دستگاه به برنامه می‌داد. مستندات اختصاصی اندروید برای دستگاه‌های ویژه، این نوع پیکربندی را برای استقرارهای کیوسک و دستگاه‌های مدیریت‌شده پشتیبانی می‌کند؛ از جمله کنترل برنامهٔ پیش‌فرض صفحهٔ اصلی و محدود کردن دسترسی به عملکردهای سیستم.

دستورات ADB لایه‌ای دیگر را با تغییر رفتار رابط کاربری سیستم اضافه کردند. این تنظیمات خاص، وابسته به دستگاه یا فرم‌ورِ آن هستند و نه APIهای عمومی اندروید، بنابراین اثر دقیق آن‌ها بستگی به نحوهٔ پیاده‌سازی آن‌ها در فرم‌ور تبلت دارد.

این بدان معناست که یک تبلت اندرویدی که به‌عنوان دستگاه کیوسک استفاده می‌شود ممکن است هنگامی که راه‌انداز، پیکربندی مالک دستگاه، محدودیت‌های رابط کاربری سیستم و ناوبری برنامه همگی به‌طور همزمان تغییر کنند، بازیابی‌اش دشوار گردد.

این واقعیت که دکمه‌های تنظیمات یا وای‌فای برنامه دیگر کار نمی‌کنند لزوماً به معنای نادرست بودن اینتنت نیست. فعالیت تنظیمات هدف ممکن است در پیکربندی فعلی دستگاه در دسترس نباشد، محدود شده باشد یا به هر نحو دیگری قابل دسترسی نباشد. اندروید همچنین توصیه می‌کند قبل از تلاش برای اجرای یک اینتنت، ابتدا بررسی کنید که آیا اینتنت قابل حل‌سازی است یا خیر.

مسیرهای بازیابی برای تبلت کیوسک اندروید قفل‌شده

اگر برنامه از پیش به‌عنوان مالک دستگاه پیکربندی شده باشد، اولین گزینه‌ی قابل بررسی، روش بازیابی مبتنی بر نرم‌افزار است.

اندروید DevicePolicyManager تابع‌های مدیریت دستگاهی را فراهم می‌کند که می‌تواند توسط مالک دستگاه استفاده شود. بسته به نسخه‌ی اندروید و پیکربندی برنامه، یک برنامه‌ی مالک دستگاه می‌تواند از مکانیزم مناسب پاک‌سازی دستگاه استفاده کند تا تبلت را به حالت تمیزی برای تست بازگرداند. wipeData() aPI استاندارد برای پاک‌سازی داده‌های کاربر است، در حالی که نسخه‌های جدیدتر اندروید قابلیت‌های اضافی پاک‌سازی دستگاه را نیز ارائه می‌دهند.

منسوخ‌شده‌ی clearDeviceOwnerApp() روش باید به‌عنوان روشی کلی برای بازیابی تولیدی در نظر گرفته نشود. اندروید آن را به‌عنوان یک رابط برنامه‌نویسی (API) مختص تست مستندسازی کرده و بازنشانی کارخانه‌ای را به‌عنوان روش عادی برای حذف رابطهٔ مالک دستگاه توصیه می‌کند.

ADB همچنین دستورات مدیریت سیاست دستگاه را فراهم می‌کند، اما این دستورات محدودیت‌هایی دارند. به‌عنوان مثال، adb shell dpm remove-active-admin روشی جهانی برای حذف مالک دستگاه نیست؛ مستندات ADB اندروید شرایطی مانند اعلام «testOnly» در برنامه را مشخص می‌کنند. testOnly اعلام.

اگر بازیابی نرم‌افزاری به‌دلیل اینکه برنامه نمی‌تواند عملیات مورد نیاز را اجرا کند، در دسترس نباشد، تنها راه باقی‌مانده، بازنشانی سخت‌افزاری کارخانه‌ای یا روش بازیابی اندروید است. .

ترکیب دقیق دکمه‌ها نباید از مدل دیگری از تبلت‌های اندرویدی پیش‌بینی شود. رفتار بازیابی توسط فرم‌웨ر و پیاده‌سازی سخت‌افزاری تبلت تعیین می‌شود. بنابراین، برای پروژه‌های تبلت اندرویدی سفارشی‌سازی‌شده، روش مناسب بازیابی باید پیش از استقرار، برای مدل واقعی و فرم‌웨ر مربوطه تأیید شود.

برای این نوع تبلت کیوسک اندروید داشتن روشی تعریف‌شده برای بازیابی به‌ویژه در آزمون یکپارچه‌سازی مفید است، زیرا پیکربندی سطح سیستم می‌تواند عمداً ناوبری عادی کاربر را حذف کند.

آزمون قصدِ تنظیمات و عملکردهای سیستم روی تبلت اندروید

دومین پرسش مشتری این بود که آیا این برنامه می‌تواند عملکردهای سیستمی مانند تنظیمات و وای‌فای را مستقیماً راه‌اندازی کند یا خیر.

اندروید برای این عملکردها اقدام‌های استاندارد تنظیمات را فراهم می‌کند. به‌عنوان مثال:

عملکرد	قصد استاندارد اندروید
تنظیمات اصلی	Settings.ACTION_SETTINGS
تنظیمات وای‌فای	Settings.ACTION_WIFI_SETTINGS
تنظیمات بی‌سیم	Settings.ACTION_WIRELESS_SETTINGS
تنظیمات بلوتوث	Settings.ACTION_BLUETOOTH_SETTINGS
تنظیمات نمایش	Settings.ACTION_DISPLAY_SETTINGS
تنظیمات موقعیت‌یابی	Settings.ACTION_LOCATION_SOURCE_SETTINGS
تنظیمات صدا	Settings.ACTION_SOUND_SETTINGS
تنظیمات امنیتی	Settings.ACTION_SECURITY_SETTINGS
تنظیمات برنامه	Settings.ACTION_APPLICATION_SETTINGS
تنظیمات خاص برنامه	Settings.ACTION_APPLICATION_DETAILS_SETTINGS

 

این‌ها عملیات استاندارد تنظیمات اندروید هستند، نه رابط‌هایی که به طور خاص برای یک سازندهٔ خاص تبلت اندرویدی طراحی شده‌اند . با این حال، وجود یک اینتنت تضمین‌کنندهٔ باز شدن موفقیت‌آمیز آن روی همهٔ دستگاه‌ها یا در همهٔ پیکربندی‌های کیوسک نیست. اندروید توصیه می‌کند قبل از اجرای آن، اینتنت را با روش resolveActivity() بررسی کنید.

برای یک تبلت اندرویدی که به‌صورت یکپارچه در سیستم ادغام شده است، آزمون اینتنت باید روی فرم‌ور و نسخهٔ اندرویدی که واقعاً برای استقرار استفاده می‌شود انجام شود. این آزمون نباید صرفاً وجود اینتنت را بررسی کند، بلکه باید تأیید کند که فعالیت مربوطه پس از اعمال محدودیت‌های مالک دستگاه، برنامهٔ راه‌انداز و رابط کاربری سیستم قابل دسترسی است.

اگر در پروژه‌ای مانند تبلت کیوسک اندروید یا ادغام سیستم فعالیت دارید و در زمینهٔ بازیابی مالک دستگاه (Device Owner)، اینتن‌های تنظیمات (Settings Intents) یا سایر مسائل مربوط به پیکربندی کمک نیاز دارید، لطفاً با ما تماس بگیرید و مدل تبلت و نسخهٔ اندروید خود را اعلام کنید. می‌توانیم گزینه‌های پشتیبانی فنی و سفارشی‌سازی موجود را بررسی کنیم.

 

همین اصل بر سایر عملکردهای سیستم نیز اعمال می‌شود. ممکن است یک API استاندارد اندروید وجود داشته باشد، اما رفتار واقعی تبلت سفارشی‌شده بستگی به نسخهٔ اندروید، پیکربندی فرم‌ور و سیاست‌های مدیریت دستگاه دارد.

درخواست‌های بیدارسازی چگونه هستند؟

سوال مشتری دربارهٔ «درخواست‌های بیدارسازی» کمی متفاوت از راه‌اندازی صفحهٔ تنظیمات است.

Intent.ACTION_SCREEN_ON نمایانگر یک پخش سیستمی است که نشان‌دهندهٔ فعال شدن تعاملی صفحه نمایش است. این یک پخش سیستمی محافظت‌شده است؛ بنابراین برنامه‌ها نباید آن را به‌عنوان یک اینتنت معمولی در نظر بگیرند که می‌توانند به‌سادگی برای بیدار کردن تبلت ارسال کنند.

اگر نیاز این باشد که صفحه نمایش را بیدار کنید، صفحه نمایش را روشن نگه دارید یا رفتار روشن‌شدن صفحه را کنترل کنید ، مکانیزم مناسب بستگی به نیاز دقیق کاربرد دارد. اندروید برای این سناریوها از واسط‌های مدیریت توان و پنجره/فعالیت استفاده می‌کند، از جمله PowerManager و قابلیت قفل بیداری (wake-lock) در صورت لزوم.

این تمایز هنگام توسعهٔ برنامه‌ها برای یک تبلت کیوسک اندروید . «اجرای یک تابع سیستمی» و «کنترل وضعیت توان دستگاه» عملیات سیستمی متفاوتی هستند و باید از طریق واسط‌های متفاوتی مدیریت شوند.

پشتیبانی فنی برای ادغام تبلت اندروید

این مورد همچنین نشان می‌دهد که استقرار حالت کیوسک ممکن است نیازمند بیش از پیکربندی سخت‌افزاری پایهٔ یک تبلت اندروید باشد.

هنگامی که یک تبلت در یک برنامهٔ اختصاصی، سیستم فروش در نقطهٔ فروش (POS)، کیوسک، سیستم صنعتی یا سایر دستگاه‌های مدیریت‌شده ادغام می‌شود، پیکربندی نرم‌افزاری ممکن است همزمان شامل راه‌انداز (launcher)، مالک دستگاه (Device Owner)، رابط کاربری سیستم، مجوزهای برنامه، اهداف تنظیمات (Settings Intents) و رفتار بازیابی باشد.

پروژه‌هایی که نیازمند تبلت اندروید سفارشی‌سازی‌شده پیکربندی‌ها، این نیازمندی‌ها باید همراه با پیکربندی سخت‌افزار و سیستم عامل اندروید ارزیابی شوند، نه اینکه در آزمون نهایی به‌صورت مسائل جداگانه در نظر گرفته شوند.

راه‌حل مناسب بستگی به نسخهٔ اندروید، فرم‌ورِ تبلت، پیکربندی برنامه و قابلیت‌هایی دارد که ادغام‌کنندهٔ سیستم باید کنترل کند. مستندات فنی نیز می‌تواند بر اساس رابط‌های موجود در سیستم، اینتندهای پشتیبانی‌شده، مجوزها و محدودیت‌های خاص دستگاه تهیه شود.

اگر در حال آزمون یک تابلت اندروید برای استقرار کیوسک یا ادغام سیستم هستید و با مشکلات مشابهی در زمینهٔ مالک دستگاه، لانچرهای سفارشی، حالت کیوسک، اینتندهای تنظیمات، محدودیت‌های رابط کاربری سیستم یا بازیابی دستگاه مواجه می‌شوید ، لطفا تماس با ما برای پشتیبانی فنی .

می‌توانید مدل تبلت، نسخهٔ اندروید، پیکربندی استقرار و قابلیت خاصی که می‌خواهید پیاده‌سازی کنید را ارائه دهید. سپس می‌توانیم دربارهٔ گزینه‌های موجود برای سفارشی‌سازی تبلت اندروید و پشتیبانی فنی بحث کنیم برای پروژه شما.