نمای کلی سرپرستی دستگاه

منسوخ شدن سرپرست دستگاه. از Android 9 (سطح API‏ ۲۸)، برخی‌از خط‌مشی‌های سرپرست هنگام فراخوانی توسط سرپرست دستگاه به‌عنوان منسوخ علامت‌گذاری می‌شوند. توصیه می‌کنیم از همین‌حالا برای این تغییر آماده شوید. برای کسب اطلاعات بیشتر و دیدن گزینه‌های انتقال، منسوخ شدن سرپرست دستگاه را بخوانید.

Android با ارائه میانای برنامه‌سازی کاربردی مدیریت دستگاه Android، از برنامه‌های سازمانی پشتیبانی می‌کند. Device Administration API ویژگی‌های مدیریت دستگاه را در سطح سیستم ارائه می‌دهد. این میاناهای برنامه‌سازی کاربردی به شما امکان می‌دهند برنامه‌هایی با آگاهی امنیتی ایجاد کنید که در تنظیمات سازمانی مفید هستند، جایی که متخصصان فناوری اطلاعات به کنترل غنی بر دستگاه‌های کارکنان نیاز دارند. برای مثال، برنامه داخلی Android Email از این میاناهای برنامه‌سازی کاربردی برای بهبود پشتیبانی Exchange استفاده کرده است. ازطریق برنامه «ایمیل»، سرپرستان Exchange می‌توانند خط‌مشی‌های گذرواژه را — ازجمله گذرواژه‌های حرفی‌عددی یا پین‌های عددی — در دستگاه‌ها اعمال کنند. سرپرستان همچنین می‌توانند از راه دور داده‌های گوشی‌های گم‌شده یا دزدیده‌شده را محو کنند (یعنی پیش‌فرض‌های کارخانه را بازیابی کنند). کاربران Exchange می‌توانند داده‌های ایمیل و تقویمشان را همگام‌سازی کنند.

این سند برای توسعه‌دهندگانی است که می‌خواهند راهکارهای سازمانی برای دستگاه‌های مجهز به Android توسعه دهند. این مقاله درباره ویژگی‌های مختلفی بحث می‌کند که میانای برنامه‌سازی کاربردی «مدیریت دستگاه» برای ارائه امنیت قوی‌تر برای دستگاه‌های کارمندان که با Android کار می‌کنند ارائه می‌دهد.

توجه برای اطلاعات درباره ساختن «کنترل‌کننده خط‌مشی کاری» برای پیاده‌سازی‌های Android for Work، به ساختن کنترل‌کننده خط‌مشی دستگاه مراجعه کنید.

حالت مالک دستگاه بی‌سر

‫Android 14 (سطح API‏ ۳۴) حالت «کاربر سیستم بی‌سر» را معرفی می‌کند (دستگاه‌هایی که در آن‌ها UserManager.isHeadlessSystemUserMode true را برمی‌گرداند). در حالت «کاربر سیستم بی‌سر»، کاربر سیستم یک کاربر پس‌زمینه است و برای تعامل کاربر نهایی به کاربران پیش‌زمینه اضافی متکی است. ‫Android 14 همچنین حالت وابسته مالک دستگاه بی‌سر را معرفی می‌کند، که «مالک نمایه» را به همه کاربران وابسته به‌غیراز کاربر سیستم که «مالک دستگاه» روی آن تنظیم شده است اضافه می‌کند.

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

سازندگان دستگاه Android می‌توانند به راهنمایی منتشرشده در source.android.com مراجعه کنند.

نمای کلی میانای برنامه‌سازی کاربردی مدیریت دستگاه

در اینجا نمونه‌هایی از انواع برنامه‌هایی که ممکن است از Device Administration API استفاده کنند آورده شده است:

  • کارخواه‌های ایمیل.
  • برنامه‌های امنیتی که محو کردن داده از راه دور را انجام می‌دهند.
  • سرویس‌ها و برنامه‌های مدیریت دستگاه.

روش کار؟

از Device Administration API برای نوشتن برنامه‌های سرپرست دستگاه استفاده می‌کنید که کاربران در دستگاه‌هایشان نصب می‌کنند. برنامه سرپرست دستگاه خط‌مشی‌های موردنظر را اعمال می‌کند. روش کار این‌طور است:

  • سرپرست سیستم برنامه سرپرست دستگاهی می‌نویسد که خط‌مشی‌های امنیتی دستگاه محلی/ازراه‌دور را اجرا می‌کند. این خط‌مشی‌ها ممکن است در برنامه کدگذاری شده باشند، یا برنامه ممکن است به‌طور پویا خط‌مشی‌ها را از سرور شخص ثالث واکشی کند.
  • برنامه در دستگاه‌های کاربران نصب شده است. Android درحال‌حاضر راهکار آماده‌سازی خودکار ندارد. برخی‌از روش‌هایی که سرپرست سیستم ممکن است برنامه را بین کاربران توزیع کند به شرح زیر است:
    • Google Play.
    • درحال فعال کردن نصب از فروشگاه دیگر.
    • توزیع برنامه ازطریق روش‌های دیگر، مثل ایمیل یا وب‌سایت.
  • سیستم از کاربر می‌خواهد برنامه سرپرست دستگاه را فعال کند. نحوه و زمان وقوع این اتفاق به نحوه پیاده‌سازی برنامه بستگی دارد.
  • وقتی کاربران برنامه سرپرست دستگاه را فعال می‌کنند، مشمول خط‌مشی‌های آن می‌شوند. رعایت این خط‌مشی‌ها معمولاً مزایایی به‌همراه دارد، مثل دسترسی به سیستم‌ها و داده‌های حساس.

اگر کاربران برنامه سرپرست دستگاه را فعال نکنند، این برنامه در دستگاه باقی می‌ماند اما در وضعیت غیرفعال خواهد بود. کاربران مشمول خط‌مشی‌های آن نخواهند بود و برعکس، هیچ‌کدام از مزایای برنامه را دریافت نخواهند کرد—برای مثال، ممکن است نتوانند داده‌ها را همگام‌سازی کنند.

اگر کاربری از خط‌مشی‌ها پیروی نکند (برای مثال، اگر کاربر گذرواژه‌ای تنظیم کند که رهنمودها را نقض کند)، تصمیم‌گیری درباره نحوه رسیدگی به این موضوع برعهده برنامه است. بااین‌حال، معمولاً این کار باعث می‌شود کاربر نتواند داده‌ها را همگام‌سازی کند.

اگر دستگاهی تلاش کند به سروری متصل شود که به خط‌مشی‌هایی نیاز دارد که در Device Administration API پشتیبانی نمی‌شوند، اتصال مجاز نخواهد بود. درحال‌حاضر Device Administration API امکان آماده‌سازی جزئی را نمی‌دهد. به‌عبارت دیگر، اگر دستگاهی (برای مثال، دستگاهی قدیمی) از همه خط‌مشی‌های ذکرشده پشتیبانی نکند، هیچ راهی برای اجازه دادن به دستگاه برای اتصال وجود ندارد.

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

برای حذف نصب برنامه سرپرست دستگاه موجود، کاربران باید ابتدا برنامه را به‌عنوان سرپرست لغو ثبت‌نام کنند.

خط‌مشی‌ها

در محیط سازمانی، اغلب لازم است دستگاه‌های کارمندان از مجموعه سخت‌گیرانه‌ای از خط‌مشی‌ها که بر استفاده از دستگاه حاکم است پیروی کنند. ‫Device Administration API از خط‌مشی‌های فهرست‌شده در جدول ۱ پشتیبانی می‌کند. توجه داشته باشید که Device Administration API درحال‌حاضر فقط از گذرواژه برای قفل صفحه پشتیبانی می‌کند:

جدول ۱. خط‌مشی‌های پشتیبانی‌شده توسط Device Administration API.

خط‌مشی شرح
گذرواژه فعال شد الزام می‌کند که دستگاه‌ها پین یا گذرواژه درخواست کنند.
حداقل طول گذرواژه تعداد نویسه‌های الزامی برای گذرواژه را تنظیم کنید. برای مثال، می‌توانید الزام کنید که پین یا گذرواژه حداقل شش نویسه داشته باشد.
گذرواژه الفباعددی لازم است الزام می‌کند که گذرواژه‌ها ترکیبی از حروف و اعداد باشند. ممکن است شامل نویسه‌های نمادین باشند.
گذرواژه پیچیده لازم است الزام می‌کند که گذرواژه‌ها باید حداقل یک حرف، یک عدد، و یک نماد ویژه داشته باشند. در Android 3.0 معرفی شد.
حداقل تعداد حروف لازم در گذرواژه حداقل تعداد حروف لازم در گذرواژه برای همه سرپرستان یا یک سرپرست خاص. در Android 3.0 معرفی شد.
حداقل تعداد حروف کوچک لازم در گذرواژه حداقل تعداد حروف کوچک لازم در گذرواژه برای همه سرپرستان یا سرپرستی خاص. در Android 3.0 معرفی شد.
حداقل نویسه‌های غیرحرفی لازم در گذرواژه حداقل تعداد نویسه‌های غیرحرفی لازم در گذرواژه برای همه سرپرستان یا سرپرستی خاص. در Android 3.0 معرفی شد.
حداقل تعداد رقم‌های عددی لازم در گذرواژه حداقل تعداد ارقام عددی لازم در گذرواژه برای همه سرپرستان یا یک سرپرست خاص. در Android 3.0 معرفی شد.
حداقل نمادهای لازم در گذرواژه حداقل تعداد نمادهای لازم در گذرواژه برای همه سرپرستان یا سرپرستی خاص. در Android 3.0 معرفی شد.
حداقل تعداد حروف بزرگ لازم در گذرواژه حداقل تعداد حروف بزرگ لازم در گذرواژه برای همه سرپرستان یا سرپرستی خاص. در Android 3.0 معرفی شد.
زمان انقضای گذرواژه زمان انقضای گذرواژه، که به‌صورت دلتا برحسب میلی‌ثانیه از زمانی که سرپرست دستگاه زمان اتمام انقضا را تنظیم می‌کند بیان می‌شود. در Android 3.0 معرفی شد.
محدودیت سابقه گذرواژه این خط‌مشی مانع از استفاده مجدد کاربران از n گذرواژه منحصربه‌فرد آخر می‌شود. این خط‌مشی معمولاً در ارتباط با setPasswordExpirationTimeout() استفاده می‌شود که کاربران را مجبور می‌کند گذرواژه‌هایشان را پس‌از گذشت مدت زمان مشخصی به‌روز کنند. در Android 3.0 معرفی شد.
حداکثر تلاش‌های ناموفق برای وارد کردن گذرواژه مشخص می‌کند کاربر چند بار می‌تواند گذرواژه اشتباه وارد کند تا دستگاه داده‌هایش را پاک کند. Device Administration API به سرپرستان اجازه می‌دهد دستگاه را از راه دور به پیش‌فرض‌های کارخانه بازنشانی کنند. این کار باعث می‌شود درصورت گم شدن یا دزدیده شدن دستگاه، داده‌ها ایمن بماند.
قفل حداکثر زمان عدم فعالیت مدت زمانی را که از آخرین باری که کاربر صفحه را لمس کرده یا دکمه‌ای را فشار داده است تا زمانی که دستگاه صفحه را قفل می‌کند تنظیم می‌کند. وقتی این اتفاق می‌افتد، کاربران باید پین یا گذرواژه‌شان را دوباره وارد کنند تا بتوانند از دستگاهشان استفاده کنند و به داده‌ها دسترسی داشته باشند. این مقدار می‌تواند بین ۱ تا ۶۰ دقیقه باشد.
فضای ذخیره‌سازی باید رمزگذاری شود مشخص می‌کند که فضای ذخیره‌سازی باید رمزگذاری شود، اگر دستگاه از آن پشتیبانی کند. در Android 3.0 معرفی شد.
غیرفعال کردن دوربین مشخص می‌کند که دوربین باید غیرفعال شود. توجه داشته باشید که این غیرفعال‌سازی لازم نیست دائمی باشد. دوربین را می‌توان به‌طور پویا براساس بافت، زمان، و غیره فعال/غیرفعال کرد. در Android 4.0 معرفی شد.

ویژگی‌های دیگر

علاوه‌بر پشتیبانی از خط‌مشی‌های فهرست‌شده در جدول بالا، Device Administration API به شما امکان می‌دهد کارهای زیر را انجام دهید:

  • از کاربر خواسته می‌شود گذرواژه جدیدی تنظیم کند.
  • دستگاه فوراً قفل می‌شود.
  • داده‌های دستگاه را پاک کنید (یعنی دستگاه را به پیش‌فرض‌های کارخانه بازگردانید).

برنامه نمونه

نمونه‌های استفاده‌شده در این صفحه براساس نمونه Device Administration API است که در نمونه‌های SDK گنجانده شده است (ازطریق Android SDK Manager دردسترس است) و در سیستم شما به‌عنوان <sdk_root>/ApiDemos/app/src/main/java/com/example/android/apis/app/DeviceAdminSample.java قرار دارد.

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

  • کیفیت گذرواژه را تنظیم کنید.
  • الزامات گذرواژه کاربر را مشخص کنید، مثلاً حداقل طول، حداقل تعداد نویسه‌های عددی که باید داشته باشد، و غیره.
  • گذرواژه را تنظیم کنید. اگر گذرواژه با خط‌مشی‌های مشخص‌شده مطابقت نداشته باشد، سیستم خطایی برمی‌گرداند.
  • تنظیم کنید چندبار تلاش ناموفق برای وارد کردن گذرواژه می‌تواند انجام شود تا دستگاه پاک شود (یعنی به تنظیمات کارخانه بازیابی شود).
  • تنظیم کنید که گذرواژه از حالا تا چه زمانی منقضی شود.
  • طول سابقه گذرواژه را تنظیم کنید (طول به تعداد گذرواژه‌های قدیمی ذخیره‌شده در سابقه اشاره دارد). این کار مانع از آن می‌شود که کاربران از یکی از n گذرواژه آخری که قبلاً استفاده کرده‌اند دوباره استفاده کنند.
  • مشخص کنید که فضای ذخیره‌سازی باید رمزگذاری شود، اگر دستگاه از آن پشتیبانی می‌کند.
  • حداکثر مدت زمان غیرفعال بودن را که می‌تواند قبل‌از قفل شدن دستگاه سپری شود تنظیم کنید.
  • دستگاه را فوراً قفل کنید.
  • داده‌های دستگاه را پاک‌سازی کند (یعنی تنظیمات کارخانه را بازیابی کند).
  • دوربین را غیرفعال می‌کند.

شکل ۱. نماگرفت برنامه نمونه

توسعه برنامه سرپرستی دستگاه

سرپرستان سیستم می‌توانند از Device Administration API برای نوشتن برنامه‌ای استفاده کنند که اجرای خط‌مشی امنیتی دستگاه محلی/ازراه‌دور را اجباری می‌کند. این بخش مراحل مربوط به ایجاد برنامه مدیریت دستگاه را خلاصه می‌کند.

درحال ایجاد مانیفست

برای استفاده از Device Administration API، مانیفست برنامه باید شامل موارد زیر باشد:

  • زیرکلاسی از DeviceAdminReceiver که شامل موارد زیر است:
  • اظهارنامه خط‌مشی‌های امنیتی مورداستفاده در فراداده.

در اینجا گزیده‌ای از مانیفست نمونه «مدیریت دستگاه» آورده شده است:

<activity android:name=".app.DeviceAdminSample"
            android:label="@string/activity_sample_device_admin">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.SAMPLE_CODE" />
    </intent-filter>
</activity>
<receiver android:name=".app.DeviceAdminSample$DeviceAdminSampleReceiver"
        android:label="@string/sample_device_admin"
        android:description="@string/sample_device_admin_description"
        android:permission="android.permission.BIND_DEVICE_ADMIN">
    <meta-data android:name="android.app.device_admin"
            android:resource="@xml/device_admin_sample" />
    <intent-filter>
        <action android:name="android.app.action.DEVICE_ADMIN_ENABLED" />
    </intent-filter>
</receiver>

توجه داشته باشید:

  • مشخصه‌های زیر به منابع رشته‌ای اشاره دارند که برای برنامه نمونه در ApiDemos/res/values/strings.xml قرار دارند. برای اطلاعات بیشتر درباره منابع، به منابع برنامه مراجعه کنید.
    • android:label="@string/activity_sample_device_admin" به برچسب قابل‌خواندن برای کاربر برای فعالیت اشاره دارد.
    • ‫android:label="@string/sample_device_admin" به برچسب قابل‌خواندن برای کاربر برای اجازه اشاره دارد.
    • android:description="@string/sample_device_admin_description" به توضیح قابل‌خواندن برای کاربر درباره اجازه اشاره دارد. شرح معمولاً طولانی‌تر و آموزنده‌تر از برچسب است.
  • android:permission="android.permission.BIND_DEVICE_ADMIN" اجازه‌ای است که زیرکلاس DeviceAdminReceiver باید داشته باشد تا مطمئن شود که فقط سیستم می‌تواند با گیرنده تعامل داشته باشد (هیچ برنامه‌ای نمی‌تواند این اجازه را دریافت کند). این کار از سوءاستفاده برنامه‌های دیگر از برنامه سرپرست دستگاهتان جلوگیری می‌کند.
  • android.app.action.DEVICE_ADMIN_ENABLED کنش اصلی است که زیرکلاس DeviceAdminReceiver باید آن را مدیریت کند تا اجازه مدیریت دستگاه را داشته باشد. وقتی کاربر برنامه سرپرست دستگاه را فعال می‌کند، این مورد برای گیرنده تنظیم می‌شود. کد شما معمولاً این مورد را در onEnabled() مدیریت می‌کند. برای پشتیبانی شدن، گیرنده باید به اجازه BIND_DEVICE_ADMIN نیز نیاز داشته باشد تا برنامه‌های دیگر نتوانند از آن سوءاستفاده کنند.
  • وقتی کاربر برنامه سرپرست دستگاه را فعال می‌کند، این کار به گیرنده اجازه می‌دهد کنش‌هایی را در پاسخ به پخش رویدادهای خاص سیستم انجام دهد. وقتی رویداد مناسبی رخ می‌دهد، برنامه می‌تواند خط‌مشی‌ای را اعمال کند. برای مثال، اگر کاربر تلاش کند گذرواژه جدیدی تنظیم کند که الزامات خط‌مشی را برآورده نمی‌کند، برنامه می‌تواند از کاربر بخواهد گذرواژه دیگری انتخاب کند که الزامات را برآورده کند.
  • پس‌از انتشار برنامه، نام گیرنده را تغییر ندهید. اگر نام در مانیفست تغییر کند، وقتی کاربران برنامه را به‌روزرسانی می‌کنند، سرپرست دستگاه غیرفعال می‌شود. برای کسب اطلاعات بیشتر، به <receiver> مراجعه کنید.
  • android:resource="@xml/device_admin_sample" خط‌مشی‌های امنیتی مورداستفاده در فراداده را اعلام می‌کند. فراداده اطلاعات بیشتری را که مختص سرپرست دستگاه است ارائه می‌دهد، همان‌طور که توسط کلاس DeviceAdminInfo تجزیه شده است. محتوای device_admin_sample.xml در اینجا آمده است:
<device-admin xmlns:android="http://schemas.android.com/apk/res/android">
  <uses-policies>
    <limit-password />
    <watch-login />
    <reset-password />
    <force-lock />
    <wipe-data />
    <expire-password />
    <encrypted-storage />
    <disable-camera />
  </uses-policies>
</device-admin>

هنگام طراحی برنامه مدیریت دستگاه، لازم نیست همه خط‌مشی‌ها را لحاظ کنید، فقط خط‌مشی‌های مرتبط با برنامه‌تان را لحاظ کنید.

برای بحث بیشتر درباره فایل مانیفست، به راهنمای توسعه‌دهندگان Android مراجعه کنید.

درحال پیاده‌سازی کد

Device Administration API شامل کلاس‌های زیر است:

DeviceAdminReceiver
کلاس پایه برای پیاده‌سازی مؤلفه مدیریت دستگاه. این کلاس راحتی را برای تفسیر کنش‌های هدف خام که توسط سیستم ارسال می‌شود فراهم می‌کند. برنامه «مدیریت دستگاه» شما باید شامل یک زیرکلاس DeviceAdminReceiver باشد.
DevicePolicyManager
کلاسی برای مدیریت خط‌مشی‌های اعمال‌شده در دستگاه. اکثر مشتریان این کلاس باید DeviceAdminReceiver را منتشر کرده باشند که کاربر درحال‌حاضر فعال کرده است. DevicePolicyManager خط‌مشی‌های یک یا چند نمونه DeviceAdminReceiver را مدیریت می‌کند
DeviceAdminInfo
از این کلاس برای مشخص کردن فراداده برای مؤلفه سرپرست دستگاه استفاده می‌شود.

این کلاس‌ها پایه و اساس یک برنامه مدیریت دستگاه کاملاً کاربردی را فراهم می‌کنند. بقیه این بخش توضیح می‌دهد که چگونه از میاناهای برنامه‌سازی کاربردی DeviceAdminReceiver و DevicePolicyManager برای نوشتن یک برنامه مدیریت دستگاه استفاده کنید.

زیرکلاس‌سازی DeviceAdminReceiver

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

در زیرکلاس DeviceAdminReceiver، برنامه نمونه به‌سادگی یک اعلان Toast را در پاسخ به رویدادهای خاص نمایش می‌دهد. برای مثال:

کاتلین

class DeviceAdminSample : DeviceAdminReceiver() {

    private fun showToast(context: Context, msg: String) {
        context.getString(R.string.admin_receiver_status, msg).let { status ->
            Toast.makeText(context, status, Toast.LENGTH_SHORT).show()
        }
    }

    override fun onEnabled(context: Context, intent: Intent) =
            showToast(context, context.getString(R.string.admin_receiver_status_enabled))

    override fun onDisableRequested(context: Context, intent: Intent): CharSequence =
            context.getString(R.string.admin_receiver_status_disable_warning)

    override fun onDisabled(context: Context, intent: Intent) =
            showToast(context, context.getString(R.string.admin_receiver_status_disabled))

    override fun onPasswordChanged(context: Context, intent: Intent, userHandle: UserHandle) =
            showToast(context, context.getString(R.string.admin_receiver_status_pw_changed))
...
}

جاوا

public class DeviceAdminSample extends DeviceAdminReceiver {

    void showToast(Context context, String msg) {
        String status = context.getString(R.string.admin_receiver_status, msg);
        Toast.makeText(context, status, Toast.LENGTH_SHORT).show();
    }

    @Override
    public void onEnabled(Context context, Intent intent) {
        showToast(context, context.getString(R.string.admin_receiver_status_enabled));
    }

    @Override
    public CharSequence onDisableRequested(Context context, Intent intent) {
        return context.getString(R.string.admin_receiver_status_disable_warning);
    }

    @Override
    public void onDisabled(Context context, Intent intent) {
        showToast(context, context.getString(R.string.admin_receiver_status_disabled));
    }

    @Override
    public void onPasswordChanged(Context context, Intent intent, UserHandle userHandle) {
        showToast(context, context.getString(R.string.admin_receiver_status_pw_changed));
    }
...
}

درحال فعال کردن برنامه

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

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

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

شکل ۲. برنامه نمونه: فعال کردن برنامه

در زیر کدی را می‌بینید که وقتی کاربر روی چارگوش انتخاب فعال کردن سرپرست کلیک می‌کند اجرا می‌شود. این کار باعث راه‌اندازی onPreferenceChange() فراخوانی برگشتی می‌شود. این فراخوانی برگشتی زمانی فراخوانده می‌شود که مقدار این Preference توسط کاربر تغییر کرده باشد و درحال تنظیم و/یا ماندگار شدن باشد. اگر کاربر درحال فعال کردن برنامه باشد، نمایشگر تغییر می‌کند تا از کاربر بخواهد برنامه سرپرست دستگاه را فعال کند، همان‌طور که در شکل ۲ نشان داده شده است. درغیراین‌صورت، برنامه سرپرست دستگاه غیرفعال می‌شود.

کاتلین

override fun onPreferenceChange(preference: Preference, newValue: Any): Boolean {
    if (super.onPreferenceChange(preference, newValue)) return true
    val value = newValue as Boolean
    if (preference == enableCheckbox) {
        if (value != adminActive) {
            if (value) {
                // Launch the activity to have the user enable our admin.
                val intent = Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN).apply {
                    putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, deviceAdminSample)
                    putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,
                            activity.getString(R.string.add_admin_extra_app_text))
                }
                startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN)
                // return false - don't update checkbox until we're really active
                return false
            } else {
                dpm.removeActiveAdmin(deviceAdminSample)
                enableDeviceCapabilitiesArea(false)
                adminActive = false
            }
        }
    } else if (preference == disableCameraCheckbox) {
        dpm.setCameraDisabled(deviceAdminSample, value)
    }
    return true
}

جاوا

@Override
public boolean onPreferenceChange(Preference preference, Object newValue) {
    if (super.onPreferenceChange(preference, newValue)) {
        return true;
    }
    boolean value = (Boolean) newValue;
    if (preference == enableCheckbox) {
        if (value != adminActive) {
            if (value) {
                // Launch the activity to have the user enable our admin.
                Intent intent = new Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN);
                intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, deviceAdminSample);
                intent.putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,
                        activity.getString(R.string.add_admin_extra_app_text));
                startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN);
                // return false - don't update checkbox until we're really active
                return false;
            } else {
                dpm.removeActiveAdmin(deviceAdminSample);
                enableDeviceCapabilitiesArea(false);
                adminActive = false;
            }
        }
    } else if (preference == disableCameraCheckbox) {
        dpm.setCameraDisabled(deviceAdminSample, value);
    }
    return true;
}

خط intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, mDeviceAdminSample) بیان می‌کند که mDeviceAdminSample (که یک مؤلفه DeviceAdminReceiver است) خط‌مشی هدف است. این خط میانای کاربر نشان‌داده‌شده در شکل ۲ را فراخوانی می‌کند که کاربران را درطول افزودن سرپرست دستگاه به سیستم راهنمایی می‌کند (یا به آن‌ها اجازه می‌دهد آن را رد کنند).

وقتی برنامه نیاز به انجام عملیاتی دارد که مشروط به فعال بودن برنامه سرپرست دستگاه است، تأیید می‌کند که برنامه فعال است. برای انجام این کار، از روش DevicePolicyManager isAdminActive() استفاده می‌کند. توجه داشته باشید که روش DevicePolicyManager isAdminActive() مؤلفه DeviceAdminReceiver را به‌عنوان آرگومان خود می‌گیرد:

کاتلین

private lateinit var dpm: DevicePolicyManager
...
private fun isActiveAdmin(): Boolean = dpm.isAdminActive(deviceAdminSample)

جاوا

DevicePolicyManager dpm;
...
private boolean isActiveAdmin() {
    return dpm.isAdminActive(deviceAdminSample);
}

مدیریت خط‌مشی‌ها

‫DevicePolicyManager یک کلاس عمومی برای مدیریت خط‌مشی‌های اجراشده در دستگاه است. DevicePolicyManager خط‌مشی‌های یک یا چند نمونه DeviceAdminReceiver را مدیریت می‌کند.

به‌صورت زیر دسته‌ای برای DevicePolicyManager دریافت می‌کنید:

کاتلین

dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager

جاوا

DevicePolicyManager dpm =
    (DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE);

این بخش نحوه استفاده از DevicePolicyManager را برای انجام کارهای مدیریتی شرح می‌دهد:

تنظیم خط‌مشی‌های گذرواژه

DevicePolicyManager شامل میاناهای برنامه‌سازی کاربردی برای تنظیم و اجرای خط‌مشی گذرواژه دستگاه است. در Device Administration API، گذرواژه فقط برای قفل صفحه اعمال می‌شود. این بخش کارهای رایج مربوط به گذرواژه را شرح می‌دهد.

تنظیم گذرواژه برای دستگاه

این کد میانای کاربری را نمایش می‌دهد که از کاربر می‌خواهد گذرواژه تنظیم کند:

کاتلین

Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD).also { intent ->
    startActivity(intent)
}

جاوا

Intent intent = new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD);
startActivity(intent);
تنظیم کیفیت گذرواژه

کیفیت گذرواژه می‌تواند یکی از ثابت‌های DevicePolicyManager زیر باشد:

PASSWORD_QUALITY_ALPHABETIC
کاربر باید گذرواژه‌ای وارد کند که حداقل حاوی نویسه‌های الفبایی (یا نمادهای دیگر) باشد.
PASSWORD_QUALITY_ALPHANUMERIC
کاربر باید گذرواژه‌ای وارد کند که حداقل حاوی هم نویسه‌های عددی و هم نویسه‌های الفبایی (یا نمادهای دیگر) باشد.
PASSWORD_QUALITY_NUMERIC
کاربر باید گذرواژه‌ای وارد کند که حداقل حاوی نویسه‌های عددی باشد.
PASSWORD_QUALITY_COMPLEX
کاربر باید گذرواژه‌ای وارد کرده باشد که حداقل شامل یک حرف، یک عدد، و یک نماد ویژه باشد.
PASSWORD_QUALITY_SOMETHING
خط‌مشی به نوعی گذرواژه نیاز دارد، اما نوع آن مهم نیست.
PASSWORD_QUALITY_UNSPECIFIED
این خط‌مشی هیچ الزامی برای گذرواژه ندارد.

برای مثال، این نحوه تنظیم خط‌مشی گذرواژه برای الزام گذرواژه الفباعددی است:

کاتلین

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
...
dpm.setPasswordQuality(deviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC)

جاوا

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
dpm.setPasswordQuality(deviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC);
تنظیم الزامات محتوای گذرواژه

از Android نسخه ۳.۰ به بعد، کلاس DevicePolicyManager شامل روش‌هایی است که به شما امکان می‌دهد محتوای گذرواژه را به‌طور دقیق تنظیم کنید. برای مثال، می‌توانید خط‌مشی‌ای تنظیم کنید که بیان می‌کند گذرواژه‌ها باید حداقل n حرف بزرگ داشته باشند. در اینجا روش‌هایی برای تنظیم دقیق محتوای گذرواژه ارائه شده است:

برای مثال، این قطعه کد بیان می‌کند که گذرواژه باید حداقل ۲ حرف بزرگ داشته باشد:

کاتلین

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwMinUppercase = 2
...
dpm.setPasswordMinimumUpperCase(deviceAdminSample, pwMinUppercase)

جاوا

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int pwMinUppercase = 2;
...
dpm.setPasswordMinimumUpperCase(deviceAdminSample, pwMinUppercase);
تنظیم حداقل طول گذرواژه

می‌توانید مشخص کنید که گذرواژه باید حداقل طول مشخص‌شده را داشته باشد. برای مثال:

کاتلین

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwLength: Int = ...
...
dpm.setPasswordMinimumLength(deviceAdminSample, pwLength)

جاوا

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int pwLength;
...
dpm.setPasswordMinimumLength(deviceAdminSample, pwLength);
تنظیم حداکثر تعداد تلاش‌های ناموفق برای وارد کردن گذرواژه

می‌توانید حداکثر تعداد مجاز تلاش‌های ناموفق برای وارد کردن گذرواژه را قبل‌از پاک شدن دستگاه (یعنی بازنشانی به تنظیمات کارخانه) تنظیم کنید. برای مثال:

کاتلین

val dPM:DevicePolicyManager
private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val maxFailedPw: Int = ...
...
dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw)

جاوا

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int maxFailedPw;
 ...
dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw);
تنظیم مهلت انقضای گذرواژه

از Android 3.0 به بعد، می‌توانید از روش setPasswordExpirationTimeout() برای تنظیم زمان انقضای گذرواژه استفاده کنید که به‌صورت دلتا برحسب میلی‌ثانیه از زمانی که سرپرست دستگاه زمان انقضا را تنظیم می‌کند بیان می‌شود. برای مثال:

کاتلین

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwExpiration: Long = ...
...
dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration)

جاوا

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
long pwExpiration;
...
dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration);
محدود کردن گذرواژه براساس سابقه

از Android 3.0 به بعد، می‌توانید از روش setPasswordHistoryLength() برای محدود کردن توانایی کاربران در استفاده مجدد از گذرواژه‌های قدیمی استفاده کنید. این روش پارامتر طول را می‌گیرد که مشخص می‌کند چه تعداد گذرواژه قدیمی ذخیره شود. وقتی این خط‌مشی فعال باشد، کاربران نمی‌توانند گذرواژه جدیدی وارد کنند که با n گذرواژه آخر مطابقت داشته باشد. این کار مانع از این می‌شود که کاربران بارها و بارها از یک گذرواژه استفاده کنند. این خط‌مشی معمولاً در ارتباط با setPasswordExpirationTimeout() استفاده می‌شود، که کاربران را مجبور می‌کند گذرواژه‌هایشان را پس‌از گذشت مدت زمان مشخصی به‌روز کنند.

برای مثال، این قطعه کد کاربران را از استفاده مجدد از هرکدام از ۵ گذرواژه آخرشان منع می‌کند:

کاتلین

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwHistoryLength = 5
...
dpm.setPasswordHistoryLength(deviceAdminSample, pwHistoryLength)

جاوا

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int pwHistoryLength = 5;
...
dpm.setPasswordHistoryLength(deviceAdminSample, pwHistoryLength);

تنظیم قفل دستگاه

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

کاتلین

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val timeMs: Long = 1000L * timeout.text.toString().toLong()
...
dpm.setMaximumTimeToLock(deviceAdminSample, timeMs)

جاوا

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
long timeMs = 1000L*Long.parseLong(timeout.getText().toString());
dpm.setMaximumTimeToLock(deviceAdminSample, timeMs);

همچنین می‌توانید به‌صورت برنامه‌نویسی به دستگاه بگویید فوراً قفل شود:

کاتلین

private lateinit var dpm: DevicePolicyManager
dpm.lockNow()

جاوا

DevicePolicyManager dpm;
dpm.lockNow();

پاک کردن داده‌ها

می‌توانید از روش DevicePolicyManager wipeData() برای بازنشانی دستگاه به تنظیمات کارخانه استفاده کنید. این کار درصورت گم شدن یا دزدیده شدن دستگاه مفید است. اغلب تصمیم به پاک کردن دستگاه نتیجه برآورده شدن شرایط خاصی است. برای مثال، می‌توانید از setMaximumFailedPasswordsForWipe() استفاده کنید تا مشخص کنید که دستگاه باید پس‌از تعداد مشخصی تلاش ناموفق برای وارد کردن گذرواژه پاک شود.

داده‌ها را به‌صورت زیر پاک می‌کنید:

کاتلین

private lateinit var dpm: DevicePolicyManager
dpm.wipeData(0)

جاوا

DevicePolicyManager dpm;
dpm.wipeData(0);

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

غیرفعال کردن دوربین

از Android 4.0 به بعد، می‌توانید دوربین را غیرفعال کنید. توجه داشته باشید که این غیرفعال‌سازی نباید دائمی باشد. دوربین را می‌توان به‌طور پویا براساس بافت، زمان، و غیره فعال/غیرفعال کرد.

بااستفاده از روش setCameraDisabled() می‌توانید کنترل کنید که دوربین غیرفعال باشد یا نه. برای مثال، این قطعه کد دوربین را براساس تنظیم کادر انتخاب فعال یا غیرفعال می‌کند:

کاتلین

private lateinit var disableCameraCheckbox: CheckBoxPreference
private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
...
dpm.setCameraDisabled(deviceAdminSample, mDisableCameraCheckbox.isChecked)

جاوا

private CheckBoxPreference disableCameraCheckbox;
DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
dpm.setCameraDisabled(deviceAdminSample, mDisableCameraCheckbox.isChecked());

رمزگذاری فضای ذخیره‌سازی

از Android 3.0 به بعد، می‌توانید از روش setStorageEncryption() برای تنظیم خط‌مشی‌ای استفاده کنید که رمزگذاری فضای ذخیره‌سازی را درصورت پشتیبانی الزامی می‌کند.

برای مثال:

کاتلین

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
...
dpm.setStorageEncryption(deviceAdminSample, true)

جاوا

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
dpm.setStorageEncryption(deviceAdminSample, true);

برای مشاهده نمونه کاملی از نحوه فعال کردن رمزگذاری فضای ذخیره‌سازی، نمونه Device Administration API را ببینید.

نمونه‌های کد اضافی

نمونه‌های Android AppRestrictionEnforcer و DeviceOwner استفاده از میاناهای برنامه‌سازی کاربردی تحت پوشش این صفحه را بیشتر نشان می‌دهند.