CTS برای برنامه های فوری

برنامه‌های فوری یکی از ویژگی‌های کلیدی نسخه ۱۰ هستند، بنابراین ضروری است که به درستی کار کنند. برنامه‌های فوری به طور ضمنی نصب می‌شوند، بنابراین مجموعه‌ای محدود از قابلیت‌ها را دارند و در یک محیط امنیتی محدودتر اجرا می‌شوند. با توجه به ماهیت فراگیر این محدودیت‌ها، هر بخشی از سیستم در معرض خطر عدم کارکرد صحیح با برنامه‌های فوری قرار دارد. یک زیرمجموعه تست CTS ایجاد می‌شود تا اطمینان حاصل شود که رفتارهای مجاز توسط برنامه‌های فوری کار می‌کنند. ایده اصلی، به حداقل رساندن رشد اندازه CTS با جداسازی حداقل مجموعه تست‌ها برای انتقال است. اجرای CTS در حالت برنامه‌های فوری به معنای نصب APK تست به عنوان یک برنامه فوری و اجرای تست‌ها است.

محدودیت‌های برنامه فوری

برنامه‌های فوری توسط کاربر نصب نمی‌شوند، بنابراین در یک محیط محدود با محدودیت‌های زیر اجرا می‌شوند:

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

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

تست‌های اجرا شده در حالت Instant Apps

همه ماژول‌های CTS تست‌هایی برای Instant Apps ندارند. اگر عملکرد تست شده توسط ماژول با سرور سیستم تعامل داشته باشد، این تست‌ها باید در حالت Instant Apps اجرا شوند. به عنوان مثال، تست‌های OpenGL با سرور سیستم تعامل ندارند و بنابراین نیازی به اجرای آنها در حالت Instant Apps نیست، در حالی که تست‌های دسترسی با سرور سیستم تعامل دارند اما نیاز به اجرای آنها در حالت Instant Apps وجود دارد.

علاوه بر شناسایی ماژول‌های قابل اجرا، کاربران باید مشخص کنند که کدام تست‌ها در این ماژول‌ها مرتبط هستند. به عنوان مثال، تست رفتارهای خاص سرویس برای یک معماری قابل اتصال (به عنوان مثال، AccessibilityService) برای حالت Instant App قابل اجرا نیست زیرا Instant Apps نمی‌تواند سرویس‌ها را در معرض برنامه‌های دیگر (از جمله پلتفرم) قرار دهد، در حالی که تست‌هایی که رفتارهای سمت برنامه را اعتبارسنجی می‌کنند برای حالت Instant App قابل اجرا هستند. مثال دیگر، تستی است که رفتارهای پشت مجوزی را که Instant App نمی‌تواند نگه دارد، اعتبارسنجی می‌کند و در حالت Instant App مرتبط نیستند. مجموعه‌ای از تست‌ها وجود دارد که فقط برای Instant Apps اعمال می‌شوند و قوانین مربوط به نحوه رفتار آنها را اعتبارسنجی می‌کنند، به عنوان مثال، عدم نمایش سرویس‌ها یا عدم مشاهده سایر برنامه‌ها. معمولاً این تست‌ها از قبل نوشته شده‌اند و نیازی به انتقال ندارند.

شکست‌های آزمایشی در حالت Instant Apps

اگر تست به دلیل اعتبارسنجی قابلیت‌هایی که Instant Apps نمی‌تواند به آنها دسترسی داشته باشد، با شکست مواجه می‌شود، در این صورت در حالت Instant Apps قابل اجرا نیست. با حاشیه‌نویسی آن با @AppModeFull ، تست را طوری علامت‌گذاری کنید که فقط در حالت Full App اجرا شود. می‌توانید این حاشیه‌نویسی را در سطح کلاس اعمال کنید تا همه تست‌های موجود در آن حذف شوند.

اگر آزمایش به دلیل خرابی برخی از قابلیت‌های قابل دسترسی برای Instant Apps با شکست مواجه شد، یک اشکال (bug) ثبت کنید .

عیب‌یابی

اگر تست شما با خطای Failed to install MyCtsModule.apk on DEVICE. Reason: '-116' با شکست مواجه شد، به دنبال پیام‌های PackageManager در logcat باشید. برای مثال، اگر می‌گوید Can't replace Full App with Instant App: your_app نیست ، ابتدا برنامه خود را با adb uninstall کنید.