این صفحه یک نمای کلی از APIها، ویژگیها و تغییرات رفتاری جدید معرفی شده در Android 8.0 (سطح API 26) ارائه میکند که بر Android در سازمان تأثیر میگذارد.
API ها و ویژگی های جدید
حالتهای مدیریت مالک نمایه و مالک دستگاه را قویتر، سازندهتر و آسانتر از قبل کردهایم. ما همچنین یک سناریوی استقرار کاملاً جدید را فعال کرده ایم - نمایه های کاری در دستگاه های کاملاً مدیریت شده. این و ویژگی های دیگر در بخش های بعدی توضیح داده شده است.
نمایه های کار در دستگاه های کاملاً مدیریت شده
در Android 8.0، دستگاه های کاملاً مدیریت شده نیز می توانند نمایه کاری داشته باشند. این به شرکتها این امکان را میدهد تا برنامهها و خطمشیها را از هم جدا کنند و در عین حال کنترل و دید را در هر دو نمایه حفظ کنند. مالک دستگاه موجود، یا یک کنترل کننده خط مشی دستگاه دیگر (DPC)، می تواند نمایه مدیریت شده را ایجاد کند.
با نمایه های کاری در دستگاه های کاملاً مدیریت شده، صاحبان دستگاه می توانند:
- با تماس با
EXTRA_PROVISIONING_SKIP_USER_CONSENT
یک نمایه مدیریت شده بدون تعامل کاربر ایجاد کنید. - هنگامی که کاربران ثانویه یا نمایه های مدیریت شده ایجاد یا حذف می شوند، اعلان دریافت کنید. تماسهای برگشتی
onUserAdded()
وonUserRemoved()
هستند. - از ایجاد نمایه های مدیریت شده توسط سایر DPC ها با استفاده از
DISALLOW_ADD_MANAGED_PROFILE
جلوگیری کنید. این تنظیم پیشفرض در Android 8.0 برای دارندگان دستگاه در دستگاههای ارائهشده جدید یا دستگاههای ارتقا یافته به Android 8.0 است. - صاحبان دستگاه همچنین می توانند از حذف نمایه های مدیریت شده موجود با استفاده از
DISALLOW_REMOVE_MANAGED_PROFILE
توسط کاربران جلوگیری کنند.
مالکان دستگاه و مالکان نمایه میتوانند با یکدیگر ارتباط برقرار کنند، اگر از یک APK باشند و مالکان آن وابسته باشند ( وابستگی کاربر را در زیر ببینید).
برای اطلاعات دقیق تر در مورد پشتیبانی از این سناریوی استقرار جدید، صفحه اختصاصی نمایه های کاری در دستگاه های کاملاً مدیریت شده را ببینید.
وابستگی کاربر
وقتی مالک دستگاه و مالک نمایه یک سازمان را نمایندگی می کنند:
صاحبان دستگاه و نمایه میتوانند در یک APK با یکدیگر ارتباط برقرار کنند—ممکن است بخواهند خطمشیها یا وضعیتها را به اشتراک بگذارند (به نمایههای کاری در دستگاههای کاملاً مدیریتشده در بالا مراجعه کنید).
ویژگیهای کل دستگاه، مانند ورود به سیستم یا حالت کار قفل فهرست مجاز، میتوانند برای کاربران وابسته اعمال شوند.
شناسههای وابستگی، پیوست شده به نمایه یا کاربر، سازمانها را شناسایی میکنند. وقتی شناسههای وابستگی مطابقت دارند، کاربران وابسته میشوند. صاحبان دستگاه و صاحبان نمایه از setAffiliationIds() برای تنظیم شناسه های وابستگی خود استفاده می کنند. سازمانهایی را با استفاده از شناسههای رشتهای طولانی و سخت برای حدس زدن نشان دهید.
دسترسی جدید برای کاربران وابسته
اگر همه کاربران ثانویه و نمایههای یک دستگاه به مالک دستگاه وابسته باشند، ویژگیهای زیر در دسترس هستند:
- ثبت امنیت با استفاده از
setSecurityLoggingEnabled()
. - ثبت فعالیت شبکه با استفاده از
setNetworkLoggingEnabled()
. - گزارش اشکال با استفاده از
requestBugreport()
.
گزارش امنیتی و گزارش اشکال قبلاً فقط برای دستگاههای تک کاربره یا دستگاههایی با تنها یک نمایه و یک کاربر در دسترس بود.
حالت کار قفل برای کاربران ثانویه و نمایه های مدیریت شده زمانی که به مالک دستگاه از طریق setLockTaskPackages()
وابسته هستند در دسترس است. برای اطلاعات بیشتر در مورد وابستگی کاربر، به کاربران وابسته مراجعه کنید.
سلب مسئولیت تامین سفارشی
اکنون DPCها می توانند سلب مسئولیت خود را در حین تهیه به کاربران نشان دهند. از EXTRA_PROVISIONING_DISCLAIMERS
، EXTRA_PROVISIONING_DISCLAIMER_HEADER
، و EXTRA_PROVISIONING_DISCLAIMER_CONTENT
برای ارائه سلب مسئولیت نوشتاری سبکدار استفاده کنید. سلب مسئولیت سفارشی DPC در لیست شرایط تاشو ظاهر می شود.
امنیت
دارندگان نمایه و دارندگان دستگاه می توانند از setRequiredStrongAuthTimeout()
برای پیکربندی بازه زمانی باز کردن قفل دستگاه یا نمایه با روش احراز هویت ثانویه، مانند اثر انگشت یا عوامل اعتماد، استفاده کنند. پس از انقضای مدت زمان، کاربر باید قفل دستگاه یا نمایه را با استفاده از روش احراز هویت قوی، مانند رمز عبور، پین یا الگو باز کند.
صاحبان دستگاه و صاحبان نمایه می توانند با استفاده از resetPasswordWithToken()
رمز عبور دستگاه و نمایه کاری را به طور ایمن بازنشانی کنند. برای دستگاههایی که از رمزگذاری مبتنی بر فایل پشتیبانی میکنند، این API قبل از اینکه کاربر قفل دستگاه یا نمایه خود را باز کند در دسترس است، مشروط بر اینکه DPC از رمزگذاری آگاه باشد.
هنگام قفل کردن نمایه کاری در دستگاهی که از رمزگذاری مبتنی بر فایل پشتیبانی میکند، lockNow(int)
میتواند به صورت اختیاری کلیدهای رمزگذاری اولیه نمایه کاری را با استفاده از FLAG_EVICT_CREDENTIAL_ENCRYPTION_KEY
خارج کند. اگر کاربر نمایه کاری خود را خاموش کند، کلیدهای رمزگذاری نیز خارج می شوند.
همچنین، صاحبان دستگاه میتوانند از setNetworkLoggingEnabled()
برای روشن کردن گزارش شبکه پرسوجوهای DNS و اتصالات TCP که از دستگاههای متعلق به شرکت شروع شدهاند، استفاده کنند. برای اطلاعات بیشتر، به گزارش فعالیت شبکه مراجعه کنید.
مالکان نمایه می توانند محدود کنند که کدام یک از بسته های کاربر اصلی می تواند اعلان های نمایه کاری را مشاهده کند. با setPermittedCrossProfileNotificationListeners()
تماس بگیرید تا بسته های مجاز را که رویدادها را از طریق NotificationListenerService
دریافت می کنند تنظیم کنید. با تنظیم شنوندگان مجاز بر روی null
(پیشفرض)، فهرست مجاز غیرفعال میشود و همه بستهها میتوانند برای اعلانها گوش دهند. برای محدود کردن رویدادها به بستههای سیستمی، یک مجموعه خالی ارسال کنید. برای مشاهده برنامههایی که نمیتوانند به اعلانهای نمایه کاری دسترسی پیدا کنند، کاربران میتوانند روی تنظیمات > برنامهها و اعلانها > دسترسی به برنامه ویژه > دسترسی به اعلان ضربه بزنید.
در نهایت، صاحبان نمایه و صاحبان دستگاه می توانند اطلاعات مربوط به به روز رسانی های معلق سیستم را که در دستگاه موجود است با استفاده از getPendingSystemUpdate()
بازیابی کنند.
نمایندگی API مدیریت برنامه
تفویض API به صاحبان دستگاه و صاحبان نمایه امکان می دهد تا مدیریت برنامه را به طور کامل در سایر برنامه ها تخلیه کنند. کلاس DevicePolicyManager
روش هایی را برای مدیریت حوزه های تفویض اختیار ارائه می دهد که صاحبان دستگاه و نمایه می توانند به یک بسته اعطا کنند:
- متد
setDelegatedScopes()
به صاحبان دستگاه و صاحبان نمایه اجازه می دهد تا به برنامه های دیگر دسترسی به APIهای ممتاز را بدهند. - متد
getDelegatedScopes()
دامنه های اعطا شده به یک بسته را برمی گرداند. -
getDelegatePackages()
بسته هایی را که دارای یک محدوده هستند برمی گرداند.
جدول زیر نشان می دهد که چگونه روش های مختلف در DevicePolicyManager
در حوزه های مختلف سازماندهی شده اند:
خدمات پس زمینه طولانی مدت
صاحبان دستگاه و نمایه میتوانند DeviceAdminService
برای ایجاد خدمات پسزمینه زیر کلاس قرار دهند. سیستم اندروید تلاش میکند تا زمانی که کاربر در حال اجراست، سرویس را در حال اجرا نگه دارد. اگر میخواهید کارهای دورهای را اجرا کنید، قبل از ایجاد یک سرویس پسزمینه، از JobScheduler
استفاده کنید.
کنترل سرویس پشتیبان
دارندگان دستگاه میتوانند سرویس پشتیبانگیری Android را با استفاده از روشهای جدید در DevicePolicyManager
تغییر دهند. با استفاده از setBackupServiceEnabled()
سرویس پشتیبان را فعال و غیرفعال کنید. وضعیت سرویس پشتیبان را با استفاده از isBackupServiceEnabled()
بررسی کنید.
پیکربندی پروکسی Wi-Fi
صاحبان دستگاه و صاحبان نمایه می توانند سرورهای پراکسی HTTP را برای شبکه های Wi-Fi پیکربندی کنند. از یک فایل PAC یا تنظیمات دستی برای پیکربندی یک سرور پراکسی برای هر شبکه Wi-Fi استفاده کنید. برای تنظیم یا حذف پراکسی برای یک WifiConfiguration
، متد setHttpProxy()
آن را فراخوانی کنید. برای دریافت تنظیمات پروکسی getHttpProxy()
تماس بگیرید.
گفتگوهای توضیحی برای ویژگیهای غیرفعال شده توسط ادمین
برنامه شما باید توضیح مفیدی را به کاربرانی که سعی در استفاده از یک ویژگی غیرفعال شده توسط سرپرست دارند نشان دهد. همه برنامهها اکنون میتوانند از createAdminSupportIntent()
برای ایجاد یک intent استفاده کنند که وقتی به startActivity(Intent)
منتقل میشود، یک گفتگوی توضیحی را نمایش میدهد. اهداف شامل توضیحات سفارشی شده و محلی برای دوربینهای غیرفعال، عکسبرداری از صفحه غیرفعال، و تمام محدودیتهای UserManager
است.
محدود کردن بلوتوث
دارندگان دستگاه می توانند بلوتوث را غیرفعال کنند—که بر همه کاربران و نمایه های دستگاه تأثیر می گذارد. برای خاموش کردن بلوتوث، محدودیت کاربر DISALLOW_BLUETOOTH
را اضافه کنید.
صاحبان دستگاه و مالکان نمایه میتوانند از ارسال فایلهای کاربران از طریق بلوتوث با استفاده از DISALLOW_BLUETOOTH_SHARING
جلوگیری کنند. دریافت فایل ها تحت تأثیر قرار نمی گیرد. وقتی توسط مالک دستگاه تنظیم شود، DISALLOW_BLUETOOTH_SHARING
برای همه کاربران دستگاه اعمال می شود. این تنظیم پیشفرض در Android 8.0 برای نمایههای جدید و نمایههای موجود در دستگاههای ارتقا یافته به Android 8.0 است.
تغییر رفتار
اگر برای کسبوکارها، از جمله DPCها، برنامه میسازید، باید تغییرات رفتاری زیر را در Android 8.0 مرور کنید و برنامه خود را بر اساس آن اصلاح کنید.
حذف کاربران
صاحبان دستگاه می توانند کاربران ثانویه و نمایه های مدیریت شده را با استفاده از removeUser()
حذف کنند، حتی اگر DISALLOW_REMOVE_USER
فعال باشد.
امنیت
احراز هویت
تغییرات زیر در کلاس DevicePolicyManager
اعمال شده است:
- متد
lockNow()
تنها در صورتی نمایه کاری را قفل می کند که چالش کاری جداگانه فعال باشد. - متد
resetPassword()
دیگر برای DPCهایی که به عنوان دارندگان دستگاه یا مالکان نمایه عمل می کنند و Android 8.0 را هدف قرار می دهند، در دسترس نیست. اگر فراخوانی شود، یک استثنا امنیتی ایجاد می شود. در عوض، DPCها باید ازresetPasswordWithToken()
استفاده کنند.توجه: DPCهایی که Android 7.1.1 (سطح API 25) یا پایینتر را هدف قرار میدهند، و همچنین DPCهایی که فقط دارای امتیازات سرپرست دستگاه هستند، تحت تأثیر این تغییر قرار نمیگیرند.
- برای دستگاههایی که از رمزگذاری مبتنی بر فایل پشتیبانی میکنند،
isActivePasswordSufficient()
قبل از اینکه کاربر قفل دستگاه را برای اولین بار پس از راهاندازی مجدد باز کند، در دسترس نیست. اگر قبل از باز کردن قفل دستگاه توسط کاربر فراخوانی شود، یک استثنا ایجاد می شود.
داده ها از نمایه های کاری قفل شده
Android 8.0 شامل تغییرات رابط کاربری برای جدا کردن داده ها از نمایه کاری قفل شده است.
- اعلانهای برنامهها در نمایه کاری ممکن است اکنون محتوای خود را پنهان کنند. قبلاً کشوی اعلان محتوای برنامههای کاری را از نمایه کاری قفل شده نشان میداد.
- صفحه Recents اکنون یک پانل ساده برای اجرای برنامه ها از یک نمایه کاری قفل شده را نشان می دهد. پانل ساده با کلید رنگی حاوی نماد و نام برنامه است. قبلاً، فعالیتها یا وظایف یک نمایه کاری قفل شده، پیشنمایش را در صفحه اخیر نشان میداد.
یکپارچگی دستگاه
- پرچم
ENSURE_VERIFY_APPS
اکنون یک محدودیت کاربر جهانی است. اگر هر کاربری در دستگاه دارای این محدودیت باشد، تأیید برنامه در همه کاربران دستگاه اعمال می شود. به عنوان مثال، اگر مالک نمایه محدودیتی را برای نمایه کاری تعیین کند، تأیید برنامه در نمایه شخصی کاربر اعمال می شود. - متد
onSystemUpdatePending()
اکنون برای صاحبان پروفایل علاوه بر دارندگان دستگاه نیز فراخوانی می شود. - هنگام استفاده از کلاس
SystemUpdatePolicy
، سیاست تعویق دیگر برای وصلههای امنیتی اعمال نمیشود، بنابراین وصلههای امنیتی دیگر نمیتوانند به تعویق بیفتند. با این حال، رفتار انواع سیاستهای دیگر، مانند خودکار و پنجرهدار، تحت تأثیر قرار نمیگیرد. - حتی اگر
DISALLOW_FACTORY_RESET
فعال باشد، صاحبان دستگاه میتوانند بازنشانی کارخانهای را با استفاده ازwipeData()
راهاندازی کنند.
VPN همیشه روشن
Android 8.0 شامل تغییرات رابط کاربری برای کمک به کاربران برای درک وضعیت اتصالات VPN همیشه روشن است:
- وقتی اتصالات VPN همیشه روشن قطع میشوند یا نمیتوانند وصل شوند، کاربران یک اعلان غیرقابل رد کردن را مشاهده میکنند. ضربه زدن روی اعلان تنظیمات پیکربندی VPN را نشان می دهد. هنگامی که VPN دوباره وصل می شود یا کاربر گزینه VPN همیشه روشن را خاموش می کند، اعلان ناپدید می شود.
- VPN همیشه روشن به شخصی که از دستگاهی استفاده میکند اجازه میدهد اتصالات شبکهای را که از VPN استفاده نمیکنند مسدود کند. هنگام روشن کردن این گزینه، برنامه تنظیمات به کاربر هشدار می دهد که تا زمانی که VPN وصل نشود، اتصال اینترنتی نخواهد داشت. تنظیمات از کاربر میخواهد ادامه دهد یا لغو کند.
VpnService
برنامه های VPN اکنون پس از راه اندازی باید متد startForeground()
خود را فراخوانی کند. از آنجایی که سیستم اندروید سرویس یک برنامه VPN را مستقیماً راه اندازی می کند، انتقال به پیش زمینه مسئولیت برنامه است. Android 8.0 برنامههای VPN را که سرویس VPN را به پیشزمینه منتقل نمیکنند، خاموش میکند.
تماس های رمز عبور
تماس های تغییر رمز عبور DeviceAdminReceiver
اکنون شامل یک پارامتر user
برای شناسایی کاربر یا نمایه ای است که رمز عبور به آن تعلق دارد. امضاهای روش جدید عبارتند از:
-
onPasswordChanged(Context, Intent, UserHandle)
-
onPasswordExpiring(Context, Intent, UserHandle)
-
onPasswordFailed(Context, Intent, UserHandle)
-
onPasswordSucceeded(Context, Intent, UserHandle)
اجرای پیشفرض هر روش جدید، نسخه قبلی را فراخوانی میکند — حذف آرگومان کاربر. اندروید 8.0 روش های قبلی را منسوخ می کند.
تفویض API مدیریت برنامه
متدهای زیر در کلاس DevicePolicyManager
اکنون منسوخ شده اند:
-
setCertInstallerPackage()
-
getCertInstallerPackage()
-
setApplicationRestrictionsManagingPackage()
-
getApplicationRestrictionsManagingPackage()
همچنین، اکنون امکان تفویض یک محدوده واحد به چندین بسته وجود دارد. به عبارت دیگر، صاحبان دستگاه و دارندگان نمایه می توانند به طور همزمان به دو بسته مختلف دسترسی به یک مجموعه از API ها را اعطا کنند.