برنامه های فوری یکی از ویژگی های کلیدی 10 هستند، بنابراین ضروری است که آنها به درستی کار کنند. برنامه‌های فوری به طور ضمنی نصب می‌شوند، بنابراین مجموعه‌ای از قابلیت‌های محدود دارند و در یک جعبه ایمنی محدودتر اجرا می‌شوند. با توجه به ماهیت فراگیر این محدودیت‌ها، هر بخشی از سیستم در معرض خطر کار نکردن صحیح با برنامه‌های فوری است. یک زیر مجموعه آزمایشی CTS ایجاد شده است تا اطمینان حاصل شود که رفتارهای مجاز توسط Instant Apps کار می کنند. ایده کلیدی این است که رشد اندازه CTS را با جداسازی حداقل مجموعه تست ها به پورت به حداقل برسانیم. اجرای CTS در حالت برنامه‌های فوری به معنای نصب APK آزمایشی به عنوان یک برنامه فوری و اجرای آزمایش‌ها است.
محدودیت های برنامه فوری
برنامه‌های فوری توسط کاربر نصب نمی‌شوند، بنابراین در یک جعبه ایمنی محدود با محدودیت‌های زیر اجرا می‌شوند:
- فقط می تواند مجوزهای خاصی را داشته باشد.
- نمی‌توان برنامه‌های دیگر را دید مگر اینکه آن برنامه‌ها برای برنامه‌های فوری قابل مشاهده باشند.
- فقط می تواند به تنظیمات خاص سیستم دسترسی داشته باشد.
- فقط می تواند به ویژگی های خاص سیستم دسترسی داشته باشد.
- نمی توان خدمات/ارائه دهندگان را در معرض دید قرار داد.
- می تواند با قوانین خاصی در اطراف پخش ها دریافت و ارسال کند.
علاوه بر این، برنامه‌های فوری باید اجازه دهند جعبه ایمنی جدید محدودیت‌های بیشتری اضافه کند. این طیف گسترده از رفتارهای ویژه در اطراف برنامه‌های فوری، کل پلتفرم را قطع می‌کند، بنابراین باید راهی وجود داشته باشد که تأیید کند که برنامه‌های فوری همانطور که برای همه دستگاه‌های موجود در اکوسیستم انتظار می‌رود کار می‌کنند.
آزمایش‌هایی که در حالت برنامه‌های فوری اجرا می‌شوند
همه ماژول‌های CTS دارای تست‌های قابل اجرا برای برنامه‌های فوری نیستند. اگر عملکرد تست شده توسط ماژول با سرور سیستم تعامل داشته باشد، این آزمایش ها باید در حالت برنامه های فوری اجرا شوند. به عنوان مثال، تست‌های OpenGL با سرور سیستم تعامل ندارند و بنابراین نیازی به اجرای آنها در حالت برنامه‌های فوری نیست، در حالی که تست‌های دسترسی با سرور سیستم تعامل دارند، اما نیاز به اجرای آنها در حالت برنامه‌های فوری وجود دارد.
علاوه بر شناسایی ماژول‌ها، کاربران باید تعیین کنند که کدام تست‌ها در این ماژول‌ها مرتبط هستند. به عنوان مثال، آزمایش رفتارهای خاص سرویس برای یک معماری قابل اتصال (به عنوان مثال، AccessibilityService) برای حالت برنامه فوری قابل اجرا نیست زیرا برنامه‌های فوری نمی‌توانند سرویس‌ها را در معرض سایر برنامه‌ها (از جمله پلتفرم) قرار دهند در حالی که آزمایش‌هایی که رفتارهای سمت برنامه را تأیید می‌کنند قابل اجرا برای حالت برنامه های فوری مثال دیگر آزمایشی است که رفتارهای پشت مجوزی را که برنامه فوری نمی تواند نگه دارد، در حالت برنامه فوری مرتبط نیستند، تأیید می کند. مجموعه‌ای از آزمایش‌ها وجود دارد که فقط برای برنامه‌های فوری اعمال می‌شود که قوانین مربوط به نحوه رفتار آنها را تأیید می‌کند، به عنوان مثال، سرویس‌ها را در معرض دید قرار نمی‌دهند یا برنامه‌های دیگر را نمی‌بینند. به طور معمول، این موارد قبلاً نوشته شده‌اند و نیازی به انتقال ندارند.
تست شکست در حالت برنامه‌های فوری
اگر آزمایش ناموفق باشد زیرا عملکردی را تأیید می کند که برنامه های فوری نمی توانند به آن دسترسی داشته باشند، در حالت برنامه های فوری قابل اجرا نیست. با حاشیه نویسی با @AppModeFull ، آزمایش را برای اجرا فقط در حالت برنامه کامل علامت گذاری کنید. می توانید این حاشیه نویسی را در سطح کلاس اعمال کنید تا تمام تست های موجود در آن حذف شوند.
اگر به دلیل خرابی برخی از عملکردهای قابل دسترسی Instant Apps، آزمایش ناموفق بود، یک اشکال را ثبت کنید .
عیب یابی
اگر تست شما با Failed to install MyCtsModule.apk در DEVICE ناموفق بود. دلیل: '-116' ، به دنبال پیام های PackageManager در logcat بگردید. برای مثال، اگر می‌گوید نمی‌توان برنامه کامل را با برنامه فوری جایگزین کرد: your_app ، ابتدا adb برنامه خود را حذف نصب کنید.