پیمایش کیفیت چنددستگاهی و انتشار فراتر از تلفن همراه در Google Play

خوش آمدید.

از اینکه در این جلسه درباره پیمایش کیفیت برنامه چنددستگاهی و انتشار در Google Play برای عوامل شکل فراتر از تلفن همراه به ما پیوستید بسیار سپاس‌گزاریم.

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

و من فاستین لیائو، رهبر عملیات در تیم ایمنی و اعتماد Play هستم.

بسیار خوشحالیم که امروز همه شما را در اینجا در کنار خود داریم.

بنابراین سال‌هاست که وقتی می‌گوییم توسعه Android، بیشتر ما واقعاً فقط یک دستگاه همراه را تصور می‌کنیم، اما بوم‌سازگان Android بسیار فراتر از تلفن‌های هوشمند گسترش یافته است.

بنابراین امروزه، کاربران شما با برنامه‌ها در اتاق نشیمن خود در Android TV، شاید در صف خودروهای اشتراکی یا هنگام شارژ کردن خودروهایشان در Android Auto یا Automotive OS، روی مچ دستشان با Wear OS، و به‌طور فزاینده‌ای در فضاهای سه‌بعدی فراگیر با Android XR تعامل دارند.

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

فرایند کلی از ساخت برنامه تا انتشار و فعال شدن آن در Google Play معمولاً همان فرایندی است که برای نسخه‌های پخش تلفن همراه استفاده می‌کنید.

برنامه‌تان را بسازید و آماده کنید، سپس فهرستگان خود را در «کنسول Play» ایجاد کنید، برنامه‌تان را آزمایش کنید، نسخه تولیدتان را بارگذاری و ارسال کنید، و سپس منتظر بررسی و تأیید بمانید.

بااین‌حال، ملاحظات منحصربه‌فردی برای انتشار برنامه‌ها برای ضریب‌های شکل فراتر از تلفن همراه وجود دارد.

و امروز، چارچوب واضحی را به شما ارائه می‌دهیم تا به شما کمک کند برای فرایند انتشار چنددستگاهی روان‌تر و قابل‌پیش‌بینی‌تر آماده شوید.

بیایید با اصول اولیه شروع کنیم: نحوه معماری و بسته‌بندی برنامه.

بنابراین، حتی قبل‌از اینکه به «کنسول Google Play» دست بزنید، باید تصمیم مهمی درباره معماری بگیرید.

آیا یک بسته برنامه واحد و یکپارچه می‌سازید که شامل همه چیز برای همه ضریب‌های شکلی باشد که پشتیبانی می‌کنید، یا برنامه‌تان را به واحدهای مختص ضریب شکل تقسیم می‌کنید و برای هرکدام «بسته ترکیبی برنامه Android» یا AAB تولید می‌کنید؟

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

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

بنابراین، اگرچه رویکرد بسته ترکیبی برنامه Android یکپارچه ممکن است برای مدیریت ساده‌تر به‌نظر برسد، ما درواقع رویکرد مدولار را توصیه می‌کنیم.

بنابراین، در اینجا مثالی آورده شده است که نشان می‌دهد چرا این رویکرد مدولار را توصیه می‌کنیم.

بنابراین فرض کنید برنامه‌ای دارید که هم از تلفن همراه و هم از Android TV پشتیبانی می‌کند.

اگر یک بسته برنامه Android را در دسته هدف انتشار استاندارد تلفن همراه ارسال کنید و برنامه Android TV شما در بررسی رد شود، کل انتشار متوقف می‌شود.

بنابراین این موضوع هم بر انتشار برنامه Android TV و هم بر برنامه تلفن همراه شما تأثیر می‌گذارد.

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

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

بنابراین، اگر برای برنامه تلفن همراه و برنامه تلویزیون خود ماژول‌های برنامه جداگانه دارید، می‌توانید برای هرکدام بسته‌های ترکیبی برنامه Android جداگانه تولید کنید.

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

نسخه پخش برنامه تلفن همراه طبق برنامه منتشر خواهد شد.

اکنون همان‌طور که قبلاً اشاره کردم، رویکردهای زیادی برای مدولارسازی وجود دارد.

بنابراین، در اینجا فقط یک نمونه از رویکردی برای مدولار کردن برنامه کتاب صوتی که تجربه تلفن همراه و تجربه سیستم‌عامل Android Automotive دارد آورده شده است.

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

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

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

و سپس در فایل‌های تنظیمات Gradle پروژه‌تان، می‌توانید این پیکربندی Gradle چندماژولی را برای پشتیبانی از این نوع ماژول‌سازی اضافه و راه‌اندازی کنید.

...

rootProject.name = "MultiFormFactorApp"

// Define modules for each form factor
include(":app:automotive")
include(":app:mobile")
include(":core:network")
include(":data:books")
include(":data:reviews")
include(":feature:home")
include(":feature:player")
include(":feature:reviews")

بنابراین، برای هر واحد و دسته برنامه از همان نام بسته یا شناسه برنامه استفاده خواهید کرد.

این رویکرد مدولار مستقیماً به استراتژی دسته هدف شما در «کنسول Play» مرتبط است.

وقتی منتشر می‌کنید، دسته هدف استاندارد تلفن همراه را دارید، اما ما دسته‌های هدف اختصاصی ضریب شکل را نیز ارائه می‌دهیم.

برای Android TV،‏ Android XR، و «سیستم عامل Android Automotive»، حق انتخاب دارید.

می‌توانید در کنار تلفن همراه منتشر کنید یا از دسته‌های اختصاصی فرم فاکتور آن‌ها استفاده کنید.

بااین‌حال، دو استثنا وجود دارد.

برای Wear OS، باید از دسته هدف اختصاصی Wear OS استفاده کنید.

و برای Android Auto، چون اساساً افزونه‌ای از برنامه تلفن همراه شما است که روی صفحه‌نمایش خودرو نمایش داده می‌شود، تنها انتخاب، قطعه استاندارد تلفن همراه است.

اگر چندین دسته هدف را مدیریت می‌کنید، نسخه‌بندی بسیار مهم است.

یک رویکرد این است که چند رقم اول کد نسخه را به فرم فاکتور اختصاص دهید.

برای مثال، 01 برای تلفن همراه، 02 برای Wear OS،‏ 03 برای سیستم عامل Android Automotive، و غیره.

به‌طور کلی توصیه می‌کنیم کدهای نسخه را حداقل هفت رقمی کنید تا بتوان از ارقام باقی‌مانده برای نسخه برنامه استفاده کرد.

این کار به جلوگیری از تداخل کد نسخه در «کنسول Play» کمک می‌کند.

وقتی برنامه‌تان بسته‌بندی شد، اکنون زمان آزمایش است.

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

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

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

بنابراین، آزمایش داخلی نقطه شروع خوبی است.

این آزمایش به شما امکان می‌دهد برنامه‌تان را به‌سرعت بین حداکثر ۱۰۰ آزمایش‌کننده توزیع کنید و مهم‌تر اینکه، بازبینی Play را راه‌اندازی نمی‌کند.

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

و با آزمایش‌های داخلی، نشانی وب یکتایی دریافت خواهید کرد که می‌توانید با آن آزمایش‌گران هم‌رسانی کنید.

وقتی از نتایج آزمایش داخلی راضی بودید، می‌توانید به آزمایش بسته و آزمایش باز بروید.

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

می‌توانید گروه‌های آزمایش بسته را به‌صورت فهرست نشانی‌های ایمیل یا ازطریق «گروه‌های Google» مدیریت کنید.

ازسوی‌دیگر، آزمایش باز به شما کمک می‌کند آزمایشی را با گروه بزرگ‌تری در Google Play اجرا کنید.

در Google Play نمایان خواهید بود و هرکسی می‌تواند به برنامه آزمایش باز بپیوندد.

نیازی به دعوت نیست و آن‌ها می‌توانند بازخورد و بازخورد خصوصی درباره برنامه را با شما هم‌رسانی کنند.

این دسته‌های هدف آزمایشی باز و بسته باعث شروع بازبینی می‌شوند.

این درواقع یک مزیت بزرگ است.

این کار به شما امکان می‌دهد فرایند بازبینی را آزمایش کنید و هرگونه مانعی را خیلی قبل‌از روز راه‌اندازی موردانتظارتان برطرف کنید.

بنابراین، با صحبت درباره فرایند بررسی، بیایید کمی درباره آنچه این فرایند شامل می‌شود و چرا مهم است صحبت کنیم.

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

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

بنابراین، بیایید ببینیم چگونه می‌توانید برنامه‌تان را آماده کنید تا بازبینی‌ها را به‌آسانی پشت سر بگذارد.

به‌نظرم بهترین جا برای شروع، نگاه کردن به دستورالعمل‌های «کیفیت برنامه» است که بر ظاهر یک تجربه کاربری عالی تمرکز دارد.

ما دستورالعمل‌های «کیفیت برنامه اصلی» را منتشر می‌کنیم که برای همه برنامه‌ها اعمال می‌شود و حداقل کیفیتی را که همه برنامه‌ها باید داشته باشند تعریف می‌کند، همچنین دستورالعمل‌های «کیفیت برنامه» تطبیقی را منتشر می‌کنیم که به شما کمک می‌کند مطمئن شوید برنامه‌تان تجربه عالی‌ای را بدون توجه به ابعاد دستگاه، اندازه صفحه‌نمایش، یا حالت نمایش ارائه می‌دهد.

این دو مجموعه دستورالعمل باهم نقطه شروع بسیار خوبی هستند.

اما ما همچنین دستورالعمل‌های «کیفیت برنامه» مختص ضریب شکل را برای هریک از ضریب‌های شکل داریم.

بازبین‌های ما برنامه‌هایتان را در دستگاه‌های واقعی و شبیه‌سازها براساس این دستورالعمل‌ها آزمایش خواهند کرد.

بنابراین، بسیار مهم است که مطمئن شوید برنامه‌تان از آن‌ها پیروی می‌کند.

بنابراین، در ادامه نگاهی سریع به رایج‌ترین دلایلی که برنامه‌ها برای هر ضریب شکل رد می‌شوند می‌اندازیم.

اما به‌خاطر داشته باشید که این موارد شامل فهرست کاملی از همه دستورالعمل‌های «کیفیت برنامه» نمی‌شود.

بنابراین، حتماً آن دستورالعمل‌های کیفیت را برای هر فاکتور فرمی که با آن کار می‌کنید به‌طور دقیق مشاهده کنید تا با مجموعه معیارهای قوی‌تری آشنا شوید.

بنابراین، بیایید با Android TV شروع کنیم.

بنابراین، در پایین این اسلایدهای بخش، پیوند کوتاهی خواهید دید که شما را به فهرست کامل دستورالعمل‌های «کیفیت برنامه» برای آن ضریب شکل هدایت می‌کند.

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

بنابراین، کاری که باید انجام دهید این است که تصویری با ابعاد ۳۲۰ در ۱۸۰ پیکسل ارائه دهید که شامل نوشتار بومی‌سازی‌شده‌ای باشد که برنامه شما را شناسایی می‌کند.

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

دوم اینکه در اکثر تلویزیون‌ها، کاربران بااستفاده از کنترل از دور پد کنترل با دستگاه تعامل برقرار می‌کنند.

بنابراین، بسیار مهم است که به‌درستی از پیمایش و تمرکز پد کنترل پشتیبانی کنید.

مطمئن شوید که حداقل از کنترل‌های پد کنترل پشتیبانی می‌کنید تا براساس این معیارها رد نشوید.

و سومین دلیل رایج برای رد شدن برنامه Android TV این است که فیلتر هدف CATEGORY_LEANBACK_LAUNCHER در فایل مانیفست Android شما وجود ندارد.

<application ...>
...
<activity
    android:name="com.example.TvActivity"
    android:label="@string/app_name"
    android:theme="@style/Theme.Leanback">
    <intent-filter>
      <action android:name=
           "android.intent.action.MAIN" />
      <category android:name=
           "Android.intent.category.
            LEANBACK_LAUNCHER" />
    </intent-filter>
  </activity>
</application>

این فیلتر برنامه شما را به‌عنوان برنامه‌ای که برای تلویزیون فعال شده است شناسایی می‌کند و به Google Play نیز اجازه می‌دهد آن را به‌عنوان برنامه تلویزیون به کاربران معرفی کند.

بنابراین وقتی کاربر برنامه‌تان را در صفحه اصلی تلویزیون انتخاب می‌کند، این هدف مشخص می‌کند کدام فعالیت راه‌اندازی شود.

بنابراین مطمئن شوید که آن را در مانیفست خود گنجانده‌اید.

‫Android XR بعدی است.

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

می‌توانید از Perfetto برای نمایه کردن عملکرد برنامه‌هایی که با Jetpack XR SDK ساخته شده‌اند استفاده کنید تا مطمئن شوید که از حداقل الزامات نرخ فریم پیروی می‌کنید.

و اگر بااستفاده از موتور هم‌زمان مانند Unity می‌سازید، می‌توانید از ابزارهای نمایه‌سازی داخلی آن موتور که در موتور تعبیه شده‌اند استفاده کنید تا مطمئن شوید که الزامات پرداز را رعایت می‌کنید.

بعداز آن خودروها را داریم که شامل Android Auto و «سیستم عامل Android Automotive» می‌شود.

برای Android Auto و سیستم عامل Android Automotive، مفهوم دسته‌ها وجود دارد که برای این ضریب شکل خاص کمی منحصربه‌فرد است.

و فقط دسته‌های خاصی از برنامه‌ها مجاز به انتشار در خودروها هستند.

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

بنابراین اجازه دهید منظورم را با جزئیات بیشتری به شما نشان دهم.

در اینجا می‌توانید نمای کلی‌ای از دسته‌های برنامه‌هایی را که در خودروها برای هر پلاتفرم پشتیبانی می‌شوند، به‌همراه دردسترس بودن آن‌ها ببینید.

بنابراین، چه در نسخه بتا باشد، چه باز باشد، که به معنای دردسترس بودن عمومی است، یا هنوز پشتیبانی نشود، که در اینجا با «به‌زودی» نشان داده شده است.

بنابراین برخی‌از دسته‌ها مانند برنامه‌های ناوبری یا مکان‌های جالب به‌طور عمومی دردسترس هستند و این یعنی هرکسی می‌تواند برنامه‌ای را در یکی از این دسته‌ها برای خودروها در نسخه تولیدی منتشر کند.

اما دسته‌های دیگر مانند برنامه‌های تماس ارتباطی برای Android Auto در مرحله بتا هستند.

بنابراین برای این دسته‌ها، می‌توانید در دسته هدف آزمایشی داخلی یا بسته منتشر کنید، اما نمی‌توانید در دسته هدف تولید منتشر کنید مگراینکه در یکی از برنامه‌های دسترسی زودرس ما برای آن دسته پذیرفته شده باشید.

و می‌توانید جزئیات بیشتر درباره این موضوع و موارد دیگر را در راهنماهای توسعه‌دهندگان «Android ویژه خودرو» پیدا کنید.

در آنجا می‌توانید پیوندهایی را برای نامزد کردن خودتان برای آن برنامه‌های دسترسی زودرس پیدا کنید.

یکی دیگر از دلایل رایجی که می‌بینیم برنامه‌ها رد می‌شوند، مشخصات نادرست یا نبود مشخصات برای نماگرفت‌های «سیستم‌عامل Android Automotive» است.

بنابراین وقتی نماگرفت‌های «سیستم عامل Android Automotive» را ارائه می‌کنید، باید مطمئن شوید که حداقل دو نماگرفت با جهت عمودی و حداقل دو نماگرفت با جهت افقی با ابعاد فهرست‌شده در اینجا اضافه کنید.

و می‌توانید از شبیه‌ساز «سیستم عامل Android Automotive» برای کمک به ضبط این موارد استفاده کنید.

این ویژگی به‌گونه‌ای تنظیم شده است که می‌تواند نماگرفت‌ها را دقیقاً در اندازه موردنیاز شما ضبط کند.

و درنهایت، ایمنی در برنامه‌های خودرو از اهمیت بالایی برخوردار است.

بنابراین اگر برنامه‌تان از رهنمودهای ما درباره حواس‌پرتی راننده پیروی نکند، رد خواهد شد.

برای مثال، برنامه ویدیویی باید بازپخش را موقتاً متوقف کند و وقتی خودرو درحال حرکت است نباید قابل‌مشاهده باشد.

و در آخر، Wear OS را داریم.

بنابراین، اگر برنامه‌های Wear OS برای نمایشگرهای کوچک و گرد بهینه‌سازی و قالب‌بندی نشده باشند، ممکن است رد شوند.

بنابراین توصیه ما در اینجا استفاده از جدیدترین نسخه پایدار Compose for Wear OS است تا مطمئن شوید که محتوا در لبه‌های دستگاه‌هایی با اندازه‌های مختلف قطع نمی‌شود، یا مثلاً مطمئن شوید که نوار پیمایش هنگام وجود محتوای پیمایش‌شدنی ظاهر می‌شود.

@Composable
fun MyText() {
  Text(
    text = stringResource(R.string.compose_for_wear_os),
    modifier = Modifier.fillMaxWidth(),
    textAlign = TextAlign.Center,
    style = MaterialTheme.typography.titleLarge
  )
}

و مشابه آنچه برای «سیستم‌عامل Android Automotive» ذکر کردیم، برنامه‌های Wear OS نیز ممکن است به‌دلیل نداشتن نماگرفت‌های Wear OS یا دقیق نبودن آن‌ها رد شوند.

در اینجا نمونه‌ای از نماگرفت خوب از فهرستگان «فروشگاه Google Play» برای برنامه نمونه Androidify آورده شده است که الزامات را برآورده می‌کند.

بنابراین مطمئن شوید حداقل یک نماگرفت ارسال کنید که برنامه‌تان را درحال اجرا در دستگاه Wear OS نشان دهد.

نتیجه؟

دستورالعمل‌های کیفیت برنامه را برای ضریب شکل خاص خود بخوانید و قبل‌از ارسال، برنامه را براساس آن‌ها آزمایش کنید.

همچنین، چند نکته مهم.

اگر برنامه‌تان به ورود به سیستم نیاز دارد، باید حساب نمایشی فعال و اعتبارنامه معتبر در بخش دسترسی به برنامه «کنسول Play» ارائه دهید.

اگر بازبین‌های ما نتوانند به سیستم وارد شوند، نمی‌توانیم برنامه‌تان را آزمایش کنیم و به‌طور خودکار رد خواهید شد.

همچنین، حتماً به وعده‌هایتان عمل کنید.

فقط از نماگرفت‌های تلفن همراه استفاده نکنید.

اگر برنامه‌تان برای Wear OS و Android TV دردسترس است، حتماً نماگرفت‌های باکیفیت بالا برای آن قالب‌های ساخت خاص در «کنسول Play» بارگذاری کنید.

و در آخر، توصیفی باشید.

دقیقاً به کاربران بگویید برنامه چه کاری انجام می‌دهد، چرا ارزشمند است، و کاربران هنگام نصب آن در هر نوع دستگاه چه انتظاری می‌توانند داشته باشند.

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

از همه شما بابت وقتی که امروز گذاشتید بسیار سپاس‌گزارم.

بی‌صبرانه منتظریم تا تجربه‌های شگفت‌انگیز چنددستگاهی را که همه شما به Google Play خواهید آورد ببینیم.