وبینار «هرچه می‌خواهید بپرسید» درباره رمزگشایی خط‌مشی Play

بسیار خوب.

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

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

و من امروز گرداننده این میزگرد خواهم بود.

می‌خواهم از اعضای پانل، بوهدان و پاول، بخواهم خودشان را معرفی کنند.

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

سلام، دوستان.

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

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

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

سلام به همه.

نام من پل است.

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

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

بسیار خوب، متشکرم.

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

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

آره.

منظور ما از خط‌مشی Play چیست؟

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

چند پیوند کوتاه برای منابع خط‌مشی Play در صفحه ارائه کرده‌ایم.

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

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

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

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

و درنهایت، پیوند سوم شما را به صفحه‌ای می‌برد که در آن می‌توانید درباره بینش‌های تحلیلی خط‌مشی Play در «استودیو Android» بیشتر بدانید، ویژگی‌ای که هدف آن ارائه راهنمایی‌های مفید پیش‌از بازبینی به‌صورت بررسی‌های lint در «استودیو Android» است.

بسیار خوب.

همچنین یک مهارت Android وجود دارد که به ممیزی برنامه‌های Android دربرابر این خط‌مشی‌های Google Play کمک می‌کند تا بتوانید مطابقت با خط‌مشی‌های مربوط به اجازه‌ها، حذف حساب، و ایمنی داده را تأیید کنید.

و می‌توانید این مهارت را بااستفاده از Android CLI درست مثل هر مهارت دیگری نصب کنید.

android skills list
android skills add play-policy-insights

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

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

شاید ساده به‌نظر برسد، اما یکی از دلایل بسیار رایج برای تأخیر یا رد شدن، محتوای غیرقابل‌دسترس است.

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

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

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

قبلاً «دسترسی به برنامه» نامیده می‌شد، اما اکنون «جزئیات ورود به سیستم» نامیده می‌شود و در بخش «محتوای برنامه» قرار دارد.

And then you want to make sure that the credentials bypass any kind of do-- two-factor authentication, captchas, paywalls, etc.

بله، کدهای نسخه قدیمی را غیرفعال کنید.

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

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

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

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

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

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

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

و سپس می‌توانید آن را با انتشار مدیریت‌شده پیوند دهید.

انتشار مدیریت‌شده ویژگی‌ای است که اجازه می‌دهد به‌روزرسانی‌های تأییدشده تا زمانی که برای انتشار آن‌ها آماده شوید نگه داشته شوند و از تأخیرهای غیرمنتظره درطول پویش‌های بازاریابی یا دیگر راه‌اندازی‌های حساس جلوگیری می‌کند.

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

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

فکر می‌کنم توسعه‌دهندگان گاهی این موضوع را فراموش می‌کنند و وقتی برنامه را تا نیمه ساخته‌اند، فراموش می‌کنند که «اوه، باید این تغییر کوچک را ایجاد کنم.»

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

درست است، اظهارنامه‌هایتان را بررسی کنید.

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

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

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

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

بنابراین، «نمایه کیت توسعه نرم‌افزار Google Play» را بررسی کنید تا اطلاعات آماری درباره بیش‌از ۱۰۰ کیت توسعه نرم‌افزار تجاری پرکاربرد را ببینید.

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

بنابراین، وقتی می‌گویید اعمال، منظورتان دقیقاً چیست؟

معنی این اصطلاح چیست؟

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

بنابراین، وقتی می‌گویم اقدامات اجرایی، منظورم این اقدامات نامطلوب است.

باحال.

متشکریم.

آره.

و درنهایت، از پژوهش‌خواهی استفاده کنید.

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

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

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

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

و سپس اگر مخالفید، یا شاید متوجه نمی‌شوید، اما فرض کنیم با رد شدن مخالفید، پژوهش‌خواهی کنید، درست است؟

اگر فکر می‌کنید که این یک نتیجه مثبت کاذب بوده است، می‌توانید از پیوند ارائه‌شده در ارتباطات برای پژوهش‌خواهی استفاده کنید.

و این نوعی گام اول بهتر است تا اینکه بدون ایجاد هیچ تغییری، عجولانه دوباره ارسال کنید.

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

و وقتی این کار را انجام دهید، با یک فرد واقعی ایمیل ردوبدل خواهید کرد.

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

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

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

بنابراین، بله.

با این اوصاف، دوباره آن را به Jan برمی‌گردانم.

بسیار خوب.

متشکریم.

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

بنابراین، این سؤالاتی که امروز در اینجا داریم، به‌نوعی نشان‌دهنده برخی‌از مسائلی است که اغلب از توسعه‌دهندگان درخصوص خط‌مشی می‌شنویم.

پس بیایید با این شروع کنیم.

برخی‌از دلایل رایج رد شدن برنامه دررابطه‌با اجازه‌ها چیست؟

و توسعه‌دهندگان چگونه می‌توانند از این رد شدن‌ها که مثلاً مربوط به نقض خط‌مشی اجازه است جلوگیری کنند؟

بسیار خوب.

اجازه‌ها، من این یکی را می‌گیرم.

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

بنابراین، اگر ویژگی کمکی یا ویژگی‌ای دارید که حتی در برنامه نیست و حتی تبلیغ نشده است، احتمال رد شدن برنامه بسیار زیاد است.

بنابراین، مطمئن شوید که اظهارنامه با مورد استفاده برنامه مطابقت داشته باشد.

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

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

بنابراین، فقط مطمئن شوید که همه‌چیز در برنامه، مانیفست، و اظهارنامه قابل‌دسترسی است.

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

باحال.

بسیار خوب.

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

اگر آن پلاتفرم‌ها محتوایی تولید کنند که نامناسب یا ازنظر واقعی نادرست یا چیزی شبیه به آن باشد، آیا می‌تواند منجر به رد شدن برنامه توسعه‌دهنده شود و در چنین مواردی واقعاً چه کسی مسئول است؟

آره.

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

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

بنابراین، هرچند هوش مصنوعی زایا حوزه جدیدی است، این موضوع برای آن هم صادق است.

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

باید سازوکار فیلتر کردن وجود داشته باشد.

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

بنابراین، Google، توسعه‌دهنده، خودتان، و کاربران همگی باهم همکاری می‌کنید تا برنامه را تا حد امکان برای همه ایمن نگه دارید.

بسیارخوب.

عالی.

اما به‌طور کلی، آیا توصیه می‌کنیم که، می‌دانید، علاوه‌بر داشتن سازوکارهایی برای پرچم‌گذاری محتوا توسط کاربران، توسعه‌دهندگان باید نوعی از سازوکار فیلتر کردن را قرار دهند؟ آیا منظورتان از سازوکار فیلتر کردن همین است؟

مثلاً برای جلوگیری از نمایش انواع خاصی از محتوا به کاربران در وهله اول؟

درست.

آره.

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

آن‌ها فقط می‌خواهند ببینند که آیا می‌توانند به چیز نامناسبی دسترسی پیدا کنند یا نه.

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

متوجه‌ام.

عالی است، متشکرم.

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

بنابراین اگر برنامه‌ای تحت آن خط‌مشی جعل هویت رد شود، اما آن‌ها به هر دلیلی معتقد باشند که این یک اشتباه است، چه کاری باید انجام دهند؟

و چگونه می‌توانند پیش‌دستانه از این نوع رد شدن جلوگیری کنند؟

پژوهش‌خواهی کنید.

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

و سپس کاری که باید انجام دهید این است که، خوب، رایج‌ترین سناریوها این خواهد بود که نمانامی که جعل هویت می‌کنید شاید نمانام خودتان باشد، درست است؟

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

و بنابراین، اما انتشار آن‌ها تحت حساب توسعه‌دهنده خودتان آسان‌تر است، درست است؟

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

و فرض کنید مشتری‌ای دارید به نام «جو چیکن» و آن‌ها بهترین مرغ را در غرب می‌سی‌سی‌پی دارند.

آن‌ها به شما یک نامه اثبات اجازه می‌دهند که در سربرگ شرکت، سربرگ رسمی شرکت با نشان‌واره آن‌ها، نوشته شده است: «ما، جوز چیکن، به توسعه‌دهنده ABC اجازه می‌دهیم که از تصاویر و شباهت‌های ما در برنامه خود استفاده کند.» و بهتر است نام برنامه و نام بسته برنامه را نیز در آن ذکر کنند.

مثلاً com.joeschicken.app یا چیزی شبیه به آن، و سپس می‌توانید به توسعه‌دهنده پاسخ دهید و آن سند را ارائه دهید.

بسیارخوب.

و بعد، فکر می‌کنم بخش دوم این بود که--

Just like is there anything proactively that they could do to avoid that?

مثلاً می‌توانید آن را بارگذاری کنید، یادم رفت اسمش چه بود، مدرک چیزی، می‌دانید، در زمانی که اولین ارسال را انجام می‌دهید؟

بله.

راست.

در «کنسول Play»، چیزی داریم که به آن فرم پیش‌اعلان می‌گوییم که می‌توانید آن را ارسال کنید، بارگذاری کنید، می‌دانید، این فرم‌های مستندات که حساب شما را با نهاد دیگر مرتبط می‌کند.

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

بله.

باحال.

بسیار خوب.

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

بنابراین، وقتی برنامه‌ها از کیت‌های توسعه نرم‌افزار طرف سوم استفاده می‌کنند، به‌نظر می‌رسد که توسعه‌دهندگان برنامه مسئول نحوه استفاده آن کیت‌های توسعه نرم‌افزار طرف سوم از مواردی مانند داده‌های کاربر هستند.

پس توسعه‌دهندگان چگونه باید بدانند که کیت‌های توسعه نرم‌افزار با خط‌مشی‌های ایمنی داده و داده‌های کاربر مطابقت دارند؟

مثلاً، چگونه می‌توانند در آن چشم‌انداز پیمایش کنند؟

بله، سؤال خوبی است.

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

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

این باید اولین یا دومین نتیجه باشد، نمایه کیت توسعه نرم‌افزار Google Play، و آنچه دریافت خواهید کرد یک صفحه وب است که بیش از صد، شاید چند صد کیت توسعه نرم‌افزار دارد که براساس اینکه آیا کیت توسعه نرم‌افزار برای درآمدزایی است، یا برای تبلیغات، یا برای سلامتی، یا چیز دیگری تقسیم شده است؟

و آن صفحه فقط داده‌های دردسترس عموم را استخراج می‌کند.

این رویدادی است که Google سازمان‌دهی می‌کند.

اما چیزی که متوجه خواهید شد این است که وقتی این کیت‌های توسعه نرم‌افزار را بررسی می‌کنید، در کنار برخی‌از آن‌ها نشانی وجود دارد که چیزی شبیه به «ثبت‌شده در کنسول کیت توسعه نرم‌افزار» را نشان می‌دهد.

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

و باید فرایند بازبینی مشابهی را طی کنند.

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

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

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

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

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

فقط یک احتمال است.

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

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

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

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

و اعلان چیزی شبیه به این خواهد بود: «سلام، متوجه شدیم که برنامه‌تان آن داده‌ها را به‌شیوه‌ای ناسازگار ارسال می‌کند و متوجه شدیم که این اتفاق در ABC SDK رخ می‌دهد.»

بنابراین، اقداماتی که به‌عنوان توسعه‌دهنده می‌توانید انجام دهید این است که کیت توسعه نرم‌افزار را به هر نسخه سازگاری که ارائه کرده‌اند به‌روز کنید.

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

اما این همان چیزی است که من درباره «نمایه کیت توسعه نرم‌افزار Google Play» دوست دارم.

آره.

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

بسیارخوب.

آره.

بسیارخوب، خوب است.

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

آیا به آن‌ها می‌گوییم که مثلاً اگر قرار است به‌روزرسانی کنند، به آن‌ها می‌گوییم چه نسخه‌ای؟ اگر توسعه‌دهنده آن را برطرف کند، آیا به آن‌ها می‌گوییم مثلاً «سلام، نسخه بهتر فلان است»؟

یا اینکه خودشان باید کمی تحقیق کنند؟

فکر می‌کنم کد نسخه واقعاً در آنجا وجود دارد.

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

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

جالب است.

باحال.

متشکریم.

بسیار خوب.

کمی درباره اعتبارنامه ورود به سیستم صحبت کردید، موضوعی که حداقل تاحدودی با آن آشنا هستم و اینکه چقدر مهم است که این اطلاعات در آنجا باشد.

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

اما توسعه‌دهندگان باید چه موقعیت‌های رایج دیگری را درنظر بگیرند؟

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

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

آره.

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

آن بخش در «کنسول Play» قبلاً دسترسی به برنامه نامیده می‌شد و فکر می‌کنم حدود یک ماه پیش یا کمی بیشتر به جزئیات ورود به سیستم تغییر کرد.

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

بنابراین، می‌توانید دستورالعمل‌هایی ارائه دهید، مثلاً اگر مراحل ورود به سیستم خیلی ساده نیست، چگونه باید انجام شود.

همچنین می‌توانید درصورت تمایل، اطلاعات ورود به سیستم دوم، سوم، و چهارم را برای کاربران ارائه دهید.

و برای اینکه شاید کمی بینش به شما بدهم، مثلاً وقتی تیم‌های ما برنامه‌ها را بررسی می‌کنند، این‌طور نیست که کسی در اتاقی نشسته باشد و کمی جستجو کند و سپس فقط روی تأیید یا رد کلیک کند.

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

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

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

بنابراین، ارائه چندین ورود به سیستم می‌تواند کمک کند.

آره.

باحال.

بله، باید بر اهمیت استفاده از آن نوشتار آزاد در اظهارنامه تأکید کنم.

بنابراین، اگر حساب نمایشی شما، مثلاً، فقط یک نام کاربری و گذرواژه نیست و مراحل بیشتری دارد، حتماً باید مطمئن شوید که تیم بازبینی ما می‌داند چگونه وارد برنامه‌تان شود.

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

آره.

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

مثلاً مواردی را دیده‌ام که، و این را از خودم درنمی‌آورم، می‌گوید ۱۷ بار روی این دکمه تک‌ضرب بزنید، و سپس مثلاً یک X روی صفحه‌نمایش بکشید، و سپس مثلاً حالت توسعه‌دهنده ظاهر می‌شود، و سپس مثلاً، می‌دانید، ۱۱ مرحله دیگر را باید دنبال کنید، پس لطفاً این کار را نکنید.

چون این کار را کمی سخت می‌کند.

یک سناریویی که شنیده‌ام این است که برخی برنامه‌ها فقط به شما اجازه می‌دهند مثلاً X ورود متوالی یا ورود هم‌زمان به یک برنامه داشته باشید و بعداز آن می‌گوید: «اوه، باید یکی را بردارید.»

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

آره.

باحال.

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

بنابراین، گاهی اوقات این موارد با مهلت همراه هستند، درست است؟

مثلاً تا این تاریخ باید فلان کار را انجام دهید تا با خط‌مشی جدیدی مطابقت داشته باشید.

اگر آن مهلت نزدیک است، اما توسعه‌دهنده می‌داند که برای رعایت کردن به زمان بیشتری نیاز دارد، چه گزینه‌هایی دارد؟

بله، این شبیه یک هشدار است.

بله، شبیه هشدار است.

آره.

بله، بنابراین، با هشدارها، منظورم این است که، هشدار ساده این است که، این-- فقط زمان بیشتری بخواهید، درست است؟

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

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

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

و سپس، بله، سپس هشدارها ارسال می‌شوند و ما می‌گوییم: «سلام، برنامه شما این خط‌مشی را که مثلاً ۶ یا ۱۲ ماه پیش اعلام شده بود نقض می‌کند.»

اما یک چیز که، و من و پل گاهی با آن مخالفت می‌کنیم، این است که ممکن است بگویند ۷ روز فرصت دارید تا این تغییر را اعمال کنید.

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

مثلاً، ما متوجه می‌شویم.

بنابراین، کاری که من می‌کنم این است که فقط پاسخ می‌دهم.

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

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

بنابراین، معمولاً کمی بیشتر به شما وقت می‌دهند.

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

البته این فضا بی‌نهایت نیست.

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

مثلاً وقتی می‌دانیم که خط‌مشی‌های جدیدی در راه است و می‌دانیم که چه کسانی روی آن کار می‌کنند، می‌گوییم: «ببینید، آیا این می‌تواند یک هشدار ۲۸ روزه باشد به‌جای ۷ روز، یا حداقل ۱۴ روز؟»

آره.

راست.

اگر حسن نیت نشان دهید، مثلاً ثابت کنید که با حسن نیت درحال ایجاد تغییرات برای مطابقت با خط‌مشی هستید، Google Play با شما همکاری خواهد کرد تا مهلت جدیدی برای اثبات آن تعیین کند.

خط زمان بهتری برای شما.

بسیارخوب.

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

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

بسیار خوب.

بنابراین، اگر توسعه‌دهنده‌ای چند برنامه تحت یک حساب توسعه‌دهنده داشته باشد، که می‌دانم همیشه اتفاق می‌افتد.

و یکی از برنامه‌ها به‌دلیل نوعی نقض خط‌مشی تعلیق می‌شود، این موضوع چه تأثیری بر کل حساب توسعه‌دهنده آن‌ها دارد؟

آیا این کار حساب یا سایر برنامه‌های مطابق با خط‌مشی را درمعرض خطر قرار می‌دهد؟

چگونه کار می‌کند؟

شاید.

این مثل توسعه‌دهندگان برچسب سفید شما است.

قبلاً درباره «جو چیکن» صحبت می‌کردم، درست است؟

و شاید شما، مثلاً، کارخواهانی دارید که همه در آن صنعت هستند.

و بنابراین، من آن را به نوعی مانند بازی بیسبال می‌دانم، و شما مانند استرایک اوت هستید، درست است؟

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

بنابراین اگر یکی از این سناریوها را داشته باشید که در آن تعداد زیادی برنامه در «فروشگاه Play» دارید که همه مشابه هستند و یکی از آن‌ها تعلیق می‌شود، فرض کنید که…

اوهوم.

تو یک عامل مخرب هستی، درست است؟

و بنابراین آن را اصلاح می‌کنید و سپس یک ماه بعد سعی می‌کنید آن را دوباره وارد کنید.

و سپس تیم‌های ما متوجه آن می‌شوند و دوباره تعلیق می‌شوید، درست است؟

و سپس آن را از برنامه‌تان حذف می‌کنید و بعد مثلاً یک ماه بعد دوباره آن را اضافه می‌کنید و سپس، خوب حالا ما یک الگوی رفتاری تکراری داریم و شما در نوبت ضربه زدن هستید، سه بار توپ را ازدست داده‌اید و حالا دیگر از بازی خارج شده‌اید، درست است؟

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

بنابراین، فرض کنید همه این برنامه‌ها را هم‌زمان با مثلاً خط لوله CI/CD یا چیزی شبیه به آن ارسال می‌کنید و مثلاً ۱۰ برنامه دریافت می‌کنید که همه آن‌ها هم‌زمان این رد یا تعلیق را دریافت می‌کنند، ما فقط به آن به‌عنوان یک اخطار نگاه می‌کنیم چون متوجه هستیم که شما تعداد زیادی برنامه را هم‌زمان ارسال می‌کنید.

اوهوم.

جالب است.

فکر می‌کنم این پاسخ سؤال بود.

آره، دوست‌داشتنی است.

متشکریم.

و یک مورد دیگر هم اینجا برایمان دارم.

و این یکی شاید بسیاری از این سؤالات بیشتر برای توسعه‌دهندگان تثبیت‌شده باشد، اما این یکی بیشتر درباره زمانی است که برای اولین‌بار در «کنسول Play» راه‌اندازی می‌کنید.

بنابراین، فرض کنیم که نمایه پرداخت Google Play شما درستی‌سنجی شده است، هویت… اوه، این خیلی طولانی است.

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

مثلاً توسعه‌دهنده در آن مورد خاص چه کاری انجام می‌دهد تا مطمئن شود حساب توسعه‌دهنده‌اش برای انتشار برنامه آماده است؟

مثلاً گاهی اوقات، شما مثل این است که این قطعات پازل را جدا می‌کنید یا اگر آن‌ها نمی‌دانند چگونه فرایند را در چنین موردی به پایان برسانند، چه کاری می‌توانند انجام دهند؟

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

این شاید یک سال پیش بود، درست است؟

دقیقاً به‌خاطر نمی‌آورم.

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

بسیارخوب.

یا مثلاً اگر نشانی و نمایه Dun & Bradstreet آن‌ها مطابقت نداشته باشد…

راست.

راست.

نمایه Google.

بسیارخوب.

بله، پس فرض کنیم شماره تلفن است.

من به این سؤال به دو روش پاسخ می‌دهم.

بسیارخوب.

یکی از آن‌ها این است که وقتی این مراحل را طی می‌کنید، در بسیاری از مواقع اعلان‌هایی در «کنسول Play Developer» شما ظاهر می‌شود.

و بنابراین فقط اعلانی دریافت می‌کنید که می‌گوید: «سلام، وقت آن رسیده است که شماره تلفنتان را ثبت کنید.»

و این یکی خیلی ساده است.

آن را در قالب شماره تلفن بین‌المللی، به‌علاوه ۱ ۴۰۸، هر شماره‌ای که هست، قرار می‌دهید.

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

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

مراحل دسترسی به تیم پژوهش‌خواهی را به شما نشان می‌دهم.

این یک تیم است، اما درواقع اگر ندانم که نیم دوجین یا دو دوجین تیم دیگر وجود دارد که…

Will.

به سؤالات در Play Developer Console که واقعاً به آن دسترسی دارید پاسخ دهید و این کار ازطریق منو راهنما انجام می‌شود.

اکنون آن واسط کاربر کمی تغییر کرده است.

قبلاً در منویی در سمت راست صفحه اصلی‌تان بود.

در پایین، دکمه راهنما داشتید.

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

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

فکر می‌کنم این چیزی است که می‌گوید.

اوهوم.

بله.

و سپس چند منو کرکره‌ای دریافت می‌کنید که می‌توانید سؤال بپرسید.

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

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

و سپس شاید کد درستی‌سنجی پیامکی دریافت می‌کنید، یا وقتی می‌خواهید آن فرایند را طی کنید، اشکالی در صفحه‌تان ظاهر می‌شود.

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

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

عالی.

باحال.

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