از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
CTS برای برنامه های فوری
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
برنامه های فوری یکی از ویژگی های کلیدی 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 برنامه خود را حذف نصب کنید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# CTS for Instant Apps\n\nInstant Apps are a key feature of 10, so it's essential that they work\nproperly. Instant Apps are implicitly installed, so they have a restricted set of\ncapabilities and run in a more restrictive security sandbox. Due to the pervasive nature\nof these restrictions, any part of the system is at risk for not properly working with Instant\nApps. A CTS test subset is created to ensure that behaviors allowed by Instant Apps are\nworking. The key idea is to minimize the size growth of CTS by isolating the\nminimal set of tests to port. CTS running in Instant Apps mode means\ninstalling the test APK as an Instant App and running the tests.\n\nInstant App restrictions\n------------------------\n\n\nInstant Apps aren't installed by the user, so they run in a restricted sandbox with\nthe following restrictions:\n\n- Can hold only certain permissions.\n- Can't see other apps unless those apps are marked as visible to Instant Apps.\n- Can access only certain system settings.\n- Can access only certain system properties.\n- Can't expose services/providers.\n- Can receive and send with special rules around broadcasts.\n\n\nIn addition, Instant Apps have to opt in to allowing the new security sandbox to add more\nrestrictions. This wide range of special behaviors around Instant Apps cross cut\nthe entire platform, so there needs to be a way to validate that Instant Apps work as expected for all\ndevices in the ecosystem.\n\nTests running in Instant Apps mode\n----------------------------------\n\n\nNot all CTS modules have tests applicable to Instant Apps. If the functionality tested by\nthe module has interaction with the system server, then these tests should be run in the\nInstant Apps mode. For example, the OpenGL tests aren't interacting with the system server and so\nthere's no need to run them in Instant Apps mode while the accessibility tests interact with the\nsystem server but there is a need to run them in Instant Apps mode.\n\n\nIn addition to identifying which modules are applicable, users need to determine\nwhich tests in these modules are relevant. For example, testing service-specific behaviors for\na pluggable architecture (for example, AccessibilityService) isn't applicable for Instant App\nmode as Instant Apps can't expose services to other apps (including the platform) while tests\nvalidating app-side behaviors are applicable for Instant Apps mode. Another example is a test that\nvalidates behaviors behind a permission that an Instant App can't hold aren't relevant in Instant\nApp mode. There's a set of tests that apply only to Instant Apps that validate the rules around\nhow they behave, for example, not exposing services, or not seeing other apps. Typically,\nthese are already written and don't require porting.\n\nTest failures in Instant Apps mode\n----------------------------------\n\n\nIf the test is failing because it validates functionality that Instant Apps can't access, then it\nisn't applicable in Instant Apps mode. Mark the test to run only in Full App mode by annotating\nit with `@AppModeFull`. You can apply this annotation to the class level to exclude all\ntests in it.\n\n\nIf the test fails because some functionality accessible to Instant Apps is broken,\n[file a bug](/docs/setup/contribute/report-bugs).\n\nTroubleshooting\n---------------\n\n\nIf your test fails with *Failed to install MyCtsModule.apk on DEVICE. Reason: '-116'* ,\nlook for PackageManager messages on logcat. For example, if it says *Can't replace Full\nApp with Instant App: your_app*, then adb uninstall your app first."]]
