API های اندروید 4.0

سطح API: 14

Android 4.0 ( ICE_CREAM_SANDWICH ) یک نسخه پلتفرم اصلی است که ویژگی‌های جدید مختلفی را برای کاربران و توسعه‌دهندگان برنامه اضافه می‌کند. علاوه بر تمام ویژگی‌های جدید و APIهایی که در زیر مورد بحث قرار می‌گیرند، Android 4.0 نسخه مهمی از پلتفرم است، زیرا مجموعه گسترده‌ای از APIها و تم‌های هولوگرافیک را از Android 3.x به صفحه‌نمایش‌های کوچک‌تر می‌آورد. به‌عنوان یک توسعه‌دهنده برنامه، اکنون یک پلتفرم واحد و چارچوب API یکپارچه دارید که به شما امکان می‌دهد برنامه‌تان را با یک APK توسعه و منتشر کنید که تجربه کاربری بهینه‌شده‌ای را برای گوشی‌ها، تبلت‌ها و موارد دیگر در هنگام اجرای همان نسخه Android ارائه می‌کند. Android 4.0 (سطح API 14) یا بالاتر.

برای توسعه دهندگان، پلتفرم Android 4.0 به عنوان یک جزء قابل دانلود برای Android SDK در دسترس است. پلتفرم قابل دانلود شامل کتابخانه اندروید و تصویر سیستم، و همچنین مجموعه ای از پوسته های شبیه ساز و موارد دیگر است. برای شروع توسعه یا آزمایش با Android 4.0، از Android SDK Manager برای دانلود پلتفرم در SDK خود استفاده کنید.

نمای کلی API

بخش های زیر یک نمای کلی فنی از API های جدید در اندروید 4.0 ارائه می دهد.

API های اجتماعی در ارائه دهنده مخاطبین

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

نمایه کاربر

Android اکنون دارای یک نمایه شخصی است که نشان دهنده مالک دستگاه است، همانطور که توسط جدول ContactsContract.Profile تعریف شده است. برنامه‌های اجتماعی که هویت کاربر را حفظ می‌کنند، می‌توانند با ایجاد یک ورودی ContactsContract.RawContacts جدید در ContactsContract.Profile به اطلاعات نمایه کاربر کمک کنند. یعنی مخاطبین خام که نماینده کاربر دستگاه هستند در جدول مخاطبین خام سنتی تعریف شده توسط ContactsContract.RawContacts Uri قرار ندارند. در عوض، باید یک مخاطب خام نمایه را در جدول در CONTENT_RAW_CONTACTS_URI اضافه کنید. سپس مخاطبین خام در این جدول در نمایه قابل مشاهده برای کاربر با برچسب "من" جمع می شوند.

افزودن یک مخاطب خام جدید برای نمایه به مجوز android.Manifest.permission#WRITE_PROFILE نیاز دارد. به همین ترتیب، برای خواندن از جدول نمایه، باید مجوز android.Manifest.permission#READ_PROFILE را درخواست کنید. با این حال، اکثر برنامه‌ها حتی زمانی که داده‌ها را به نمایه می‌دهند، نیازی به خواندن نمایه کاربر ندارند. خواندن نمایه کاربر یک مجوز حساس است و باید انتظار داشته باشید که کاربران نسبت به برنامه هایی که آن را درخواست می کنند شک داشته باشند.

Invite Intent

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

برای اینکه برنامه شما مانند لیست "افزودن اتصال" قابل مشاهده باشد، برنامه شما باید یک آداپتور همگام سازی برای همگام سازی اطلاعات تماس از شبکه اجتماعی شما ارائه دهد. سپس باید به سیستم نشان دهید که برنامه شما به هدف INVITE_CONTACT با افزودن ویژگی inviteContactActivity به فایل پیکربندی همگام سازی برنامه خود، با نام کاملاً واجد شرایط فعالیتی که سیستم باید هنگام ارسال هدف دعوت شروع کند، پاسخ می دهد. سپس فعالیتی که شروع می‌شود می‌تواند URI مخاطب مورد نظر را از داده‌های intent بازیابی کند و کارهای لازم را برای دعوت آن مخاطب به شبکه یا اضافه کردن شخص به اتصالات کاربر انجام دهد.

عکس های بزرگ

اندروید اکنون از عکس‌های با وضوح بالا برای مخاطبین پشتیبانی می‌کند. اکنون، هنگامی که عکسی را در یک رکورد مخاطب قرار می دهید، سیستم آن را به یک تصویر کوچک 96x96 (همانطور که قبلا انجام داده بود) و یک "عکس نمایش داده شده" 256x256 که در یک فروشگاه عکس جدید مبتنی بر فایل ذخیره شده است پردازش می کند (اندازه های دقیق انتخاب سیستم ممکن است در آینده متفاوت باشد). می‌توانید با قرار دادن یک عکس بزرگ در ستون PHOTO معمول یک ردیف داده، یک عکس بزرگ به مخاطب اضافه کنید، که سپس سیستم آن را در تصویر کوچک مناسب پردازش می‌کند و سوابق عکس را نمایش می‌دهد.

تماس با بازخورد استفاده

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

ارائه دهنده تقویم

APIهای تقویم جدید به شما امکان می‌دهند تقویم‌ها، رویدادها، شرکت‌کنندگان، یادآوری‌ها و هشدارها را بخوانید، اضافه کنید، تغییر دهید و حذف کنید که در ارائه‌دهنده تقویم ذخیره می‌شوند.

انواع برنامه ها و ویجت ها می توانند از این API ها برای خواندن و تغییر رویدادهای تقویم استفاده کنند. با این حال، برخی از قانع‌کننده‌ترین موارد استفاده، آداپتورهای همگام‌سازی هستند که تقویم کاربر را از سرویس‌های تقویم دیگر با ارائه‌دهنده تقویم همگام‌سازی می‌کنند تا یک مکان واحد برای همه رویدادهای کاربر ارائه دهند. برای مثال، رویدادهای Google Calendar با ارائه‌دهنده تقویم توسط آداپتور Google Calendar Sync همگام‌سازی می‌شوند و به این رویدادها اجازه می‌دهند با برنامه تقویم داخلی Android مشاهده شوند.

مدل داده برای تقویم ها و اطلاعات مربوط به رویداد در Calendar Provider توسط CalendarContract تعریف شده است. تمام داده های تقویم کاربر در تعدادی جداول تعریف شده توسط زیر کلاس های مختلف CalendarContract ذخیره می شود:

  • جدول CalendarContract.Calendars اطلاعات مربوط به تقویم را در خود نگه می دارد. هر ردیف در این جدول حاوی جزئیات مربوط به یک تقویم است، مانند نام، رنگ، اطلاعات همگام سازی و غیره.
  • جدول CalendarContract.Events اطلاعات مربوط به رویداد را در خود دارد. هر ردیف در این جدول حاوی اطلاعات مربوط به یک رویداد است، مانند عنوان رویداد، مکان، زمان شروع، زمان پایان و غیره. این رویداد می تواند یک بار رخ دهد یا چندین بار تکرار شود. شرکت کنندگان، یادآورها و ویژگی های توسعه یافته در جداول جداگانه ذخیره می شوند و از _ID رویداد برای پیوند دادن آنها با رویداد استفاده می کنند.
  • جدول CalendarContract.Instances زمان شروع و پایان را برای وقوع یک رویداد نگه می دارد. هر ردیف در این جدول نشان دهنده یک رخداد واحد است. برای رویدادهای یک بار، یک نگاشت یک به یک از نمونه ها به رویدادها وجود دارد. برای رویدادهای تکرار شونده، ردیف‌های متعددی به‌طور خودکار تولید می‌شوند تا با چندین رخداد آن رویداد مطابقت داشته باشند.
  • جدول CalendarContract.Attendees اطلاعات شرکت کنندگان یا مهمانان رویداد را نگه می دارد. هر ردیف نشان دهنده یک مهمان از یک رویداد است. نوع مهمان شخص و پاسخ شخص به رویداد را مشخص می کند.
  • جدول CalendarContract.Reminders داده های هشدار/اعلان را نگه می دارد. هر ردیف نشان دهنده یک هشدار واحد برای یک رویداد است. یک رویداد می تواند چندین یادآور داشته باشد. تعداد یادآورها در هر رویداد در MAX_REMINDERS مشخص شده است که توسط آداپتور همگام‌سازی که متعلق به تقویم داده شده است تنظیم می‌شود. یادآوری‌ها به تعداد دقیقه قبل از برنامه‌ریزی رویداد مشخص می‌شوند و یک روش هشدار مانند استفاده از هشدار، ایمیل یا پیامک برای یادآوری کاربر را مشخص می‌کنند.
  • جدول CalendarContract.ExtendedProperties فیلدهای داده مبهم مورد استفاده توسط آداپتور همگام سازی را در خود نگه می دارد. ارائه‌دهنده هیچ اقدامی با موارد موجود در این جدول انجام نمی‌دهد، مگر اینکه در صورت حذف رویدادهای مرتبط، آنها را حذف کند.

برای دسترسی به داده‌های تقویم کاربر با ارائه‌دهنده تقویم، برنامه شما باید مجوز READ_CALENDAR (برای دسترسی خواندن) و WRITE_CALENDAR (برای دسترسی نوشتن) را درخواست کند.

قصد رویداد

اگر تنها کاری که می‌خواهید انجام دهید اضافه کردن یک رویداد به تقویم کاربر است، می‌توانید از یک هدف ACTION_INSERT با داده‌های تعریف‌شده توسط Events.CONTENT_URI برای شروع فعالیتی در برنامه Calendar که رویدادهای جدید ایجاد می‌کند، استفاده کنید. استفاده از intent نیازی به مجوز ندارد و می توانید جزئیات رویداد را با موارد اضافی زیر مشخص کنید:

ارائه دهنده پست صوتی

ارائه‌دهنده پست صوتی جدید به برنامه‌ها اجازه می‌دهد تا پست‌های صوتی را به دستگاه اضافه کنند تا همه پست‌های صوتی کاربر را در یک نمایش تصویری ارائه کنند. به عنوان مثال، ممکن است یک کاربر چندین منبع پست صوتی مانند یکی از ارائه دهنده خدمات تلفن و دیگران از VoIP یا سایر خدمات صوتی جایگزین داشته باشد. این برنامه‌ها می‌توانند از APIهای ارائه‌دهنده پست صوتی برای افزودن پست‌های صوتی خود به دستگاه استفاده کنند. سپس برنامه داخلی تلفن تمام پست‌های صوتی را در یک نمایش یکپارچه به کاربر ارائه می‌کند. اگرچه برنامه تلفن سیستم تنها برنامه‌ای است که می‌تواند همه پست‌های صوتی را بخواند، اما هر برنامه‌ای که پست‌های صوتی را ارائه می‌کند می‌تواند پست‌هایی را که به سیستم اضافه کرده است بخواند (اما نمی‌تواند پست‌های صوتی را از سرویس‌های دیگر بخواند).

از آنجایی که API ها در حال حاضر به برنامه های شخص ثالث اجازه نمی دهند همه پیام های صوتی سیستم را بخوانند، تنها برنامه های شخص ثالثی که باید از API های پست صوتی استفاده کنند آنهایی هستند که پست صوتی را برای تحویل به کاربر دارند.

کلاس VoicemailContract ارائه دهنده محتوا را برای Voicemail Provder تعریف می کند. زیر کلاس های VoicemailContract.Voicemails و VoicemailContract.Status جداولی را ارائه می دهند که در آنها برنامه ها می توانند داده های پست صوتی را برای ذخیره سازی در دستگاه وارد کنند. برای مثالی از یک برنامه ارائه‌دهنده پست صوتی، نسخه آزمایشی ارائه‌دهنده پست صوتی را ببینید.

چند رسانه ای

Android 4.0 چندین API جدید برای برنامه‌هایی اضافه می‌کند که با رسانه‌هایی مانند عکس، ویدیو و موسیقی تعامل دارند.

جلوه های رسانه ای

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

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

  1. آنها باید به یک تصویر بافت GL_TEXTURE_2D متصل شوند
  2. آنها باید حداقل یک سطح mipmap داشته باشند

یک شیء Effect یک جلوه رسانه واحد را تعریف می کند که می توانید آن را روی یک قاب تصویر اعمال کنید. گردش کار اصلی برای ایجاد یک Effect عبارت است از:

  1. EffectContext.createWithCurrentGlContext() از متن OpenGL ES 2.0 خود فراخوانی کنید.
  2. از EffectContext برگشتی برای فراخوانی EffectContext.getFactory() استفاده کنید که نمونه ای از EffectFactory را برمی گرداند.
  3. createEffect() فراخوانی کنید و یک نام افکت از @link android.media.effect.EffectFactory} ارسال کنید، مانند EFFECT_FISHEYE یا EFFECT_VIGNETTE .

شما می توانید پارامترهای یک افکت را با فراخوانی setParameter() و ارسال نام پارامتر و مقدار پارامتر تنظیم کنید. هر نوع افکت پارامترهای مختلفی را می پذیرد که با نام افکت مستند شده است. برای مثال، EFFECT_FISHEYE یک پارامتر برای scale اعوجاج دارد.

برای اعمال افکت روی یک بافت، apply() را روی Effect فراخوانی کنید و بافت ورودی، عرض و ارتفاع و بافت خروجی را وارد کنید. بافت ورودی باید به یک تصویر بافت GL_TEXTURE_2D متصل شود (معمولاً با فراخوانی تابع glTexImage2D() انجام می شود. ممکن است چندین سطح mipmap ارائه دهید. اگر بافت خروجی به یک تصویر بافت متصل نشده باشد، به طور خودکار توسط افکت به عنوان یک GL_TEXTURE_2D و با یک سطح mipmap (0) که اندازه آن همان ورودی است، محدود می شود.

تمامی افکت های فهرست شده در EffectFactory تضمین می شوند که پشتیبانی شوند. با این حال، برخی از افکت‌های اضافی موجود از کتابخانه‌های خارجی توسط همه دستگاه‌ها پشتیبانی نمی‌شوند، بنابراین ابتدا باید با فراخوانی isEffectSupported() بررسی کنید که آیا افکت مورد نظر از کتابخانه خارجی پشتیبانی می‌شود یا خیر.

مشتری کنترل از راه دور

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

برای فعال کردن کلاینت‌های کنترل از راه دور برای پخش‌کننده رسانه خود، یک RemoteControlClient را با سازنده‌اش نمونه‌سازی کنید و به آن یک PendingIntent ارسال کنید که ACTION_MEDIA_BUTTON را پخش می‌کند. هدف همچنین باید مؤلفه BroadcastReceiver صریح را در برنامه شما که رویداد ACTION_MEDIA_BUTTON را مدیریت می‌کند، اعلام کند.

برای اعلام اینکه پخش کننده شما می تواند کدام ورودی های کنترل رسانه را مدیریت کند، باید setTransportControlFlags() را در RemoteControlClient خود فراخوانی کنید و مجموعه ای از پرچم های FLAG_KEY_MEDIA_* مانند FLAG_KEY_MEDIA_PREVIOUS و FLAG_KEY_MEDIA_NEXT را ارسال کنید.

سپس باید RemoteControlClient خود را با ارسال آن به MediaManager.registerRemoteControlClient() ثبت کنید. پس از ثبت نام، گیرنده پخشی که هنگام نصب RemoteControlClient اعلام کردید، با فشار دادن یک دکمه از کنترل از راه دور، رویدادهای ACTION_MEDIA_BUTTON را دریافت می کند. هدفی که دریافت می‌کنید شامل KeyEvent برای کلید رسانه فشار داده شده است، که می‌توانید با getParcelableExtra(Intent.EXTRA_KEY_EVENT) از intent بازیابی کنید.

برای نمایش اطلاعات روی کنترل از راه دور در مورد رسانه در حال پخش، editMetaData() را فراخوانی کنید و ابرداده را به RemoteControlClient.MetadataEditor برگشتی اضافه کنید. شما می توانید یک بیت مپ برای آثار هنری رسانه، اطلاعات عددی مانند زمان سپری شده و اطلاعات متنی مانند عنوان آهنگ ارائه دهید. برای اطلاعات در مورد کلیدهای موجود، پرچم‌های METADATA_KEY_* را در MediaMetadataRetriever ببینید.

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

پخش کننده رسانه

  • پخش جریانی رسانه آنلاین از MediaPlayer اکنون به مجوز INTERNET نیاز دارد. اگر MediaPlayer برای پخش محتوا از اینترنت استفاده می‌کنید، حتماً مجوز INTERNET را به مانیفست خود اضافه کنید، در غیر این صورت پخش رسانه شما با Android 4.0 کار نخواهد کرد.
  • setSurface() به شما امکان می دهد Surface به عنوان سینک ویدیو تعریف کنید.
  • setDataSource() به شما امکان می دهد هدرهای HTTP اضافی را همراه با درخواست خود ارسال کنید، که می تواند برای پخش زنده HTTP(S) مفید باشد.
  • پخش زنده HTTP(S) اکنون به کوکی های HTTP در تمام درخواست ها احترام می گذارد

انواع رسانه ها

Android 4.0 پشتیبانی از موارد زیر را اضافه می کند:

  • پروتکل پخش زنده HTTP/HTTPS نسخه 3
  • رمزگذاری صوتی خام ADTS AAC
  • تصاویر WEBP
  • ویدیوی ماتروسکا

برای اطلاعات بیشتر، فرمت‌های رسانه پشتیبانی شده را ببینید.

دوربین

کلاس Camera اکنون شامل APIهایی برای تشخیص چهره و کنترل مناطق فوکوس و نورسنجی است.

تشخیص چهره

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

برای تشخیص چهره در برنامه دوربین خود، باید با فراخوانی setFaceDetectionListener() یک Camera.FaceDetectionListener ثبت کنید. سپس می توانید سطح دوربین خود را راه اندازی کنید و با فراخوانی startFaceDetection() شروع به شناسایی چهره کنید.

هنگامی که سیستم یک یا چند چهره را در صحنه دوربین تشخیص می‌دهد، در اجرای Camera.FaceDetectionListener ، از جمله آرایه‌ای از اشیاء Camera.Face ، callback onFaceDetection() را فراخوانی می‌کند.

نمونه ای از کلاس Camera.Face اطلاعات مختلفی در مورد چهره شناسایی شده ارائه می دهد، از جمله:

  • یک Rect که محدوده های صورت را نسبت به میدان دید فعلی دوربین مشخص می کند
  • یک عدد صحیح بین 1 تا 100 که نشان می دهد سیستم چقدر مطمئن است که جسم یک چهره انسان است.
  • یک شناسه منحصر به فرد برای ردیابی چند چهره
  • چندین اشیاء Point که محل قرارگیری چشم ها و دهان را نشان می دهد

توجه: تشخیص چهره ممکن است در برخی از دستگاه ها پشتیبانی نشود، بنابراین باید با فراخوانی getMaxNumDetectedFaces() بررسی کنید و مطمئن شوید که مقدار بازگشتی بزرگتر از صفر است. همچنین، برخی از دستگاه‌ها ممکن است از شناسایی چشم‌ها و دهان پشتیبانی نکنند، در این صورت، آن فیلدها در شی Camera.Face خالی خواهند بود.

مناطق فوکوس و اندازه گیری

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

قبل از تنظیم یک ناحیه فوکوس یا ناحیه اندازه گیری، ابتدا باید getMaxNumFocusAreas() یا getMaxNumMeteringAreas() را فراخوانی کنید. اگر اینها صفر را برگرداند، دستگاه از ویژگی مربوطه پشتیبانی نمی کند.

برای تعیین فوکوس یا مناطق اندازه گیری مورد استفاده، به سادگی setFocusAreas() یا setMeteringAreas() را فراخوانی کنید. هر کدام List از اشیاء Camera.Area را می گیرند که مناطقی را که باید برای فوکوس یا اندازه گیری در نظر گرفته شوند را نشان می دهد. برای مثال، می‌توانید ویژگی‌ای را پیاده‌سازی کنید که به کاربر اجازه می‌دهد با لمس ناحیه‌ای از پیش‌نمایش، ناحیه فوکوس را تنظیم کند، سپس آن را به یک شی Camera.Area ترجمه کنید و از دوربین درخواست کنید که روی آن ناحیه از صحنه فوکوس کند. با تغییر صحنه در آن ناحیه، فوکوس یا نوردهی در آن ناحیه به طور مداوم به روز می شود.

فوکوس خودکار مداوم برای عکس ها

اکنون می توانید فوکوس خودکار مداوم (CAF) را هنگام عکس گرفتن فعال کنید. برای فعال کردن CAF در برنامه دوربین خود، FOCUS_MODE_CONTINUOUS_PICTURE را به setFocusMode() منتقل کنید. وقتی برای گرفتن عکس آماده شدید، با autoFocus() تماس بگیرید. Camera.AutoFocusCallback شما فوراً یک تماس پاسخ دریافت می کند تا نشان دهد آیا فوکوس به دست آمده است یا خیر. برای از سرگیری CAF پس از دریافت پاسخ تماس، باید cancelAutoFocus() را فراخوانی کنید.

توجه: با استفاده از FOCUS_MODE_CONTINUOUS_VIDEO که در سطح 9 API اضافه شده است، فوکوس خودکار پیوسته هنگام ضبط ویدیو نیز پشتیبانی می‌شود.

سایر ویژگی های دوربین

  • در حین ضبط ویدیو، اکنون می توانید takePicture() را فراخوانی کنید تا عکسی را بدون وقفه در جلسه ویدیو ذخیره کنید. قبل از انجام این کار، باید isVideoSnapshotSupported() را فراخوانی کنید تا مطمئن شوید که سخت افزار آن را پشتیبانی می کند.
  • اکنون می توانید نوردهی خودکار و تعادل رنگ سفید را با setAutoExposureLock() و setAutoWhiteBalanceLock() قفل کنید تا از تغییر این ویژگی ها جلوگیری کنید.
  • اکنون می توانید در حالی که پیش نمایش دوربین در حال اجرا است setDisplayOrientation() فراخوانی کنید. قبلاً فقط قبل از شروع پیش‌نمایش می‌توانستید با آن تماس بگیرید، اما اکنون می‌توانید جهت را در هر زمانی تغییر دهید.

اهداف پخش دوربین

  • Camera.ACTION_NEW_PICTURE : این نشان می دهد که کاربر عکس جدیدی گرفته است. برنامه داخلی دوربین این پخش را پس از گرفتن عکس فراخوانی می کند و برنامه های دوربین شخص ثالث نیز باید این هدف را پس از گرفتن عکس پخش کنند.
  • Camera.ACTION_NEW_VIDEO : این نشان می دهد که کاربر یک ویدیوی جدید گرفته است. برنامه دوربین داخلی این پخش را پس از ضبط ویدیو فراخوانی می کند و برنامه های دوربین شخص ثالث نیز باید این هدف را پس از ضبط ویدیو پخش کنند.

پرتو Android (NDEF Push با NFC)

Android Beam یک ویژگی جدید NFC است که به شما امکان می‌دهد پیام‌های NDEF را از یک دستگاه به دستگاه دیگر ارسال کنید (فرآیندی که به نام NDEF Push نیز شناخته می‌شود). انتقال داده زمانی آغاز می‌شود که دو دستگاه مجهز به Android که از Android Beam پشتیبانی می‌کنند در مجاورت یکدیگر باشند. (حدود 4 سانتی متر)، معمولاً با لمس کردن پشت آنها، داده های داخل پیام NDEF می تواند حاوی هر داده ای باشد که می خواهید بین دستگاه ها به اشتراک بگذارید .

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

  • یک NdefMessage برای فشار دادن در حین فعالیت تعریف کنید:

    در هر زمان با setNdefPushMessage() تماس بگیرید تا پیامی را که می خواهید ارسال کنید تنظیم کنید. به عنوان مثال، ممکن است این متد را فراخوانی کرده و NdefMessage خود را در طول متد onCreate() فعالیت خود ارسال کنید. سپس، هر زمان که Android Beam با دستگاه دیگری در حالی که فعالیت در پیش زمینه است، فعال شود، سیستم NdefMessage به دستگاه دیگر ارسال می کند.

  • NdefMessage برای فشار دادن در زمان شروع Android Beam تعریف کنید:

    NfcAdapter.CreateNdefMessageCallback را پیاده سازی کنید، که در آن پیاده سازی متد createNdefMessage() NdefMessage که می خواهید ارسال کنید برمی گرداند. سپس اجرای NfcAdapter.CreateNdefMessageCallback را به setNdefPushMessageCallback() منتقل کنید.

    در این حالت، زمانی که Android Beam با دستگاه دیگری فعال می‌شود، در حالی که فعالیت شما در پیش‌زمینه است، سیستم createNdefMessage() را فراخوانی می‌کند تا NdefMessage که می‌خواهید ارسال کنید، بازیابی کند. این به شما امکان می‌دهد تا NdefMessage به گونه‌ای تعریف کنید که فقط پس از شروع Android Beam ارائه شود، در صورتی که محتوای پیام ممکن است در طول عمر فعالیت متفاوت باشد.

در صورتی که می‌خواهید پس از اینکه سیستم با موفقیت پیام NDEF شما را به دستگاه دیگر تحویل داد، کد خاصی را اجرا کنید، می‌توانید NfcAdapter.OnNdefPushCompleteCallback را پیاده‌سازی کنید و آن را با setNdefPushCompleteCallback() تنظیم کنید. پس از تحویل پیام، سیستم onNdefPushComplete() را فراخوانی می کند.

در دستگاه دریافت کننده، سیستم پیام های NDEF Push را به روشی مشابه با برچسب های NFC معمولی ارسال می کند. سیستم یک intent را با عمل ACTION_NDEF_DISCOVERED برای شروع یک فعالیت فراخوانی می کند، با یک URL یا یک نوع MIME که مطابق با اولین NdefRecord در NdefMessage تنظیم شده است. برای فعالیتی که می‌خواهید پاسخ دهید، می‌توانید فیلترهای هدف را برای نشانی‌های وب یا انواع MIME اعلام کنید که برنامه شما به آن‌ها اهمیت می‌دهد. برای اطلاعات بیشتر در مورد ارسال برچسب، راهنمای توسعه NFC را ببینید.

اگر می‌خواهید NdefMessage شما یک URI داشته باشد، اکنون می‌توانید از روش راحتی createUri برای ساختن یک NdefRecord جدید بر اساس یک رشته یا یک شی Uri استفاده کنید. اگر URI قالب خاصی است که می‌خواهید برنامه شما در طول یک رویداد Android Beam نیز دریافت کند، باید با استفاده از طرح URI یک فیلتر هدف برای فعالیت خود ایجاد کنید تا پیام NDEF ورودی را دریافت کنید.

همچنین باید با NdefMessage خود یک «رکورد برنامه Android» ارسال کنید تا تضمین کنید که برنامه شما پیام NDEF دریافتی را مدیریت می‌کند، حتی اگر برنامه‌های دیگر برای اقدام مشابه فیلتر شوند. می‌توانید با فراخوانی createApplicationRecord() یک رکورد برنامه Android ایجاد کنید. ارسال آن به نام بسته برنامه شما هنگامی که دستگاه دیگر پیام NDEF را با رکورد برنامه دریافت می کند و چندین برنامه حاوی فعالیت هایی هستند که هدف مشخص شده را مدیریت می کنند، سیستم همیشه پیام را به فعالیت در برنامه شما تحویل می دهد (بر اساس سابقه برنامه منطبق). اگر دستگاه مورد نظر در حال حاضر برنامه شما را نصب نکرده باشد، سیستم از رکورد برنامه اندروید برای راه اندازی Google Play استفاده می کند و کاربر را برای نصب به برنامه می برد.

اگر برنامه شما از NFC API برای انجام پیام‌رسانی NDEF Push استفاده نمی‌کند، Android یک رفتار پیش‌فرض ارائه می‌کند: وقتی برنامه شما در یک دستگاه در پیش‌زمینه است و Android Beam با دستگاه دیگری که دارای Android است فراخوانی می‌شود، دستگاه دیگر یک پیام دریافت می‌کند. پیام NDEF با یک رکورد برنامه Android که برنامه شما را شناسایی می کند. اگر دستگاه دریافت کننده برنامه را نصب کرده باشد، سیستم آن را راه اندازی می کند. اگر نصب نشده باشد، Google Play باز می شود و کاربر را به برنامه شما می برد تا آن را نصب کند.

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

Wi-Fi P2P

Android اکنون از اتصالات Wi-Fi peer-to-peer (P2P) بین دستگاه‌های مجهز به Android و سایر انواع دستگاه (مطابق با برنامه صدور گواهینامه Wi-Fi Direct™ اتحاد Wi-Fi) بدون نقطه اتصال یا اینترنت پشتیبانی می‌کند. چارچوب Android مجموعه‌ای از APIهای Wi-Fi P2P را ارائه می‌کند که به شما امکان می‌دهد وقتی هر دستگاه از Wi-Fi P2P پشتیبانی می‌کند، دستگاه‌های دیگر را کشف کرده و به آن متصل شوید، سپس از طریق یک اتصال سریع در فواصل بسیار طولانی‌تر از اتصال بلوتوث ارتباط برقرار کنید.

یک بسته جدید، android.net.wifi.p2p ، شامل تمام APIها برای انجام اتصالات همتا به همتا با Wi-Fi است. کلاس اولیه ای که باید با آن کار کنید WifiP2pManager است که می توانید با تماس گرفتن با getSystemService(WIFI_P2P_SERVICE) را بدست آورید. WifiP2pManager شامل APIهایی است که به شما امکان می دهد:

  • برنامه خود را برای اتصالات P2P با فراخوانی initialize() راه اندازی کنید.
  • با تماس با discoverPeers() دستگاه های اطراف را کشف کنید
  • با فراخوانی connect() یک اتصال P2P را شروع کنید
  • و بیشتر

چندین رابط و کلاس دیگر نیز لازم است، مانند:

  • رابط WifiP2pManager.ActionListener به شما امکان می دهد زمانی که عملیاتی مانند کشف همتایان یا اتصال به آنها با موفقیت یا شکست مواجه می شود، تماس های برگشتی دریافت کنید.
  • رابط WifiP2pManager.PeerListListener به شما امکان می دهد اطلاعاتی در مورد همتایان کشف شده دریافت کنید. پاسخ تماس یک WifiP2pDeviceList ارائه می‌کند که از آن می‌توانید یک شی WifiP2pDevice را برای هر دستگاه در محدوده بازیابی کنید و اطلاعاتی مانند نام دستگاه، آدرس، نوع دستگاه، پیکربندی‌های WPS که دستگاه پشتیبانی می‌کند و موارد دیگر را دریافت کنید.
  • رابط WifiP2pManager.GroupInfoListener به شما امکان می دهد اطلاعاتی درباره یک گروه P2P دریافت کنید. پاسخ تماس یک شی WifiP2pGroup را ارائه می دهد که اطلاعات گروهی مانند مالک، نام شبکه و عبارت عبور را ارائه می دهد.
  • رابط WifiP2pManager.ConnectionInfoListener به شما امکان می دهد اطلاعات مربوط به اتصال فعلی را دریافت کنید. پاسخ تماس یک شی WifiP2pInfo را ارائه می دهد که دارای اطلاعاتی مانند تشکیل گروه و مالک گروه است.

برای استفاده از Wi-Fi P2P API، برنامه شما باید مجوزهای کاربر زیر را درخواست کند:

  • ACCESS_WIFI_STATE
  • CHANGE_WIFI_STATE
  • INTERNET (اگرچه برنامه شما از نظر فنی به اینترنت متصل نمی شود، اما برقراری ارتباط با همتایان Wi-Fi P2P با سوکت های جاوا استاندارد نیاز به مجوز اینترنت دارد).

سیستم Android همچنین چندین عمل مختلف را در طول برخی رویدادهای Wi-Fi P2P پخش می کند:

برای اطلاعات بیشتر به مستندات WifiP2pManager مراجعه کنید. همچنین به برنامه نمونه آزمایشی Wi-Fi P2P نگاه کنید.

دستگاه های سلامت بلوتوث

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

مشابه هدست‌های معمولی و دستگاه‌های نمایه A2DP، باید getProfileProxy() با یک BluetoothProfile.ServiceListener و نوع پروفایل HEALTH برای برقراری ارتباط با شی پراکسی پروفایل فراخوانی کنید.

هنگامی که پروکسی Health Profile (شیء BluetoothHealth ) را به دست آوردید، اتصال و برقراری ارتباط با دستگاه های بهداشتی جفت شده شامل کلاس های بلوتوث جدید زیر است:

  • BluetoothHealthCallback : شما باید این کلاس را گسترش دهید و روش‌های پاسخ به تماس را برای دریافت به‌روزرسانی‌ها در مورد تغییرات در وضعیت ثبت برنامه و وضعیت کانال بلوتوث پیاده‌سازی کنید.
  • BluetoothHealthAppConfiguration : در طول تماس‌های برگشتی به BluetoothHealthCallback خود، نمونه‌ای از این شی را دریافت می‌کنید که اطلاعات پیکربندی مربوط به دستگاه سلامت بلوتوث موجود را ارائه می‌دهد، که باید از آن برای انجام عملیات‌های مختلفی مانند شروع و پایان دادن به اتصالات با APIهای BluetoothHealth استفاده کنید.

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

قابلیت دسترسی

Android 4.0 با حالت جدید کاوش با لمس و APIهای توسعه یافته که به شما امکان می دهد اطلاعات بیشتری در مورد مشاهده محتوا یا توسعه خدمات دسترسی پیشرفته ارائه دهید، دسترسی را برای کاربران دارای اختلال بینایی بهبود می بخشد.

حالت کاوش با لمس

کاربرانی که از دست دادن بینایی دارند اکنون می‌توانند با لمس کردن و کشیدن انگشت روی صفحه برای شنیدن توضیحات صوتی محتوا، صفحه را کاوش کنند. از آنجایی که حالت کاوش با لمس مانند یک مکان نما مجازی عمل می کند، به خوانندگان صفحه اجازه می دهد تا متن توصیفی را به همان روشی که صفحه خوان ها هنگام حرکت کاربر با d-pad یا trackball می توانند با خواندن اطلاعات ارائه شده توسط android:contentDescription شناسایی کنند. و setContentDescription() بر روی یک رویداد شبیه سازی شده "hover". بنابراین، در نظر بگیرید که این یک یادآوری است که باید متن توصیفی برای نماهای برنامه خود ارائه دهید، به خصوص برای ImageButton ، EditText ، ImageView و سایر ویجت هایی که ممکن است به طور طبیعی حاوی متن توصیفی نباشند.

قابلیت دسترسی برای نماها

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

مهم است که ابتدا توجه داشته باشید که رفتار متد sendAccessibilityEvent() در اندروید 4.0 تغییر کرده است. همانند نسخه قبلی اندروید، زمانی که کاربر سرویس‌های دسترسی را در دستگاه فعال می‌کند و یک رویداد ورودی مانند کلیک یا شناور رخ می‌دهد، نمای مربوطه با فراخوانی به sendAccessibilityEvent() اطلاع داده می‌شود. قبلاً، اجرای sendAccessibilityEvent() یک AccessibilityEvent را مقداردهی اولیه می‌کرد و آن را به AccessibilityManager ارسال می‌کرد. رفتار جدید شامل برخی از روش‌های برگشت تماس اضافی است که به view و والدین آن اجازه می‌دهد اطلاعات متنی بیشتری را به رویداد اضافه کنند:

  1. هنگامی که فراخوانی می شود، متدهای sendAccessibilityEvent() و sendAccessibilityEventUnchecked() به onInitializeAccessibilityEvent() موکول می شوند.

    پیاده‌سازی‌های سفارشی View ممکن است بخواهند onInitializeAccessibilityEvent() برای پیوست کردن اطلاعات دسترسی اضافی به AccessibilityEvent پیاده‌سازی کنند، اما باید اجرای فوق‌العاده را نیز فراخوانی کنند تا اطلاعات پیش‌فرض مانند توضیحات محتوای استاندارد، فهرست آیتم و موارد دیگر را ارائه کنند. با این حال، شما نباید محتوای متنی اضافی را در این پاسخ تماس اضافه کنید - این در مرحله بعدی اتفاق می افتد.

  2. پس از مقداردهی اولیه، اگر رویداد یکی از چندین نوع باشد که باید با اطلاعات متنی پر شود، view سپس یک فراخوانی به dispatchPopulateAccessibilityEvent() دریافت می کند که به پاسخ تماس onPopulateAccessibilityEvent() موکول می شود.

    پیاده‌سازی‌های سفارشی View معمولاً باید onPopulateAccessibilityEvent() را پیاده‌سازی کنند تا در صورتی که متن android:contentDescription موجود نباشد یا کافی نباشد، محتوای متنی اضافی به AccessibilityEvent اضافه کند. برای افزودن توضیحات متنی بیشتر به AccessibilityEvent ، getText() را فراخوانی کنید. add() .

  3. در این مرحله، View با فراخوانی requestSendAccessibilityEvent() در نمای والد، رویداد را به سلسله مراتب view منتقل می کند. سپس هر نمای والدین این فرصت را دارد که با افزودن یک AccessibilityRecord ، اطلاعات دسترسی را افزایش دهد ، تا اینکه در نهایت به نمای ریشه نرسد ، که این رویداد را با sendAccessibilityEvent() به AccessibilityManager ارسال می کند.

علاوه بر روشهای جدید فوق ، که در هنگام گسترش کلاس View مفید هستند ، می توانید با گسترش AccessibilityDelegate و تنظیم آن در نمای با setAccessibilityDelegate() این تماس های تماس را نیز در هر View رهگیری کنید. هنگامی که شما این کار را انجام می دهید ، هر روش دسترسی در نمای تماس با روش مربوطه در نماینده را نشان می دهد. به عنوان مثال ، هنگامی که این نمایش فراخوانی به onPopulateAccessibilityEvent() دریافت می کند ، آن را در View.AccessibilityDelegate به همان روش منتقل می کند. هر روشی که توسط نماینده اداره نشود ، برای رفتار پیش فرض به نمای درست داده می شود. این به شما امکان می دهد فقط روشهای لازم برای هر نمای معین را بدون گسترش کلاس View نادیده بگیرید.

اگر می خواهید قبل از 4.0 سازگاری با نسخه های Android را حفظ کنید ، ضمن اینکه از API های دسترسی جدید نیز پشتیبانی می کنید ، می توانید با استفاده از مجموعه ای از کلاسهای ابزار که ارائه می دهند ، با آخرین نسخه کتابخانه پشتیبانی V4 (در بسته سازگاری ، R4 ) این کار را انجام دهید. API های دسترسی جدید در یک طراحی سازگار با عقب.

خدمات دسترسی

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

اگر در حال تهیه یک سرویس دسترسی (مانند خواننده صفحه نمایش) هستید ، می توانید با روش زیر به اطلاعات محتوای اضافی و سلسله مراتب View View دسترسی پیدا کنید:

  1. پس از دریافت یک AccessibilityEvent از یک برنامه ، برای بازیابی یک AccessibilityRecord خاص (ممکن است چندین سوابق به این رویداد وجود داشته باشد) با AccessibilityEvent.getRecord() تماس بگیرید.
  2. از هر دو AccessibilityEvent یا یک AccessibilityRecord فردی ، می توانید برای بازیابی یک شیء AccessibilityNodeInfo getSource() تماس بگیرید.

    AccessibilityNodeInfo یک گره واحد از محتوای پنجره را در فرمی نشان می دهد که به شما امکان می دهد اطلاعات دسترسی را در مورد آن گره پرس و جو کنید. شیء AccessibilityNodeInfo که از AccessibilityEvent منبع رویداد را توصیف می کند ، در حالی که منبع از یک AccessibilityRecord سلف منبع رویداد را توصیف می کند.

  3. با AccessibilityNodeInfo ، می توانید اطلاعات مربوط به آن را پرس و جو کنید ، با getParent() یا getChild() تماس بگیرید تا سلسله مراتب نمای را طی کنید و حتی نماهای کودک را به گره اضافه کنید.

برای اینکه برنامه شما بتواند خود را به عنوان یک سرویس دسترسی به سیستم منتشر کند ، باید یک فایل پیکربندی XML را که مربوط به AccessibilityServiceInfo است ، اعلام کند. برای کسب اطلاعات بیشتر در مورد ایجاد یک سرویس دسترسی ، برای کسب اطلاعات در مورد پیکربندی XML ، AccessibilityService و SERVICE_META_DATA مراجعه کنید.

سایر API های دسترسی

اگر به حالت دسترسی دستگاه علاقه دارید ، AccessibilityManager دارای API های جدید مانند:

خدمات هجی چک

یک چارچوب جدید طلسم Checker به برنامه ها اجازه می دهد تا چک های طلسم را به روشی شبیه به چارچوب روش ورودی (برای IME) ایجاد کنند. برای ایجاد یک چکر طلسم جدید ، شما باید خدماتی را اجرا کنید که SpellCheckerService را گسترش داده و کلاس SpellCheckerService.Session را گسترش دهید تا پیشنهادات املایی را بر اساس متن ارائه شده توسط روش های پاسخ به رابط ارائه دهید. در روش های پاسخ به تماس SpellCheckerService.Session ، شما باید پیشنهادات املایی را به عنوان اشیاء پیشنهادی به عنوان SuggestionsInfo برگردانید.

برنامه های کاربردی با یک سرویس چرچر طلسم باید طبق نیاز سرویس ، اجازه BIND_TEXT_SERVICE اعلام کنند. این سرویس همچنین باید یک فیلتر قصد را با <action android:name="android.service.textservice.SpellCheckerService" /> به عنوان عمل هدف و باید شامل یک عنصر <meta-data> باشد که اطلاعات پیکربندی را برای سحر و جادو نشان می دهد.

به عنوان مثال به برنامه سرویس خدمات SPELL CHECHER و نمونه برنامه Client Checker Sold Somple مراجعه کنید.

موتورهای متن به گفتار

ANAPI های Android به گفتار (TTS) Android به طور قابل توجهی گسترش یافته است تا برنامه ها بتوانند موتورهای TTS سفارشی را به راحتی پیاده سازی کنند ، در حالی که برنامه هایی که می خواهند از موتور TTS استفاده کنند ، دارای یک API جدید برای انتخاب موتور هستند.

با استفاده از موتورهای متن به گفتار

در نسخه های قبلی Android ، می توانید از کلاس TextToSpeech برای انجام عملیات متن به گفتار (TTS) با استفاده از موتور TTS ارائه شده توسط سیستم استفاده کنید یا یک موتور سفارشی را با استفاده از setEngineByPackageName() تنظیم کنید. در Android 4.0 ، روش setEngineByPackageName() کاهش یافته است و اکنون می توانید موتور را برای استفاده با یک سازنده جدید TextToSpeech که نام بسته موتور TTS را می پذیرد ، مشخص کنید.

همچنین می توانید موتورهای TTS موجود را با getEngines() پرس و جو کنید. این روش لیستی از اشیاء TextToSpeech.EngineInfo را برمی گرداند ، که شامل داده های متا مانند نماد ، برچسب و نام بسته موتور است.

ساخت موتورهای متنی به گفتار

پیش از این ، موتورهای سفارشی نیاز داشتند که موتور با استفاده از یک پرونده هدر بومی بدون مدارک ساخته شود. در Android 4.0 ، مجموعه کاملی از API های چارچوب برای ساخت موتورهای TTS وجود دارد.

تنظیم اساسی نیاز به اجرای TextToSpeechService دارد که به هدف INTENT_ACTION_TTS_SERVICE پاسخ می دهد. کار اصلی برای یک موتور TTS در طی تماس با onSynthesizeText() در یک سرویس که TextToSpeechService را گسترش می دهد ، اتفاق می افتد. سیستم این روش را دو شی ارائه می دهد:

  • SynthesisRequest : این شامل داده های مختلفی از جمله متن برای سنتز ، محلی ، میزان گفتار و زمین صوتی است.
  • SynthesisCallback : این رابط کاربری است که موتور TTS شما داده های گفتار حاصل را به عنوان صوتی پخش می کند. ابتدا موتور باید با start() تماس بگیرد تا نشان دهد که موتور آماده تحویل صوتی است ، سپس با audioAvailable() تماس می گیرد و داده های صوتی را در یک بافر بایت منتقل می کند. هنگامی که موتور شما تمام صدا را از طریق بافر منتقل کرد ، تماس done() .

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

برای مثال موتور TTS با استفاده از API های جدید ، به برنامه نمونه نمونه موتور گفتار مراجعه کنید.

استفاده از شبکه

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

اگر برنامه شما معاملات شبکه زیادی را انجام می دهد ، باید تنظیمات کاربر را ارائه دهید که به کاربران امکان می دهد عادات داده برنامه شما را کنترل کنند ، مانند این که برنامه شما چند بار داده ها را همگام سازی می کند ، چه در هنگام استفاده از Wi-Fi ، بارگیری/بارگیری ها را انجام دهید. داده ها هنگام رومینگ و غیره. با این کنترل های موجود در اختیار آنها ، کاربران بسیار کمتر احتمال دارند که هنگام نزدیک شدن به محدودیت های خود ، دسترسی برنامه شما به داده ها را غیرفعال کنند ، زیرا در عوض می توانند دقیقاً میزان داده های برنامه شما را کنترل کنند. اگر با این تنظیمات فعالیت اولویت را ارائه می دهید ، باید در اعلامیه آشکار آن یک فیلتر قصد برای عمل ACTION_MANAGE_NETWORK_USAGE را درج کنید. به عنوان مثال:

<activity android:name="DataPreferences" android:label="@string/title_preferences">
    <intent-filter>
       <action android:name="android.intent.action.MANAGE_NETWORK_USAGE" />
       <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

این فیلتر قصد به سیستم نشان می دهد که این فعالیتی است که استفاده از داده های برنامه شما را کنترل می کند. بنابراین ، هنگامی که کاربر از برنامه شما از برنامه Settings استفاده می کند ، یک دکمه "View Settings Application" در دسترس است که فعالیت اولویت شما را راه اندازی می کند تا کاربر بتواند میزان استفاده از برنامه شما را تصحیح کند.

همچنین مراقب باشید که getBackgroundDataSetting() اکنون مستهلک شده است و همیشه واقعی را برمی گرداند - به جای آن getActiveNetworkInfo() استفاده کنید. قبل از انجام هرگونه معاملات شبکه ، همیشه باید با getActiveNetworkInfo() تماس بگیرید تا NetworkInfo که نمایانگر شبکه فعلی و پرس و جو isConnected() دریافت کنید تا بررسی کند که آیا دستگاه دارای اتصال است. سپس می توانید سایر خصوصیات اتصال ، مانند اینکه دستگاه رومینگ است یا به Wi-Fi متصل است ، بررسی کنید.

تصدی

Android 4.0 قابلیت های برنامه سازمانی را با ویژگی های زیر گسترش می دهد.

خدمات VPN

VpnService جدید به برنامه های کاربردی اجازه می دهد تا VPN (شبکه خصوصی مجازی) خود را بسازند و به عنوان یک Service اجرا شوند. یک سرویس VPN یک رابط کاربری برای یک شبکه مجازی با آدرس و قوانین مسیریابی خود ایجاد می کند و تمام خواندن و نوشتن را با توصیف کننده پرونده انجام می دهد.

برای ایجاد یک سرویس VPN ، از VpnService.Builder استفاده کنید ، که به شما امکان می دهد آدرس شبکه ، سرور DNS ، مسیر شبکه و موارد دیگر را مشخص کنید. پس از اتمام ، می توانید رابط کاربری را با فراخوانی establish() ، که یک ParcelFileDescriptor را برمی گرداند ، ایجاد کنید.

از آنجا که یک سرویس VPN می تواند بسته ها را رهگیری کند ، پیامدهای امنیتی وجود دارد. به همین ترتیب ، اگر VpnService را پیاده سازی می کنید ، خدمات شما باید به BIND_VPN_SERVICE نیاز داشته باشد تا اطمینان حاصل شود که فقط سیستم می تواند به آن متصل شود (فقط سیستم به این مجوز اعطا می شود - برنامه ها نمی توانند آن را درخواست کنند). برای استفاده از سرویس VPN خود ، کاربران باید آن را به صورت دستی در تنظیمات سیستم فعال کنند.

سیاست های دستگاه

برنامه هایی که محدودیت های دستگاه را مدیریت می کنند هم اکنون می توانند دوربین را با استفاده از setCameraDisabled() و خاصیت USES_POLICY_DISABLE_CAMERA (با استفاده از یک عنصر <disable-camera /> در پرونده پیکربندی خط مشی استفاده کنند) غیرفعال کنند.

مدیریت گواهی

کلاس جدید KeyChain API را فراهم می کند که به شما امکان می دهد گواهینامه های موجود در فروشگاه کلید System را وارد کنید. گواهینامه ها نصب هر دو گواهی مشتری (برای تأیید هویت کاربر) و گواهینامه های مرجع گواهینامه (برای تأیید هویت سرور) را ساده تر می کنند. برنامه هایی مانند مرورگرهای وب یا مشتریان ایمیل می توانند به گواهینامه های نصب شده برای تأیید اعتبار کاربران به سرورها دسترسی پیدا کنند. برای اطلاعات بیشتر به مستندات KeyChain مراجعه کنید.

سنسورهای دستگاه

دو نوع سنسور جدید در Android 4.0 اضافه شده است:

  • TYPE_AMBIENT_TEMPERATURE : یک سنسور دما که دمای محیط (اتاق) را در درجه سانتیگراد فراهم می کند.
  • TYPE_RELATIVE_HUMIDITY : یک سنسور رطوبت که رطوبت محیط نسبی (اتاق) را به عنوان درصد فراهم می کند.

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

سنسور دمای قبلی ، TYPE_TEMPERATURE ، کاهش یافته است. به جای آن باید از سنسور TYPE_AMBIENT_TEMPERATURE استفاده کنید.

علاوه بر این ، سه سنسور مصنوعی اندروید بسیار بهبود یافته است ، بنابراین اکنون آنها دارای تأخیر کمتری و خروجی نرم تر هستند. این سنسورها شامل سنسور گرانش ( TYPE_GRAVITY ) ، سنسور بردار چرخش ( TYPE_ROTATION_VECTOR ) و سنسور شتاب خطی ( TYPE_LINEAR_ACCELERATION ) است. سنسورهای بهبود یافته برای بهبود خروجی خود به سنسور ژیروسکوپ متکی هستند ، بنابراین سنسورها فقط در دستگاه هایی که دارای ژیروسکوپ هستند ظاهر می شوند.

نوار اکشن

ActionBar برای حمایت از چندین رفتار جدید به روز شده است. از همه مهمتر ، این سیستم به طرز مهربانی اندازه و پیکربندی نوار عمل را هنگام اجرای روی صفحه های کوچکتر مدیریت می کند تا یک تجربه کاربر بهینه در تمام اندازه های صفحه ارائه شود. به عنوان مثال ، هنگامی که صفحه باریک است (مانند وقتی که یک گوشی در جهت گیری پرتره قرار دارد) ، زبانه های ناوبری Action Bar در یک "نوار انباشته" ظاهر می شوند که مستقیماً در زیر نوار اصلی عمل ظاهر می شود. "نوار عمل تقسیم" ، که تمام موارد عمل را در یک نوار جداگانه در پایین صفحه قرار می دهد وقتی صفحه نمایش باریک است.

نوار عمل تقسیم

اگر نوار عمل شما شامل چندین مورد اکشن باشد ، همه آنها در یک نوار اکشن روی صفحه باریک قرار نمی گیرند ، بنابراین سیستم تعداد بیشتری از آنها را در منوی سرریز قرار می دهد. با این حال ، Android 4.0 به شما امکان می دهد "نوار عمل تقسیم "splitActionBarWhenNarrow" را فعال کنید تا موارد اکشن بیشتر در یک نوار جداگانه در انتهای صفحه نمایش android:uiOptions شود. برچسب های <application> شما یا برچسب های <Cienciation <activity> در پرونده مانیفست شما ، سیستم در هنگام باریک بودن یک نوار اضافی در پایین صفحه برای همه موارد اکشن اضافه می کند (هیچ موردی در قسمت اولیه ظاهر نمی شود. نوار عمل).

اگر می خواهید از زبانه های ناوبری ارائه شده توسط APTIS ActionBar.Tab استفاده کنید ، اما به نوار اصلی عمل در بالا احتیاج ندارید (می خواهید فقط زبانه ها در قسمت بالا ظاهر شوند) ، سپس نوار عمل تقسیم را همانطور که در بالا توضیح داده شده است فعال کنید و همچنین برای غیرفعال کردن نماد برنامه در نوار عمل ، با setDisplayShowHomeEnabled(false) تماس بگیرید. با هیچ چیز در نوار اصلی عمل ، ناپدید می شود - همه چیز باقی مانده زبانه های ناوبری در بالا و موارد عمل در پایین صفحه است.

سبک های نوار اکشن

اگر می خواهید یک ظاهر طراحی شده سفارشی را در نوار اکشن اعمال کنید ، می توانید به ترتیب از Properties Properties Properties backgroundStacked و backgroundSplit استفاده کنید تا به ترتیب یک پس زمینه قابل ترسیم یا رنگ در نوار انباشته و نوار تقسیم شده اعمال کنید. همچنین می توانید این سبک ها را در زمان اجرا با setStackedBackgroundDrawable() و setSplitBackgroundDrawable() تنظیم کنید.

ارائه دهنده اقدام

کلاس جدید ActionProvider به شما امکان می دهد یک کنترل کننده تخصصی برای موارد اقدام ایجاد کنید. یک ارائه دهنده عمل می تواند یک نمای عمل ، یک رفتار پیش فرض عمل و یک زیرمنو برای هر مورد عملی را که در آن مرتبط است تعریف کند. هنگامی که می خواهید یک مورد اکشن ایجاد کنید که دارای رفتارهای پویا باشد (مانند نمای عمل متغیر ، عمل پیش فرض یا زیرمنو) ، گسترش ActionProvider یک راه حل خوب برای ایجاد یک مؤلفه قابل استفاده مجدد است ، به جای اینکه به تحولات مختلف اقدامات اقدامی بپردازید قطعه یا فعالیت شما

به عنوان مثال ، ShareActionProvider یک ActionProvider افزودنی است که یک عمل "اشتراک" را از نوار عمل تسهیل می کند. به جای استفاده از مورد اقدام سنتی که از هدف ACTION_SEND استفاده می کند ، می توانید از این ارائه دهنده عمل برای ارائه نمای عمل با یک کشویی استفاده کنید. لیست برنامه هایی که با هدف ACTION_SEND اداره می کنند ، وقتی کاربر برنامه ای را برای استفاده برای عمل انتخاب می کند ، ShareActionProvider آن را به یاد می آورد و آن را در نمای عمل برای دسترسی سریعتر به اشتراک گذاری با آن برنامه فراهم می کند.

برای اعلام یک ارائه دهنده عمل برای یک مورد اکشن ، ویژگی android:actionProviderClass در عنصر <item> برای منوی گزینه های فعالیت خود ، با نام کلاس ارائه دهنده عمل به عنوان مقدار قرار دهید. به عنوان مثال:

<item android:id="@+id/menu_share"
      android:title="Share"
      android:showAsAction="ifRoom"
      android:actionProviderClass="android.widget.ShareActionProvider" />

در روش پاسخ به تماس onCreateOptionsMenu() فعالیت خود ، نمونه ای از ارائه دهنده عمل را از مورد منو بازیابی کنید و قصد را تنظیم کنید:

کاتلین 

override fun onCreateOptionsMenu(menu: Menu): Boolean {
    menuInflater.inflate(R.menu.options, menu)
    val shareActionProvider = menu.findItem(R.id.menu_share)?.actionProvider as? ShareActionProvider
    // Set the share intent of the share action provider.
    shareActionProvider?.setShareIntent(createShareIntent())
    ...
    return super.onCreateOptionsMenu(menu)
}

جاوا 

public boolean onCreateOptionsMenu(Menu menu) {
    getMenuInflater().inflate(R.menu.options, menu);
    ShareActionProvider shareActionProvider =
          (ShareActionProvider) menu.findItem(R.id.menu_share).getActionProvider();
    // Set the share intent of the share action provider.
    shareActionProvider.setShareIntent(createShareIntent());
    ...
    return super.onCreateOptionsMenu(menu);
}

برای مثال با استفاده از ShareActionProvider ، به ActionBarshareActionProviderActivity در Apidemos مراجعه کنید.

نمایش های عمل قابل جمع شدن

موارد عملی که نمای عمل را ارائه می دهند ، اکنون می توانند بین وضعیت نمایش عمل و وضعیت اقدام سنتی خود جابجا شوند. پیش از این فقط در هنگام استفاده به عنوان نمای عمل ، از سقوط SearchView پشتیبانی شده پشتیبانی می شود ، اما اکنون می توانید برای هر مورد عملی ، یک نمای عمل را اضافه کرده و بین حالت گسترش یافته (نمای عمل قابل مشاهده است) و حالت فروپاشی (مورد عمل قابل مشاهده است).

برای اعلام اینکه یک مورد عملی که شامل یک نمای عمل است قابل جمع شدن است ، شامل پرچم “collapseActionView" در android:showAsAction برای عنصر <item> در پرونده XML منو است.

برای دریافت تماس تلفنی هنگامی که نمای عمل بین گسترش و فروپاشی تغییر می کند ، نمونه ای از MenuItem.OnActionExpandListener را با MenuItem مربوطه با فراخوانی setOnActionExpandListener() ثبت کنید. به طور معمول ، شما باید این کار را در طول تماس با onCreateOptionsMenu() انجام دهید.

برای کنترل یک نمای عمل قابل جمع شدن ، می توانید collapseActionView() و expandActionView() را در مورد MenuItem مربوطه تماس بگیرید.

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

API های دیگر برای نوار اکشن

  • setHomeButtonEnabled() به شما امکان می دهد تا مشخص کنید که آیا نماد/آرم به عنوان دکمه ای برای حرکت در خانه یا "بالا" رفتار می کند ("True" را عبور دهید تا آن را به عنوان یک دکمه رفتار کند).
  • setIcon() و setLogo() به شما امکان می دهد نماد یا آرم نوار عمل را در زمان اجرا تعریف کنید.
  • Fragment.setMenuVisibility() به شما امکان می دهد تا از موارد منوی گزینه هایی که توسط این قطعه اعلام شده اند ، امکان پذیر یا غیرفعال شوید. اگر این قطعه به فعالیت اضافه شده باشد ، اما قابل مشاهده نیست ، این مفید است ، بنابراین موارد منو باید پنهان شوند.
  • FragmentManager.invalidateOptionsMenu() به شما امکان می دهد منوی گزینه های فعالیت را در حالت های مختلف چرخه عمر قطعه که در آن با استفاده از روش معادل از Activity ممکن است در دسترس نباشد ، باطل کنید.

رابط کاربری و نماها

Android 4.0 انواع نمایش های جدید و سایر مؤلفه های UI را معرفی می کند.

GridLayout

GridLayout یک گروه نمایش جدید است که دیدگاه های کودک را در یک شبکه مستطیل قرار می دهد. بر خلاف TableLayout ، GridLayout به یک سلسله مراتب مسطح متکی است و از منظره های میانی مانند ردیف های جدول برای تهیه ساختار استفاده نمی کند. در عوض ، کودکان مشخص می کنند که کدام ردیف (ها) و ستون (های) آنها باید اشغال کنند (سلولها می توانند چندین ردیف و/یا ستون را در خود جای دهند) ، و به طور پیش فرض به صورت متوالی در ردیف ها و ستون های شبکه قرار می گیرند. جهت گیری GridLayout تعیین می کند که آیا کودکان پی در پی به طور پیش فرض به صورت افقی یا عمودی گذاشته شده اند. فضای بین کودکان ممکن است یا با استفاده از نمونه های جدید از Space جدید یا با تنظیم پارامترهای حاشیه مربوط به کودکان مشخص شود.

برای نمونه ها با استفاده از GridLayout به Apidemos مراجعه کنید.

عکسبرداری

TextureView نمای جدیدی است که به شما امکان می دهد یک جریان محتوا مانند یک فیلم یا صحنه OpenGL را نمایش دهید. اگرچه مشابه SurfaceView ، TextureView به جای ایجاد یک پنجره جداگانه ، مانند یک نمای منظم رفتار می کند ، بنابراین می توانید مانند هر شیء View دیگر با آن رفتار کنید. به عنوان مثال ، شما می توانید Transforms را اعمال کنید ، آن را با استفاده از ViewPropertyAnimator ، تحریک کنید یا کدورت آن را با setAlpha() تنظیم کنید.

مراقب باشید که TextureView فقط در یک پنجره شتاب سخت افزاری کار می کند.

برای اطلاعات بیشتر ، به مستندات TextureView مراجعه کنید.

ویروس

ویجت Switch جدید یک ضامن دو حالت است که کاربران می توانند به یک طرف یا طرف دیگر (یا به سادگی ضربه بزنند) برای جابجایی گزینه ای بین دو حالت.

می توانید از android:textOn و android:textOff ویژگی ها استفاده کنید تا متن را در هنگام تنظیم روشن و خاموش در سوئیچ ظاهر کنید. ویژگی android:text همچنین به شما امکان می دهد یک برچسب را در کنار سوئیچ قرار دهید.

برای یک نمونه با استفاده از سوئیچ ها ، به پرونده طرح سوئیچ ها. xml و فعالیت سوئیچ های مربوطه مراجعه کنید.

Android 3.0 PopupMenu برای ایجاد منوهای متنی کوتاه معرفی کرد که در یک نقطه لنگر که مشخص می کنید ظاهر می شوند (معمولاً در نقطه مورد انتخاب شده). Android 4.0 PopupMenu با چند ویژگی مفید گسترش می دهد:

  • اکنون می توانید به راحتی محتوای منوی بازشو را از یک منبع منوی XML با inflate() منتقل کنید ، و از آن شناسه منبع منو عبور دهید.
  • هم اکنون می توانید یک PopupMenu.OnDismissListener ایجاد کنید که هنگام اخراج منو ، پاسخ به تماس دریافت می کند.

ترجیحات

یک کلاس انتزاعی جدید TwoStatePreference به عنوان پایه ای برای ترجیحاتی که گزینه انتخاب دو کشور را ارائه می دهد ، خدمت می کند. New SwitchPreference یک برنامه افزودنی TwoStatePreference است که یک ویجت Switch را در نمای اولویت فراهم می کند تا کاربران بتوانند بدون نیاز به باز کردن صفحه یا گفتگوی اضافی ، تنظیمات را روشن یا خاموش کنند. به عنوان مثال ، برنامه تنظیمات از تنظیمات Wi-Fi و بلوتوث استفاده SwitchPreference کند.

تم های سیستمی

موضوع پیش فرض برای کلیه برنامه هایی که Android 4.0 را هدف قرار می دهند (با تنظیم targetSdkVersion یا minSdkVersion به “14" یا بالاتر) اکنون موضوع "پیش فرض دستگاه" است: Theme.DeviceDefault . devicedefault. توسط دستگاه خاص

خانواده Theme.Holo تضمین شده است که هنگام اجرای همان نسخه Android از یک دستگاه به دستگاه دیگر تغییر نمی کنند. اگر به صراحت از هر یک از Theme.Holo استفاده کنید. مضامین مربوط به فعالیت های خود ، می توانید اطمینان داشته باشید که این مضامین در همان نسخه پلت فرم ، شخصیت را در دستگاه های مختلف تغییر نمی دهند.

اگر می خواهید برنامه خود با موضوع کلی دستگاه مخلوط شود (مانند زمانی که OEM های مختلف مضامین پیش فرض متفاوتی را برای سیستم ارائه می دهند) ، باید صریحاً مضامین را از Theme.DeviceDefault استفاده کنید.

دکمه منوی گزینه ها

با شروع Android 4.0 ، متوجه خواهید شد که گوشی ها دیگر به دکمه سخت افزار منو احتیاج ندارند. با این وجود ، اگر برنامه موجود شما منوی گزینه ها را ارائه دهد و انتظار داشته باشد که یک دکمه منو وجود داشته باشد ، دیگر نیازی به نگرانی در مورد این موضوع نیست. برای اطمینان از ادامه کار برنامه های موجود همانطور که انتظار می رود ، سیستم یک دکمه منوی روی صفحه را برای برنامه هایی که برای نسخه های قدیمی Android طراحی شده اند ، فراهم می کند.

برای بهترین تجربه کاربر ، برنامه های جدید و به روز شده باید در عوض از ActionBar برای دسترسی به موارد منو استفاده کنند و targetSdkVersion را برای "14" تنظیم کنند تا از آخرین رفتارهای پیش فرض چارچوب استفاده کنند.

کنترل برای دید UI سیستم

از اوایل اندروید ، این سیستم یک مؤلفه UI را که به عنوان نوار وضعیت شناخته می شود ، مدیریت کرده است که در بالای دستگاه های گوشی قرار دارد تا اطلاعاتی مانند سیگنال حامل ، زمان ، اعلان ها و غیره را ارائه دهد. Android 3.0 نوار سیستم را برای دستگاه های رایانه لوحی اضافه کرد ، که در پایین صفحه قرار دارد تا کنترل های ناوبری سیستم (خانه ، پشت و غیره) را فراهم کند و همچنین یک رابط برای عناصری که به طور سنتی توسط نوار وضعیت ارائه می شود. در Android 4.0 ، این سیستم نوع جدیدی از UI سیستم به نام نوار ناوبری را فراهم می کند. شما ممکن است نوار ناوبری را یک نسخه تنظیم مجدد از نوار سیستم طراحی شده برای گوشی ها در نظر بگیرید. به همین ترتیب ، دستگاهی که نوار ناوبری را فراهم می کند ، نوار وضعیت را نیز در بالا دارد.

تا به امروز ، می توانید نوار وضعیت را روی گوشی ها با استفاده از پرچم FLAG_FULLSCREEN پنهان کنید. در Android 4.0 ، API هایی که کنترل نوار سیستم را کنترل می کنند به روز شده اند تا بهتر رفتار نوار سیستم و نوار ناوبری را منعکس کنند:

  • پرچم SYSTEM_UI_FLAG_LOW_PROFILE پرچم STATUS_BAR_HIDDEN را جایگزین می کند. در هنگام تنظیم ، این پرچم حالت "پایین" را برای نوار سیستم یا نوار ناوبری امکان پذیر می کند. دکمه های ناوبری کم نور و سایر عناصر موجود در نوار سیستم نیز پنهان می شوند. فعال کردن این امر برای ایجاد بازی های همهجانبه بدون حواس پرتی برای دکمه های ناوبری سیستم مفید است.
  • پرچم SYSTEM_UI_FLAG_VISIBLE جایگزین پرچم STATUS_BAR_VISIBLE برای درخواست نوار سیستم یا نوار ناوبری قابل مشاهده است.
  • SYSTEM_UI_FLAG_HIDE_NAVIGATION پرچم جدیدی است که درخواست نوار ناوبری را به طور کامل پنهان می کند. توجه داشته باشید که این فقط برای نوار ناوبری که توسط برخی از گوشی ها استفاده می شود ، کار می کند (نوار سیستم را روی قرص ها پنهان نمی کند). نوار ناوبری به محض دریافت سیستم ورودی کاربر ، به مشاهده باز می گردد. به همین ترتیب ، این حالت در درجه اول برای پخش ویدیویی یا موارد دیگری که در آن کل صفحه مورد نیاز است مفید است اما ورودی کاربر لازم نیست.

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

برای همگام سازی سایر وقایع در فعالیت خود با تغییر دید در سیستم UI سیستم (به عنوان مثال ، نوار عمل یا سایر کنترل های UI را هنگام پنهان کردن سیستم مخفی کنید) ، باید یک View.OnSystemUiVisibilityChangeListener را ثبت کنید. یا نوار ناوبری تغییر می کند.

برای نمایش گزینه های مختلف UI سیستم ، به کلاس Overcanactivity مراجعه کنید.

چارچوب ورودی

Android 4.0 پشتیبانی از وقایع شناور Cursor و رویدادهای جدید دکمه قلم و ماوس را اضافه می کند.

حوادث شناور

کلاس View اکنون از رویدادهای "Hover" پشتیبانی می کند تا با استفاده از دستگاه های اشاره گر (مانند موش یا سایر دستگاه هایی که یک مکان نما روی صفحه را هدایت می کنند) تعامل غنی تر را فعال کنند.

برای دریافت رویدادهای شناور در یک نمای ، View.OnHoverListener را پیاده سازی کرده و آن را در setOnHoverListener() ثبت کنید. هنگامی که یک رویداد شناور در این نمایش اتفاق می افتد ، شنونده شما تماس تلفنی را برای onHover() دریافت می کند ، و View که این رویداد را دریافت کرده است و یک MotionEvent ارائه می دهد که نوع رویداد Hover را که رخ داده است ، ارائه می دهد. رویداد شناور می تواند یکی از موارد زیر باشد:

View.OnHoverListener شما. onhoverlistener اگر این رویداد شناور را انجام دهد ، باید از onHover() برگردد. اگر شنونده شما کاذب را برگرداند ، رویداد شناور طبق معمول به نمای والدین اعزام می شود.

اگر برنامه شما از دکمه ها یا ویجت های دیگری استفاده می کند که ظاهر آنها را بر اساس وضعیت فعلی تغییر می دهد ، اکنون می توانید از ویژگی android:state_hovered در یک لیست حالت قابل ترسیم استفاده کنید تا در صورت شناور از منظره ، پس زمینه دیگری را ترسیم کند.

برای نمایش وقایع جدید شناور ، به کلاس Hover در Apidemos مراجعه کنید.

رویدادهای قلم و دکمه ماوس

Android اکنون API ها را برای دریافت ورودی از یک دستگاه ورودی قلم مانند لوازم جانبی دیجیتایزر لوازم جانبی لوازم جانبی یا صفحه لمسی دارای قلم فراهم می کند.

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

برنامه شما می تواند با پرسیدن "نوع ابزار" مرتبط با هر یک از نشانگرها در MotionEvent با استفاده از getToolType() انواع ابزار در حال حاضر بین انگشت ، ماوس ، قلم و پاک کن تمایز قائل شود: TOOL_TYPE_UNKNOWN ، TOOL_TYPE_FINGER ، TOOL_TYPE_MOUSE ، TOOL_TYPE_STYLUS و TOOL_TYPE_ERASER با پرس و جو از نوع ابزار ، برنامه شما می تواند ورودی قلم را به روش های مختلف از ورودی انگشت یا ماوس انتخاب کند.

برنامه شما همچنین می تواند پرس BUTTON_PRIMARY جو کند که دکمه های ماوس یا BUTTON_SECONDARY BUTTON_BACK پرس BUTTON_TERTIARY جو از "حالت دکمه" از یک MotionEvent با استفاده از BUTTON_FORWARD getButtonState() فشرده می شوند. و دکمه های ماوس به جلو به طور خودکار در کلیدهای KEYCODE_BACK و KEYCODE_FORWARD نقشه برداری می شوند.

علاوه بر اندازه گیری دقیق موقعیت و فشار یک مخاطب ، برخی از دستگاه های ورودی قلم نیز فاصله بین نوک قلم و دیجیتایزر ، زاویه شیب قلم و زاویه جهت گیری قلم را گزارش می کنند. برنامه شما می تواند این اطلاعات را با استفاده از getAxisValue() با Axis Codes AXIS_DISTANCE ، AXIS_TILT و AXIS_ORIENTATION پرس و جو کند.

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

خواص

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

به عنوان مثال ، اگر می خواهید مقدار Field bar بر روی Object foo تنظیم کنید ، قبلاً این کار را انجام می دهید:

کاتلین 

foo.bar = value

جاوا 

foo.bar = value;

اگر می خواهید برای یک bar زمینه خصوصی زیربنایی با تنظیم کننده تماس بگیرید ، قبلاً این کار را می کردید:

کاتلین 

foo.setBar(value)

جاوا 

foo.setBar(value);

با این حال ، اگر می خواهید به نمونه foo بروید و کد دیگری را تنظیم کنید ، مقدار bar را تنظیم کنید ، واقعاً راهی برای انجام این کار قبل از Android 4.0 وجود ندارد.

با استفاده از کلاس Property ، می توانید یک BAR شیء Property را در کلاس Foo اعلام کنید تا بتوانید زمینه را به عنوان مثال foo از کلاس Foo مانند این تنظیم کنید:

کاتلین 

BAR.set(foo, value)

جاوا 

BAR.set(foo, value);

کلاس View اکنون از کلاس Property استفاده می کند تا به شما امکان می دهد زمینه های مختلفی را تنظیم کنید ، مانند خصوصیات تبدیل که در Android 3.0 اضافه شده است ( ROTATION ، ROTATION_X ، TRANSLATION_X و غیره).

کلاس ObjectAnimator همچنین از کلاس Property استفاده می کند ، بنابراین می توانید یک ObjectAnimator با یک Property ایجاد کنید ، که سریعتر ، کارآمدتر و از نوع ایمن تر از رویکرد مبتنی بر رشته است.

شتاب سخت افزاری

با شروع Android 4.0 ، شتاب سخت افزار برای همه ویندوز به طور پیش فرض فعال می شود اگر برنامه شما یا targetSdkVersion یا minSdkVersion را به “14" یا بالاتر تنظیم کرده باشد. .

در صورت لزوم ، می توانید شتاب سخت افزاری را با ویژگی hardwareAccelerated برای عناصر <activity> یا عنصر <application> به صورت دستی غیرفعال کنید. با فراخوانی setLayerType(LAYER_TYPE_SOFTWARE) می توانید شتاب سخت افزار را برای نمایش های جداگانه غیرفعال کنید.

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

JNI تغییر می کند

در نسخه های قبلی Android ، منابع محلی JNI دسته های غیرمستقیم نبودند. اندروید از نشانگرهای مستقیم استفاده کرد. این مسئله تا زمانی که جمع کننده زباله اشیاء را جابجا نکند ، مشکلی نبود ، اما به نظر می رسید که کار می کند زیرا باعث می شود نوشتن کد حشره دار باشد. در Android 4.0 ، این سیستم برای تشخیص این اشکالات از منابع غیرمستقیم استفاده می کند.

Ins و Outs of JNI منابع محلی در "منابع محلی و جهانی" در نکات JNI شرح داده شده است. در Android 4.0 ، CheckJNI برای تشخیص این خطاها تقویت شده است. تماشای وبلاگ توسعه دهندگان Android برای پست آینده در مورد خطاهای مشترک با منابع JNI و منابع JNI و منابع JNI چگونه می توانید آنها را برطرف کنید.

این تغییر در اجرای JNI فقط برنامه هایی را که Android 4.0 را با تنظیم یا targetSdkVersion یا minSdkVersion به “14" یا بالاتر هدف قرار می دهد ، تحت تأثیر قرار می دهد. اگر این ویژگی ها را بر روی هر مقدار پایین تر تنظیم کرده اید ، پس منابع محلی JNI مانند نسخه های قبلی رفتار می کنند .

وب کیت

  • WebKit به نسخه 534.30 به روز شد
  • پشتیبانی از فونت های شاخص (Devanagari ، Bengali و Tamil ، از جمله پشتیبانی شخصیت پیچیده مورد نیاز برای ترکیب گلیف) در WebView و مرورگر داخلی
  • پشتیبانی از فونت های اتیوپی ، گرجی و ارمنی در WebView و مرورگر داخلی
  • پشتیبانی از WebDriver آزمایش برنامه هایی که WebView استفاده می کنند را برای شما آسان می کند

مرورگر اندروید

برنامه مرورگر ویژگی های زیر را برای پشتیبانی از برنامه های وب اضافه می کند:

مجوزها

موارد زیر مجوزهای جدید است:

ویژگی های دستگاه

The following are new device features:

  • FEATURE_WIFI_DIRECT : Declares that the application uses Wi-Fi for peer-to-peer communications.

For a detailed view of all API changes in Android 4.0 (API Level 14), see the API Differences Report .

Previous APIs

In addition to everything above, Android 4.0 naturally supports all APIs from previous releases. Because the Android 3.x platform is available only for large-screen devices, if you've been developing primarily for handsets, then you might not be aware of all the APIs added to Android in these recent releases.

Here's a look at some of the most notable APIs you might have missed that are now available on handsets as well:

اندروید 3.0
  • Fragment : A framework component that allows you to separate distinct elements of an activity into self-contained modules that define their own UI and lifecycle. See the Fragments developer guide.
  • ActionBar : A replacement for the traditional title bar at the top of the activity window. It includes the application logo in the left corner and provides a new interface for menu items. See the Action Bar developer guide.
  • Loader : A framework component that facilitates asynchronous loading of data in combination with UI components to dynamically load data without blocking the main thread. See the Loaders developer guide.
  • System clipboard: Applications can copy and paste data (beyond mere text) to and from the system-wide clipboard. Clipped data can be plain text, a URI, or an intent. See the Copy and Paste developer guide.
  • Drag and drop: A set of APIs built into the view framework that facilitates drag and drop operations. See the Drag and Drop developer guide.
  • An all new flexible animation framework allows you to animate arbitrary properties of any object (View, Drawable, Fragment, Object, or anything else) and define animation aspects such as duration, interpolation, repeat and more. The new framework makes Animations in Android simpler than ever. See the Property Animation developer guide.
  • RenderScript graphics and compute engine: RenderScript offers a high performance 3D graphics rendering and compute API at the native level, which you write in the C (C99 standard), providing the type of performance you expect from a native environment while remaining portable across various CPUs and GPUs. See the RenderScript developer guide.
  • Hardware accelerated 2D graphics: You can now enable the OpenGL renderer for your application by setting {android:hardwareAccelerated="true"} in your manifest element's <application> element or for individual <activity> elements. This results in smoother animations, smoother scrolling, and overall better performance and response to user interaction.

    Note: If you set your application's minSdkVersion or targetSdkVersion to "14" or higher, hardware acceleration is enabled by default.

  • و خیلی خیلی بیشتر. See the Android 3.0 Platform notes for more information.
اندروید 3.1
  • USB APIs: Powerful new APIs for integrating connected peripherals with Android applications. The APIs are based on a USB stack and services that are built into the platform, including support for both USB host and device interactions. See the USB Host and Accessory developer guide.
  • MTP/PTP APIs: Applications can interact directly with connected cameras and other PTP devices to receive notifications when devices are attached and removed, manage files and storage on those devices, and transfer files and metadata to and from them. The MTP API implements the PTP (Picture Transfer Protocol) subset of the MTP (Media Transfer Protocol) specification. See the android.mtp documentation.
  • RTP APIs: Android exposes an API to its built-in RTP (Real-time Transport Protocol) stack, which applications can use to manage on-demand or interactive data streaming. In particular, apps that provide VOIP, push-to-talk, conferencing, and audio streaming can use the API to initiate sessions and transmit or receive data streams over any available network. See the android.net.rtp documentation.
  • Support for joysticks and other generic motion inputs.
  • See the Android 3.1 Platform notes for many more new APIs.
Android 3.2
  • New screens support APIs that give you more control over how your applications are displayed across different screen sizes. The API extends the existing screen support model with the ability to precisely target specific screen size ranges by dimensions, measured in density-independent pixel units (such as 600dp or 720dp wide), rather than by their generalized screen sizes (such as large or xlarge ). For example, this is important in order to help you distinguish between a 5" device and a 7" device, which would both traditionally be bucketed as "large" screens. See the blog post, New Tools for Managing Screen Sizes .
  • New constants for <uses-feature> to declare landscape or portrait screen orientation requirements.
  • The device "screen size" configuration now changes during a screen orientation change. If your app targets API level 13 or higher, you must handle the "screenSize" configuration change if you also want to handle the "orientation" configuration change. See android:configChanges for more information.
  • See the Android 3.2 Platform notes for other new APIs.

سطح API

The Android 4.0 API is assigned an integer identifier— 14 —that is stored in the system itself. This identifier, called the "API level", allows the system to correctly determine whether an application is compatible with the system, prior to installing the application.

To use APIs introduced in Android 4.0 in your application, you need compile the application against an Android platform that supports API level 14 or higher. Depending on your needs, you might also need to add an android:minSdkVersion="14" attribute to the <uses-sdk> element.

For more information, read What is API Level?