سطح API: 19
Android 4.4 ( KITKAT
) نسخه جدیدی برای پلتفرم اندروید است که ویژگی های جدیدی را برای کاربران و توسعه دهندگان برنامه ارائه می دهد. این سند مقدمه ای بر قابل توجه ترین API های جدید ارائه می دهد.
بهعنوان یک توسعهدهنده برنامه، باید در اسرع وقت تصویر سیستم Android 4.4 و پلتفرم SDK را از SDK Manager دانلود کنید. اگر دستگاهی ندارید که Android 4.4 را روی آن آزمایش کنید، از تصویر سیستم Android 4.4 برای آزمایش برنامه خود در شبیه ساز Android استفاده کنید. سپس برنامه های خود را بر اساس پلتفرم Android 4.4 بسازید تا از آخرین API ها استفاده کنید.
سطح API هدف خود را به روز کنید
برای بهینه سازی بهتر برنامه خود برای دستگاه های دارای Android 4.4، باید targetSdkVersion
خود را روی "19"
تنظیم کنید، آن را روی یک تصویر سیستم Android 4.4 نصب کنید، آن را آزمایش کنید، سپس با این تغییر یک به روز رسانی منتشر کنید.
میتوانید از APIها در Android 4.4 استفاده کنید و در عین حال از نسخههای قدیمیتر نیز با افزودن شرایطی به کد خود استفاده کنید که سطح API سیستم را قبل از اجرای APIهایی که توسط minSdkVersion
شما پشتیبانی نمیشوند بررسی میکنند. برای اطلاعات بیشتر در مورد حفظ سازگاری به عقب، پشتیبانی از نسخههای مختلف پلتفرم را بخوانید.
برای اطلاعات بیشتر در مورد نحوه عملکرد سطوح API، سطح API چیست؟
تغییرات مهم رفتاری
اگر قبلاً برنامه ای را برای اندروید منتشر کرده اید، توجه داشته باشید که ممکن است برنامه شما تحت تأثیر تغییرات Android 4.4 قرار گیرد.
اگر برنامه شما از حافظه خارجی می خواند...
برنامه شما نمیتواند فایلهای به اشتراکگذاشتهشده در حافظه خارجی را هنگام اجرا در Android 4.4 بخواند، مگر اینکه برنامه شما مجوز READ_EXTERNAL_STORAGE
را داشته باشد. یعنی فایلهای درون فهرستی که توسط getExternalStoragePublicDirectory()
بازگردانده شدهاند، دیگر بدون اجازه در دسترس نیستند. با این حال، اگر شما نیاز به دسترسی به دایرکتوریهای خاص برنامه خود دارید که توسط getExternalFilesDir()
ارائه شدهاند، به مجوز READ_EXTERNAL_STORAGE
نیاز ندارید.
اگر برنامه شما از WebView استفاده می کند...
برنامه شما ممکن است هنگام اجرا در Android 4.4 رفتار متفاوتی داشته باشد، به خصوص وقتی targetSdkVersion
برنامه خود را به "19" یا بالاتر به روز می کنید.
کد زیربنایی کلاس WebView
و APIهای مرتبط بهروزرسانی شده است تا بر اساس یک عکس فوری مدرن از کد منبع Chromium باشد. این پیشرفتهای مختلفی را برای عملکرد، پشتیبانی از ویژگیهای جدید HTML5 و پشتیبانی از اشکالزدایی از راه دور محتوای WebView
شما به ارمغان میآورد. دامنه این ارتقا به این معنی است که اگر برنامه شما از WebView
استفاده کند، ممکن است رفتار آن در برخی موارد تحت تأثیر قرار گیرد. اگرچه تغییرات رفتاری شناخته شده مستند شده و عمدتاً برنامه شما را تنها زمانی تحت تأثیر قرار میدهد که targetSdkVersion
برنامه خود را به «19» یا بالاتر بهروزرسانی میکنید، WebView
جدید در «حالت quirks» برای ارائه برخی عملکردهای قدیمی در برنامههایی که سطح API 18 و پایینتر را هدف قرار میدهند، کار میکند. ممکن است برنامه شما به رفتارهای ناشناخته نسخه قبلی WebView
وابسته باشد.
بنابراین، اگر برنامه موجود شما از WebView
استفاده میکند، مهم است که در اسرع وقت روی Android 4.4 تست کنید و برای اطلاعات در مورد اینکه چگونه برنامه شما ممکن است در هنگام بهروزرسانی targetSdkVersion
خود به «19» یا بالاتر ، با مهاجرت به WebView در Android 4.4 مشورت کنید.
اگر برنامه شما از AlarmManager استفاده می کند...
هنگامی که targetSdkVersion
برنامه خود را روی "19" یا بالاتر تنظیم می کنید، آلارم هایی که با استفاده از set()
یا setRepeating()
ایجاد می کنید، دقیق نیستند.
برای بهبود بهره وری انرژی، اکنون اندروید آلارمهای همه برنامههایی را که در زمانهای تقریباً مشابهی اتفاق میافتند، دستهبندی میکند، بنابراین سیستم به جای چندین بار، دستگاه را یک بار بیدار میکند تا هر زنگ هشدار را کنترل کند.
اگر زنگ هشدار شما با زمان دقیق ساعت مرتبط نیست، اما همچنان مهم است که زنگ شما در یک بازه زمانی خاص (مانند 2 بعدازظهر تا 4 بعد از ظهر) فراخوانی شود، می توانید از متد new setWindow()
استفاده کنید که یک " را می پذیرد. زودترین زمان برای زنگ هشدار و یک "پنجره" زمانی پس از اولین زمانی که سیستم باید در آن زنگ هشدار را فراخوانی کند.
اگر زنگ شما باید به زمان دقیق ساعت (مانند یادآوری رویداد تقویم) پین شود، میتوانید از روش جدید setExact()
استفاده کنید.
این رفتار دستهای نادقیق فقط برای برنامههای بهروزرسانی شده اعمال میشود. اگر targetSdkVersion
را روی «18» یا پایینتر تنظیم کرده باشید، هشدارهای شما مانند نسخههای قبلی هنگام اجرا در Android 4.4 رفتار خواهند کرد.
اگر برنامه شما داده ها را با استفاده از ContentResolver همگام می کند...
هنگامی که targetSdkVersion
برنامه خود را روی "19" یا بالاتر تنظیم می کنید، ایجاد یک همگام سازی با addPeriodicSync()
عملیات همگام سازی شما را در فاصله زمانی انعطاف پذیری پیش فرض تقریباً 4 درصد از دوره ای که مشخص می کنید انجام می دهد. به عنوان مثال، اگر فرکانس نظرسنجی شما 24 ساعت باشد، ممکن است عملیات همگامسازی شما تقریباً در یک بازه زمانی یک ساعته در روز انجام شود، نه اینکه دقیقاً در همان زمان هر روز انجام شود.
برای تعیین فاصله انعطاف پذیری خود برای عملیات همگام سازی، باید از متد new requestSync()
استفاده کنید. برای جزئیات بیشتر، به بخش زیر درباره آداپتورهای همگامسازی مراجعه کنید.
این رفتار فاصله زمانی انعطافپذیر فقط برای برنامههای بهروزرسانی شده اعمال میشود. اگر targetSdkVersion
روی «18» یا پایینتر تنظیم کرده باشید، درخواستهای همگامسازی موجود شما مانند نسخههای قبلی هنگام اجرا در Android 4.4 رفتار خواهند کرد.
چارچوب چاپ
اندروید اکنون شامل یک چارچوب کامل است که به کاربران اجازه می دهد هر سندی را با استفاده از چاپگر متصل از طریق Wi-Fi، بلوتوث یا سایر خدمات چاپ کنند. این سیستم تراکنش بین برنامهای که میخواهد سندی را چاپ کند و خدماتی که کارهای چاپی را به چاپگر تحویل میدهند، انجام میدهد. چارچوب android.print
تمام API های لازم برای تعیین یک سند چاپی و تحویل آن به سیستم برای چاپ را فراهم می کند. اینکه واقعاً به کدام API برای یک کار چاپی نیاز دارید، به محتوای شما بستگی دارد.
چاپ محتوای عمومی
اگر می خواهید محتوا را از رابط کاربری خود به عنوان یک سند چاپ کنید، ابتدا باید یک زیر کلاس از PrintDocumentAdapter
ایجاد کنید. در این کلاس، شما باید چند متد callback را پیاده سازی کنید، از جمله onLayout()
برای ایجاد طرح بندی خود بر اساس ویژگی های چاپ ارائه شده، و onWrite()
برای سریال کردن محتوای قابل چاپ خود در ParcelFileDescriptor
.
برای نوشتن محتوای خود در ParcelFileDescriptor
باید آن را به صورت PDF ارسال کنید. APIهای جدید PdfDocument
با ارائه یک Canvas
از getCanvas()
که میتوانید محتوای قابل چاپ خود را روی آن بکشید، راه مناسبی برای انجام این کار ارائه میدهند. سپس با استفاده از متد writeTo()
PdfDocument
در ParcelFileDescriptor
بنویسید.
هنگامی که پیاده سازی خود را برای PrintDocumentAdapter
تعریف کردید، می توانید کارهای چاپی را بنا به درخواست کاربر با استفاده از متد PrintManager
، print()
اجرا کنید، که PrintDocumentAdapter
به عنوان یکی از آرگومان های خود می گیرد.
چاپ تصاویر
اگر می خواهید فقط یک عکس یا بیت مپ دیگر چاپ کنید، API های کمکی در کتابخانه پشتیبانی همه کار را برای شما انجام می دهند. به سادگی یک نمونه جدید از PrintHelper
ایجاد کنید، حالت مقیاس را با setScaleMode()
تنظیم کنید، سپس Bitmap
خود را به printBitmap()
منتقل کنید. همین. کتابخانه تمام تعاملات باقی مانده با سیستم را برای تحویل بیت مپ به چاپگر انجام می دهد.
خدمات چاپ ساختمان
به عنوان یک OEM چاپگر، می توانید از چارچوب android.printservice
برای ارائه قابلیت همکاری با چاپگرهای خود از دستگاه های Android استفاده کنید. میتوانید خدمات چاپی را بهعنوان APK بسازید و توزیع کنید، که کاربران میتوانند آنها را در دستگاههای خود نصب کنند. یک برنامه خدمات چاپ اساساً به عنوان یک سرویس بدون هد با تقسیم بندی کلاس PrintService
، که کارهای چاپی را از سیستم دریافت می کند و با استفاده از پروتکل های مناسب، کارها را به چاپگرهای خود مخابره می کند، عمل می کند.
برای اطلاعات بیشتر درباره نحوه چاپ محتوای برنامه خود، چاپ محتوا را بخوانید.
ارائه دهنده پیامک
ارائهدهنده محتوای Telephony
(«ارائهدهنده پیامک») به برنامهها اجازه میدهد پیامهای SMS و MMS را روی دستگاه بخوانند و بنویسند. این شامل جداولی برای پیامهای SMS و MMS دریافتی، پیشنویس، ارسال شده، در انتظار و غیره است.
با شروع اندروید 4.4، تنظیمات سیستم به کاربران این امکان را می دهد که یک "برنامه پیش فرض پیامک" را انتخاب کنند. پس از انتخاب، فقط برنامه پیشفرض پیامک میتواند به ارائهدهنده پیامک بنویسد و فقط برنامه پیشفرض پیامک پیام SMS_DELIVER_ACTION
را هنگامی که کاربر پیامک دریافت میکند یا پخش WAP_PUSH_DELIVER_ACTION
را هنگامی که کاربر MMS دریافت میکند، دریافت میکند. برنامه پیشفرض پیام کوتاه مسئول نوشتن جزئیات برای ارائهدهنده پیامک هنگام دریافت یا ارسال پیام جدید است.
سایر برنامههایی که بهعنوان برنامه پیشفرض پیامک انتخاب نشدهاند، فقط میتوانند ارائهدهنده پیامک را بخوانند، اما ممکن است با شنیدن پخش SMS_RECEIVED_ACTION
، که یک پخش غیرقابل سقط است و ممکن است به چندین برنامه تحویل داده شود، هنگام دریافت پیامک جدید مطلع شوند. این پخش برای برنامههایی در نظر گرفته شده است که --- در حالی که به عنوان برنامه پیشفرض پیامک انتخاب نشدهاند --- نیاز به خواندن پیامهای دریافتی ویژه مانند انجام تأیید شماره تلفن دارند.
برای اطلاعات بیشتر، پست وبلاگ، آماده کردن برنامه های پیامک خود را برای کیت کت بخوانید.
بی سیم و اتصال
شبیه سازی کارت میزبان
برنامههای Android اکنون میتوانند کارتهای NFC ISO14443-4 (ISO-DEP) را که از APDU برای تبادل داده استفاده میکنند (همانطور که در ISO7816-4 مشخص شده است) شبیهسازی کنند. این به دستگاه دارای NFC دارای Android نسخه 4.4 اجازه میدهد تا چندین کارت NFC را همزمان شبیهسازی کند و به پایانه پرداخت NFC یا سایر خوانندههای NFC اجازه میدهد تا تراکنش را با کارت NFC مناسب بر اساس شناسه برنامه (AID) آغاز کنند.
اگر میخواهید یک کارت NFC را که از این پروتکلها در برنامه شما استفاده میکند، شبیهسازی کنید، یک مؤلفه سرویس بر اساس کلاس HostApduService
ایجاد کنید. در حالی که اگر برنامه شما در عوض از یک عنصر امن برای شبیهسازی کارت استفاده میکند، باید سرویسی بر اساس کلاس OffHostApduService
ایجاد کنید که مستقیماً در تراکنشها دخیل نیست، اما برای ثبت AIDهایی که باید توسط عنصر امن مدیریت شوند، ضروری است.
برای اطلاعات بیشتر، راهنمای شبیه سازی کارت NFC را بخوانید.
حالت خواننده NFC
حالت جدید خواننده NFC به یک فعالیت اجازه میدهد تا تمام فعالیتهای NFC را فقط به خواندن انواع برچسبهایی که فعالیت به آنها در پیشزمینه علاقهمند است محدود کند. میتوانید با enableReaderMode()
حالت خواننده را برای فعالیت خود فعال کنید، و اجرای NfcAdapter.ReaderCallback
را ارائه میکند که با شناسایی برچسبهای جدید، یک تماس پاسخ دریافت میکند.
این قابلیت جدید، در ارتباط با شبیهسازی کارت میزبان، به اندروید اجازه میدهد تا در هر دو انتهای یک واسط پرداخت تلفن همراه کار کند: یک دستگاه به عنوان پایانه پرداخت (دستگاهی که فعالیت حالت خواننده را اجرا میکند) و دستگاه دیگری به عنوان مشتری پرداخت عمل میکند. دستگاه شبیه سازی کارت NFC).
فرستنده های مادون قرمز
هنگام اجرا بر روی دستگاهی که دارای فرستنده مادون قرمز (IR) است، اکنون می توانید سیگنال های IR را با استفاده از API های ConsumerIrManager
ارسال کنید. برای دریافت نمونه ای از ConsumerIrManager
، getSystemService()
با CONSUMER_IR_SERVICE
به عنوان آرگومان فراخوانی کنید. سپس می توانید فرکانس های IR پشتیبانی شده دستگاه را با getCarrierFrequencies()
پرس و جو کنید و سیگنال ها را با ارسال فرکانس و الگوی سیگنال مورد نظر خود با transmit()
ارسال کنید.
همیشه باید ابتدا با فراخوانی hasIrEmitter()
بررسی کنید که آیا یک دستگاه دارای فرستنده IR است یا خیر، اما اگر برنامه شما فقط با دستگاههایی سازگار است که دارای فرستنده هستند، باید عنصر <uses-feature>
را در مانیفست خود برای "android.hardware.consumerir"
قرار دهید. "android.hardware.consumerir"
( FEATURE_CONSUMER_IR
).
چند رسانه ای
پخش تطبیقی
پشتیبانی از پخش ویدئوی تطبیقی در حال حاضر با API های MediaCodec
در دسترس است، که امکان تغییر یکپارچه رزولوشن را در حین پخش بر روی یک Surface
فراهم می کند — می توانید فریم های ورودی رمزگشا را با وضوح جدید تغذیه کنید و وضوح بافرهای خروجی بدون شکاف قابل توجهی تغییر می کند.
میتوانید با افزودن دو کلید به MediaFormat
که حداکثر وضوح مورد نیاز برنامه شما از کدک را مشخص میکنند، پخش تطبیقی را فعال کنید: KEY_MAX_WIDTH
و KEY_MAX_HEIGHT
. با اضافه شدن این موارد به MediaFormat
، MediaFormat
با configure()
به نمونه MediaCodec
خود منتقل کنید.
کدک بین وضوحهای مشابه یا کوچکتر از این مقادیر به صورت یکپارچه جابهجا میشود. کدک ممکن است رزولوشنهای بزرگتر از حداکثرهای مشخصشده را نیز پشتیبانی کند (تا زمانی که در محدوده پروفایلهای پشتیبانیشده باشد)، اما انتقال به وضوحهای بزرگتر ممکن است یکپارچه نباشد.
برای تغییر وضوح هنگام رمزگشایی ویدیوی H.264، با استفاده از MediaCodec.queueInputBuffer() به صف فریمها ادامه دهید، اما مطمئن باشید که مقادیر جدید مجموعه پارامترهای Sequence (SPS) و مجموعه پارامترهای تصویر (PPS) را همراه با Refresh رمزگشای آنی ارائه میکنید. قاب (IDR) در یک بافر واحد.
با این حال، قبل از اینکه بخواهید کدک خود را برای پخش تطبیقی پیکربندی کنید، باید با فراخوانی isFeatureSupported(String)
با FEATURE_AdaptivePlayback
تأیید کنید که دستگاه از پخش تطبیقی پشتیبانی می کند.
توجه: پشتیبانی از پخش تطبیقی مختص فروشنده است. برخی از کدک ها ممکن است برای نکات وضوح بزرگتر به حافظه بیشتری نیاز داشته باشند. بنابراین، شما باید حداکثر رزولوشن را بر اساس منبعی که رمزگشایی می کنید تنظیم کنید.
مُهرهای صوتی درخواستی
برای تسهیل همگام سازی صوتی و تصویری، کلاس AudioTimestamp
جدید جزئیات جدول زمانی را در مورد یک «قاب» خاص در یک جریان صوتی که توسط AudioTrack
مدیریت می شود، ارائه می دهد. برای دریافت آخرین مهر زمانی موجود، یک شی AudioTimestamp
را نمونه سازی کنید و آن را به getTimestamp()
ارسال کنید. اگر درخواست برای مهر زمانی با موفقیت انجام شود، نمونه AudioTrack
با یک موقعیت در واحدهای فریم، همراه با زمان تخمینی زمانی که آن فریم ارائه شده یا متعهد به ارائه شده است، پر می شود.
میتوانید از مقدار nanoTime
در AudioTimestamp
(که یکنواخت است) استفاده کنید تا نزدیکترین فریم ویدیویی مرتبط را در مقایسه با framePosition
بیابید، بنابراین میتوانید فریمهای ویدئویی را برای مطابقت با صدا رها، کپی یا درونیابی کنید. همچنین، میتوانید زمان دلتا بین مقدار nanoTime
و زمان مورد انتظار یک فریم ویدیویی آینده (با در نظر گرفتن نرخ نمونه) تعیین کنید تا پیشبینی کنید که کدام فریم صوتی در همان لحظه یک فریم ویدیویی مورد انتظار است.
خواننده تصویر سطحی
ImageReader
API جدید به شما امکان دسترسی مستقیم به بافرهای تصویر را در حین رندر شدن آنها در یک Surface
می دهد. شما می توانید ImageReader
با روش استاتیک newInstance()
بدست آورید. سپس getSurface()
را فراخوانی کنید تا یک Surface
جدید ایجاد کنید و داده های تصویر خود را با تولیدکننده ای مانند MediaPlayer
یا MediaCodec
تحویل دهید. برای اطلاع از در دسترس بودن تصاویر جدید از سطح، رابط ImageReader.OnImageAvailableListener
را پیاده سازی کنید و آن را با setOnImageAvailableListener()
ثبت کنید.
اکنون هنگامی که محتوا را به Surface
خود می کشید، ImageReader.OnImageAvailableListener
شما با در دسترس قرار گرفتن هر فریم تصویر جدید، تماسی با onImageAvailable()
دریافت می کند و ImageReader
مربوطه را در اختیار شما قرار می دهد. میتوانید از ImageReader
برای به دست آوردن دادههای تصویر قاب بهعنوان یک شی Image
با فراخوانی acquireLatestImage()
یا acquireNextImage()
استفاده کنید.
شی Image
دسترسی مستقیم به مهر زمانی، قالب، ابعاد و دادههای پیکسلی تصویر را در ByteBuffer
فراهم میکند. با این حال، برای اینکه کلاس Image
تصاویر شما را تفسیر کند، باید طبق یکی از انواعی که با ثابتها در ImageFormat
یا PixelFormat
تعریف شده است، قالببندی شوند.
اندازه گیری پیک و RMS
اکنون می توانید پیک و RMS جریان صوتی فعلی را از Visualizer
با ایجاد یک نمونه جدید از Visualizer.MeasurementPeakRms
و ارسال آن به getMeasurementPeakRms()
پرس و جو کنید. هنگامی که شما این روش را فراخوانی می کنید، مقادیر پیک و RMS Visualizer.MeasurementPeakRms
داده شده روی آخرین مقادیر اندازه گیری شده تنظیم می شوند.
تقویت کننده صدا
LoudnessEnhancer
زیرمجموعه جدیدی از AudioEffect
است که به شما امکان می دهد تا صدای MediaPlayer
یا AudioTrack
خود را افزایش دهید. این می تواند به ویژه در رابطه با متد جدید getMeasurementPeakRms()
که در بالا ذکر شد، مفید باشد، به منظور افزایش حجم تراک های صوتی گفتاری در حالی که رسانه های دیگر در حال پخش هستند.
کنترل از راه دور
Android 4.0 (سطح API 14) API های RemoteControlClient
را معرفی کرد که به برنامه های رسانه اجازه می دهد رویدادهای کنترل کننده رسانه را از مشتریان راه دور مانند کنترل های رسانه روی صفحه قفل مصرف کنند. اکنون API های جدید RemoteController
به شما امکان می دهند کنترل از راه دور خود را بسازید، و ایجاد برنامه های نوآورانه و تجهیزات جانبی جدید را قادر می سازد که می توانند پخش هر برنامه رسانه ای را که با RemoteControlClient
ادغام می شود، کنترل کنند.
برای ساخت یک کنترل از راه دور، می توانید رابط کاربری خود را به هر شکلی که می خواهید پیاده سازی کنید، اما برای ارائه رویدادهای دکمه رسانه به برنامه رسانه کاربر، باید سرویسی ایجاد کنید که کلاس NotificationListenerService
را گسترش دهد و رابط RemoteController.OnClientUpdateListener
را پیاده سازی کند. استفاده از NotificationListenerService
بهعنوان پایه مهم است زیرا محدودیتهای حریم خصوصی مناسبی را فراهم میکند، که از کاربران میخواهد برنامه شما را به عنوان شنونده اعلان در تنظیمات امنیتی سیستم فعال کنند.
کلاس NotificationListenerService
شامل چند روش انتزاعی است که باید پیاده سازی کنید، اما اگر فقط نگران رویدادهای کنترلر رسانه برای مدیریت پخش رسانه هستید، می توانید پیاده سازی خود را خالی بگذارید و به جای آن بر روی متدهای RemoteController.OnClientUpdateListener
تمرکز کنید.
رتبه بندی از کنترل از راه دور
Android 4.4 بر روی قابلیتهای موجود برای کلاینتهای کنترل از راه دور (برنامههایی که رویدادهای کنترل رسانه را با RemoteControlClient
دریافت میکنند) با افزودن این قابلیت برای کاربران برای رتبهبندی آهنگ فعلی از کنترل از راه دور، ایجاد میکند.
کلاس Rating
جدید اطلاعاتی را در مورد رتبه بندی کاربر در خود گنجانده است. یک رتبهبندی با سبک رتبهبندی آن (یا RATING_HEART
، RATING_THUMB_UP_DOWN
، RATING_3_STARS
، RATING_4_STARS
، RATING_5_STARS
یا RATING_PERCENTAGE
) و مقدار رتبهبندی مناسب برای آن سبک تعریف میشود.
برای اینکه به کاربران اجازه دهید آهنگ های شما را از طریق کنترل از راه دور رتبه بندی کنند:
- با افزودن پرچم
FLAG_KEY_MEDIA_RATING
درsetTransportControlFlags()
علامت دهید که میخواهید رابط کاربری رتبهبندی را در معرض دید کاربر قرار دهید (در صورت وجود). - برای بازیابی
RemoteControlClient.MetadataEditor
editMetadata()
را فراخوانی کنید و آن راRATING_KEY_BY_USER
باaddEditableKey()
ارسال کنید. - سپس با فراخوانی
putObject()
و ارسال آن به عنوان کلیدRATING_KEY_BY_USER
و یکی از سبک های رتبه بندی بالا به عنوان مقدار، سبک رتبه بندی را مشخص کنید.
برای دریافت پاسخ تماس زمانی که کاربر رتبهبندی را از کنترلکننده از راه دور تغییر میدهد، رابط جدید RemoteControlClient.OnMetadataUpdateListener
را پیادهسازی کنید و یک نمونه را به setMetadataUpdateListener()
ارسال کنید. وقتی کاربر رتبهبندی را تغییر میدهد، RemoteControlClient.OnMetadataUpdateListener
شما یک تماس با onMetadataUpdate()
دریافت میکند و RATING_KEY_BY_USER
بهعنوان کلید و یک شی Rating
بهعنوان مقدار ارسال میکند.
زیرنویسهای بسته
VideoView
اکنون هنگام پخش ویدیوهای HTTP Live Stream (HLS) از آهنگهای زیرنویس WebVTT پشتیبانی میکند و آهنگ زیرنویس را مطابق تنظیمات برگزیده زیرنویسی که کاربر در تنظیمات سیستم تعریف کرده است، نمایش میدهد.
همچنین می توانید VideoView
با تراک های زیرنویس WebVTT خود با استفاده از متد addSubtitleSource()
ارائه دهید. این متد یک InputStream
که دادههای زیرنویس را حمل میکند و یک شی MediaFormat
را میپذیرد که فرمت دادههای زیرنویس را مشخص میکند، که میتوانید با استفاده از createSubtitleFormat()
آن را مشخص کنید. این زیرنویس ها نیز بر اساس ترجیحات کاربر بر روی ویدیو ظاهر می شوند.
اگر VideoView
برای نمایش محتوای ویدیوی خود استفاده نمیکنید، باید همپوشانی زیرنویس خود را تا حد امکان با اولویت زیرنویس بسته کاربر مطابقت دهید. یک CaptioningManager
API جدید به شما امکان میدهد تنظیمات برگزیده شرح بسته کاربر، از جمله سبکهای تعریفشده توسط CaptioningManager.CaptionStyle
، مانند حروف و رنگ را جستجو کنید. در صورتی که کاربر پس از شروع ویدیوی شما، برخی از تنظیمات برگزیده را تنظیم کند، باید با ثبت نمونه ای از CaptioningManager.CaptioningChangeListener
، به تغییرات در تنظیمات برگزیده گوش دهید تا در صورت تغییر هر یک از تنظیمات برگزیده، پاسخ تماس دریافت کنید، سپس زیرنویس خود را در صورت لزوم به روز کنید.
انیمیشن و گرافیک
صحنه ها و انتقال ها
چارچوب جدید android.transition
API هایی را ارائه می دهد که انیمیشن ها را بین حالت های مختلف رابط کاربری شما تسهیل می کند. یکی از ویژگیهای کلیدی این است که شما میتوانید حالتهای متمایز رابط کاربری خود را که به عنوان «صحنهها» شناخته میشود، با ایجاد یک طرحبندی جداگانه برای هر یک تعریف کنید. هنگامی که می خواهید از یک صحنه به صحنه دیگر متحرک شوید، یک "انتقال" را اجرا کنید، که انیمیشن لازم را برای تغییر طرح از صحنه فعلی به صحنه بعدی محاسبه می کند.
برای انتقال بین دو صحنه، به طور کلی باید موارد زیر را انجام دهید:
-
ViewGroup
حاوی اجزای UI که می خواهید تغییر دهید را مشخص کنید. - طرح بندی را که نشان دهنده نتیجه نهایی تغییر است (صحنه بعدی) مشخص کنید.
- نوع انتقالی را که باید تغییر طرح بندی را متحرک کند، مشخص کنید.
- انتقال را اجرا کنید.
میتوانید از یک شی Scene
برای انجام مراحل 1 و 2 استفاده کنید. یک Scene
حاوی ابردادههایی است که ویژگیهای یک طرحبندی را که برای انجام یک انتقال ضروری هستند، از جمله نمای والد صحنه و طرحبندی صحنه را توصیف میکند. شما می توانید یک Scene
با استفاده از سازنده کلاس یا متد static getSceneForLayout()
ایجاد کنید.
سپس باید از TransitionManager
برای انجام مراحل 3 و 4 استفاده کنید. یک راه این است که Scene
خود را به متد static go()
منتقل کنید. این نمای والد صحنه را در طرحبندی فعلی پیدا میکند و برای رسیدن به طرحبندی تعریفشده توسط Scene
، یک انتقال روی نماهای فرزند انجام میدهد.
از طرف دیگر، به هیچ وجه نیازی به ایجاد یک شیء Scene
ندارید، بلکه میتوانید در عوض beginDelayedTransition()
را فراخوانی کنید و یک ViewGroup
را مشخص کنید که حاوی نماهایی است که میخواهید تغییر دهید. سپس نماهای مورد نظر را اضافه، حذف یا پیکربندی مجدد کنید. پس از اینکه سیستم تغییرات را در صورت لزوم تنظیم کرد، یک انتقال شروع به متحرک سازی تمام نماهای تحت تأثیر می کند.
برای کنترل بیشتر، میتوانید مجموعهای از انتقالها را که باید بین صحنههای از پیش تعریفشده اتفاق بیفتد، با استفاده از یک فایل XML در دایرکتوری res/transition/
پروژه خود تعریف کنید. در داخل یک عنصر <transitionManager>
، یک یا چند تگ <transition>
را مشخص کنید که هر کدام یک صحنه (ارجاع به یک فایل طرحبندی) و انتقالی را که هنگام ورود و/یا خروج از آن صحنه اعمال میشود، مشخص کنید. سپس با استفاده از inflateTransitionManager()
این مجموعه از انتقال ها را باد کنید. از TransitionManager
برگشتی برای اجرای هر انتقال با transitionTo()
استفاده کنید و یک Scene
که توسط یکی از تگهای <transition>
نمایش داده میشود، عبور دهید. همچنین میتوانید مجموعهای از انتقالها را بهصورت برنامهنویسی با APIهای TransitionManager
تعریف کنید.
هنگام تعیین یک انتقال، می توانید از چندین نوع از پیش تعریف شده که توسط زیر کلاس های Transition
تعریف شده اند، مانند Fade
و ChangeBounds
استفاده کنید. اگر نوع انتقال را مشخص نکنید، سیستم به طور پیشفرض از AutoTransition
استفاده میکند که بهطور خودکار نماها را محو میکند، حرکت میدهد و در صورت لزوم اندازهها را تغییر میدهد. علاوه بر این، میتوانید با گسترش هر یک از این کلاسها، انتقالهای سفارشی ایجاد کنید تا انیمیشنها را هر طور که میخواهید انجام دهید. یک انتقال سفارشی می تواند هر تغییر خاصیت را که می خواهید دنبال کند و هر انیمیشنی را که می خواهید بر اساس آن تغییرات ایجاد کند. به عنوان مثال، می توانید یک زیر کلاس از Transition
ارائه دهید که به تغییرات در ویژگی "rotation" یک view گوش می دهد و سپس هر تغییری را متحرک می کند.
برای اطلاعات بیشتر، به مستندات TransitionManager
مراجعه کنید.
انیماتور در حال مکث است
API های Animator
اکنون به شما این امکان را می دهند که با متدهای pause()
و resume()
یک انیمیشن در حال انجام را متوقف کرده و از سر بگیرید.
برای ردیابی وضعیت یک انیمیشن، میتوانید رابط Animator.AnimatorPauseListener
را پیادهسازی کنید، که وقتی انیمیشن متوقف میشود و از سر گرفته میشود، پاسخهای تماس را ارائه میدهد: pause()
و resume()
. سپس با addPauseListener()
شنونده را به یک شی Animator
اضافه کنید.
همچنین، میتوانید کلاس انتزاعی AnimatorListenerAdapter
را زیر کلاس قرار دهید، که اکنون شامل پیادهسازیهای خالی برای تماسهای مکث و ازسرگیری تعریفشده توسط Animator.AnimatorPauseListener
است.
بیت مپ های قابل استفاده مجدد
اکنون می توانید از هر بیت مپ قابل تغییر در BitmapFactory
برای رمزگشایی هر بیت مپ دیگری استفاده کنید - حتی زمانی که بیت مپ جدید اندازه متفاوتی دارد --- تا زمانی که تعداد بایت های حاصل از بیت مپ رمزگشایی شده (در دسترس از getByteCount()
) کمتر یا مساوی باشد. به تعداد بایت تخصیص یافته بیت مپ استفاده مجدد (موجود در getAllocationByteCount()
. برای اطلاعات بیشتر، inBitmap
را ببینید.
APIهای جدید برای Bitmap
امکان پیکربندی مجدد مشابه را برای استفاده مجدد در خارج از BitmapFactory
(برای تولید بیت مپ دستی یا منطق رمزگشایی سفارشی) میدهند. اکنون میتوانید ابعاد بیتمپ را با متدهای setHeight()
و setWidth()
تنظیم کنید و با setConfig()
یک Bitmap.Config
جدید را بدون تأثیر بر تخصیص بیت مپ زیرین مشخص کنید. متد reconfigure()
همچنین راه مناسبی برای ترکیب این تغییرات با یک فراخوانی فراهم می کند.
با این حال، نباید نقشه بیتی را که در حال حاضر توسط سیستم view استفاده میشود، پیکربندی مجدد کنید، زیرا بافر پیکسل زیرین به روشی قابل پیشبینی مجدداً ترسیم نمیشود.
محتوای کاربر
چارچوب دسترسی به ذخیره سازی
در نسخههای قبلی Android، اگر میخواهید برنامه شما نوع خاصی از فایل را از برنامه دیگری بازیابی کند، باید یک intent را با عمل ACTION_GET_CONTENT
فراخوانی کند. این اقدام همچنان راه مناسبی برای درخواست فایلی است که میخواهید به برنامه خود وارد کنید . با این حال، Android 4.4 عمل ACTION_OPEN_DOCUMENT
را معرفی میکند که به کاربر امکان میدهد فایلی از نوع خاصی را انتخاب کند و به برنامه شما دسترسی طولانی مدت خواندن به آن فایل (احتمالاً با دسترسی نوشتن) بدون وارد کردن فایل به برنامه شما بدهد.
اگر در حال توسعه برنامهای هستید که خدمات ذخیرهسازی فایلها (مانند سرویس ذخیره ابری) را ارائه میکند، میتوانید با پیادهسازی یک ارائهدهنده محتوا به عنوان زیر کلاس کلاس DocumentsProvider
جدید، در این رابط کاربری یکپارچه برای انتخاب فایلها شرکت کنید. زیرکلاس DocumentsProvider
شما باید دارای یک فیلتر هدف باشد که عملکرد PROVIDER_INTERFACE
را بپذیرد ( "android.content.action.DOCUMENTS_PROVIDER"
). سپس باید چهار روش انتزاعی را در DocumentsProvider
پیاده سازی کنید:
-
queryRoots()
- این باید یک
Cursor
برگرداند که تمام دایرکتوریهای ریشه ذخیرهسازی اسناد شما را با استفاده از ستونهای تعریفشده درDocumentsContract.Root
توصیف کند. -
queryChildDocuments()
- این باید یک
Cursor
برگرداند که تمام فایلهای موجود در فهرست مشخصشده را با استفاده از ستونهای تعریفشده درDocumentsContract.Document
توصیف کند. -
queryDocument()
- این باید
Cursor
برگرداند که فایل مشخص شده را با استفاده از ستون های تعریف شده درDocumentsContract.Document
توصیف می کند. -
openDocument()
- این باید یک
ParcelFileDescriptor
نشان دهنده فایل مشخص شده را برگرداند. سیستم زمانی این روش را فراخوانی می کند که کاربر یک فایل را انتخاب کند و برنامه مشتری با فراخوانیopenFileDescriptor()
درخواست دسترسی به آن کند.
برای اطلاعات بیشتر، راهنمای چارچوب دسترسی به فضای ذخیره سازی را ببینید.
دسترسی به حافظه خارجی
اکنون میتوانید فایلهای مخصوص برنامه را در رسانههای ذخیرهسازی خارجی ثانویه بخوانید و بنویسید، مانند زمانی که دستگاهی هم فضای ذخیرهسازی شبیهسازی شده و هم یک کارت SD ارائه میکند. متد جدید getExternalFilesDirs()
مانند متد getExternalFilesDir()
موجود عمل می کند با این تفاوت که آرایه ای از اشیاء File
را برمی گرداند. قبل از خواندن یا نوشتن در هر یک از مسیرهای برگردانده شده توسط این متد، شی File
را به متد getStorageState()
جدید ارسال کنید تا تأیید شود که ذخیره سازی در حال حاضر موجود است.
روشهای دیگر برای دسترسی به دایرکتوری کش مخصوص برنامه و دایرکتوری OBB شما نیز اکنون نسخههای متناظری دارند که دسترسی به دستگاههای ذخیرهسازی ثانویه را فراهم میکنند: getExternalCacheDirs()
و getObbDirs()
به ترتیب.
اولین ورودی در آرایه File
برگشتی، حافظه خارجی اصلی دستگاه در نظر گرفته می شود، که همان File
است که با روش های موجود مانند getExternalFilesDir()
بازگردانده شده است.
توجه: با شروع Android 4.4، پلتفرم دیگر نیازی ندارد که برنامه شما WRITE_EXTERNAL_STORAGE
یا READ_EXTERNAL_STORAGE
را دریافت کند، زمانی که باید با استفاده از روشهای بالا فقط به مناطق خاص برنامه خود در حافظه خارجی دسترسی داشته باشید. با این حال، اگر میخواهید به مناطق قابل اشتراکگذاری حافظه خارجی که توسط getExternalStoragePublicDirectory()
دسترسی داشته باشید، مجوزها لازم است.
همگام سازی آداپتورها
روش جدید requestSync()
در ContentResolver
برخی از مراحل تعریف درخواست همگامسازی برای ContentProvider
را با کپسوله کردن درخواستها در شیء جدید SyncRequest
که میتوانید با SyncRequest.Builder
ایجاد کنید، ساده میکند. ویژگیهای موجود در SyncRequest
عملکردی مشابه تماسهای همگامسازی ContentProvider
موجود را ارائه میکنند، اما این قابلیت را اضافه میکند که با فعال کردن setDisallowMetered()
مشخص کند که در صورت اندازهگیری شبکه، همگامسازی حذف شود.
ورودی کاربر
انواع سنسور جدید
سنسور جدید TYPE_GEOMAGNETIC_ROTATION_VECTOR
داده های بردار چرخشی را بر اساس مغناطیس سنج ارائه می دهد که جایگزین مفیدی برای حسگر TYPE_ROTATION_VECTOR
در زمانی که ژیروسکوپ در دسترس نیست یا هنگام استفاده با رویدادهای حسگر دسته ای برای ضبط جهت دستگاه در حالی که تلفن در حالت خواب است استفاده می شود. این حسگر به انرژی کمتری نسبت به TYPE_ROTATION_VECTOR
نیاز دارد، اما ممکن است مستعد دادههای رویدادهای پر سر و صدا باشد و زمانی که کاربر در خارج از منزل است مؤثرتر است.
اندروید همچنین اکنون از سنسورهای مرحله داخلی در سخت افزار پشتیبانی می کند:
-
TYPE_STEP_DETECTOR
- این حسگر هر بار که کاربر قدمی برمی دارد یک رویداد را راه اندازی می کند. در هر مرحله کاربر، این سنسور یک رویداد با مقدار 1.0 و یک مهر زمانی ارائه می دهد که نشان می دهد چه زمانی مرحله رخ داده است.
-
TYPE_STEP_COUNTER
- این حسگر همچنین در هر مرحله شناسایی شده یک رویداد را راهاندازی میکند، اما در عوض تعداد کل مراحل انباشته شده را از زمانی که این سنسور برای اولین بار توسط یک برنامه ثبت شده است، ارائه میکند.
توجه داشته باشید که این سنسورهای دو مرحله ای همیشه نتایج یکسانی را ارائه نمی دهند. رویدادهای TYPE_STEP_COUNTER
با تأخیر بالاتری نسبت به رویدادهای TYPE_STEP_DETECTOR
رخ میدهند، اما به این دلیل است که الگوریتم TYPE_STEP_COUNTER
پردازش بیشتری را برای حذف موارد مثبت کاذب انجام میدهد. بنابراین TYPE_STEP_COUNTER
ممکن است در ارائه رویدادها کندتر باشد، اما نتایج آن باید دقیق تر باشد.
هر دو سنسور مرحله ای وابسته به سخت افزار هستند (Nexus 5 اولین دستگاهی است که از آنها پشتیبانی می کند)، بنابراین باید با hasSystemFeature()
در دسترس بودن را با استفاده از ثابت های FEATURE_SENSOR_STEP_DETECTOR
و FEATURE_SENSOR_STEP_COUNTER
بررسی کنید.
رویدادهای حسگر دستهای
برای مدیریت بهتر قدرت دستگاه، APIهای SensorManager
اکنون به شما امکان میدهند فرکانسی را که میخواهید سیستم در آن دستهای از رویدادهای حسگر را به برنامه شما تحویل دهد، مشخص کنید. این کار تعداد رویدادهای واقعی حسگر موجود در برنامه شما را برای یک دوره زمانی معین کاهش نمیدهد، بلکه فرکانس تماس سیستم با SensorEventListener
شما را با بهروزرسانیهای حسگر کاهش میدهد. به این معنی که سیستم به جای اینکه هر رویداد را در لحظه وقوع به برنامه شما تحویل دهد، تمام رویدادهایی را که در یک دوره زمانی رخ می دهند ذخیره می کند، سپس آنها را به یکباره به برنامه شما تحویل می دهد.
برای ارائه دسته بندی، کلاس SensorManager
دو نسخه جدید از متد registerListener()
اضافه می کند که به شما امکان می دهد «حداکثر تأخیر گزارش» را مشخص کنید. این پارامتر جدید حداکثر تاخیری را که SensorEventListener
شما برای تحویل رویدادهای حسگر جدید تحمل می کند، مشخص می کند. برای مثال، اگر تاخیر دستهای را یک دقیقه تعیین کنید، سیستم مجموعه اخیر رویدادهای دستهبندیشده را در فاصله زمانی بیش از یک دقیقه با برقراری تماسهای متوالی با متد onSensorChanged()
شما ارائه میکند - یک بار برای هر رویداد دستهای. رویدادهای حسگر هرگز بیش از حداکثر مقدار تأخیر گزارش شما به تأخیر نمیافتند، اما اگر برنامههای دیگر تأخیر کوتاهتری برای همان سنسور درخواست کرده باشند، ممکن است زودتر به دست بیایند.
با این حال، توجه داشته باشید که حسگر رویدادهای دستهبندیشده را بر اساس تأخیر گزارش شما تنها زمانی که CPU بیدار است، به برنامه شما تحویل میدهد. اگرچه یک حسگر سختافزاری که از دستهبندی پشتیبانی میکند، به جمعآوری رویدادهای حسگر در زمانی که CPU در حالت خواب است ادامه میدهد، CPU را بیدار نمیکند تا رویدادهای دستهای را به برنامه شما تحویل دهد. زمانی که حسگر در نهایت حافظه خود را برای رویدادها تمام کرد، شروع به حذف قدیمی ترین رویدادها می کند تا جدیدترین رویدادها را ذخیره کند. میتوانید با بیدار کردن دستگاه قبل از اینکه حسگر حافظه آن را پر کند، از دست دادن رویدادها جلوگیری کنید و سپس flush()
برای ضبط آخرین دسته از رویدادها فراخوانی کنید. برای تخمین زمانی که حافظه پر می شود و باید فلاش شود، getFifoMaxEventCount()
را فراخوانی کنید تا حداکثر تعداد رویدادهای حسگر را که می تواند ذخیره کند، به دست آورید و آن عدد را بر نرخی که برنامه شما برای هر رویداد می خواهد تقسیم کنید. از این محاسبه برای تنظیم هشدارهای بیداری با AlarmManager
استفاده کنید که Service
شما (که SensorEventListener
پیاده سازی می کند) را برای شستشوی حسگر فراخوانی می کند.
توجه: همه دستگاهها از رویدادهای حسگر دستهای پشتیبانی نمیکنند زیرا نیاز به پشتیبانی توسط حسگر سختافزاری دارد. با این حال ، با شروع Android 4.4 ، شما همیشه باید از روش های New registerListener()
استفاده کنید ، زیرا اگر دستگاه از دسته بندی پشتیبانی نمی کند ، سیستم با لطف استدلال تأخیر دسته ای را نادیده می گیرد و در زمان واقعی وقایع سنسور را ارائه می دهد.
هویت کنترل کننده
Android اکنون هر کنترلر متصل را با یک عدد صحیح منحصر به فرد مشخص می کند که می توانید با getControllerNumber()
پرس و جو کنید ، و این باعث می شود که هر کنترلر را با یک بازیکن متفاوت در یک بازی مرتبط کنید. عدد برای هر کنترلر ممکن است به دلیل قطع کنترل ، اتصال یا تنظیم مجدد توسط کاربر تغییر کند ، بنابراین باید با ثبت نمونه ای از InputManager.InputDeviceListener
، کدام شماره کنترل کننده را با هر دستگاه ورودی مطابقت دهد. سپس در صورت بروز تغییر getControllerNumber()
را برای هر InputDevice
تماس بگیرید.
دستگاه های متصل نیز اکنون شناسه های محصول و فروشنده را ارائه می دهند که از getProductId()
و getVendorId()
در دسترس هستند. اگر نیاز به اصلاح نقشه های اصلی خود بر اساس مجموعه کلیدهای موجود در یک دستگاه دارید ، می توانید از دستگاه پرس و جو کنید تا بررسی کنید که آیا کلیدهای خاصی با hasKeys(int...)
در دسترس هستند.
رابط کاربری
حالت همهجانبه تمام صفحه
برای تهیه برنامه خود برای برنامه خود که کل صفحه را پر می کند ، پرچم جدید SYSTEM_UI_FLAG_IMMERSIVE
برای setSystemUiVisibility()
(هنگامی که با SYSTEM_UI_FLAG_HIDE_NAVIGATION
ترکیب می شود) یک حالت همهجانبه جدید را امکان پذیر می کند. در حالی که حالت کامل صفحه نمایش همهجانبه فعال است ، فعالیت شما همچنان به دریافت تمام رویدادهای لمسی ادامه می دهد. کاربر می تواند میله های سیستم را با کشش داخلی در امتداد منطقه ای که در آن سیستم به طور معمول در آن ظاهر می شود ، فاش کند. این پرچم SYSTEM_UI_FLAG_HIDE_NAVIGATION
(و پرچم SYSTEM_UI_FLAG_FULLSCREEN
، در صورت استفاده) را پاک می کند تا میله های سیستم قابل مشاهده باشند. با این حال ، اگر دوست دارید میله های سیستم بعد از چند لحظه دوباره مخفی شوند ، می توانید در عوض از پرچم SYSTEM_UI_FLAG_IMMERSIVE_STICKY
استفاده کنید.
میله های سیستم شفاف
اکنون می توانید میله های سیستم را تا حدی با مضامین جدید ، Theme.Holo.NoActionBar.TranslucentDecor
و Theme.Holo.Light.NoActionBar.TranslucentDecor
درست کنید. با فعال کردن میله های سیستم شفاف ، طرح شما ناحیه پشت میله های سیستم را پر می کند ، بنابراین باید برای بخشی از طرح خود که نباید توسط میله های سیستم پوشانده شود ، fitsSystemWindows
نیز فعال کنید.
اگر در حال ایجاد یک موضوع سفارشی هستید ، یکی از این مضامین را به عنوان موضوع والدین تنظیم کنید یا ویژگی های سبک windowTranslucentNavigation
و windowTranslucentStatus
را در موضوع خود قرار دهید.
شنونده اعلان پیشرفته
Android 4.3 API های NotificationListenerService
را اضافه کرد و به برنامه ها اجازه می دهد تا اطلاعات مربوط به اعلان های جدید را همانطور که توسط سیستم ارسال می شود ، دریافت کنند. در Android 4.4 ، شنوندگان اعلان می توانند ابرداده اضافی را برای اعلان و جزئیات کامل در مورد اقدامات اعلان بازیابی کنند:
قسمت جدید Notification.extras
شامل یک Bundle
برای ارائه ابرداده اضافی سازنده شما مانند EXTRA_TITLE
و EXTRA_PICTURE
است. کلاس Notification.Action
ویژگی های یک عمل متصل به اعلان را تعریف می کند ، که می توانید از قسمت actions
جدید بازیابی کنید.
آینه سازی قابل ترسیم برای چیدمان RTL
در نسخه های قبلی Android ، اگر برنامه شما شامل تصاویری است که باید جهت گیری افقی خود را برای طرح های راست به چپ معکوس کند ، شما باید تصویر آینه ای را در یک فهرست drawables-ldrtl/
منابع قرار دهید. اکنون ، این سیستم می تواند با فعال کردن ویژگی autoMirrored
در یک منبع قابل ترسیم یا با فراخوانی setAutoMirrored()
تصاویر را به طور خودکار برای شما آینه کند. در صورت فعال بودن ، هنگامی که جهت چیدمان راست به چپ باشد ، به طور خودکار Drawable
می شود.
قابلیت دسترسی
کلاس View
اکنون به شما امکان می دهد "مناطق زنده" را برای بخش هایی از UI خود که به طور پویا با محتوای متن جدید به روز می شود ، با افزودن ویژگی جدید accessibilityLiveRegion
شما به طرح XML یا فراخوانی setAccessibilityLiveRegion()
اعلام کنید. به عنوان مثال ، یک صفحه ورود به سیستم با یک قسمت متن که یک اعلان "رمز عبور نادرست" را نشان می دهد باید به عنوان یک منطقه زنده مشخص شود ، بنابراین خواننده صفحه نمایش هنگام تغییر پیام را تلاوت می کند.
برنامه هایی که یک سرویس دسترسی را ارائه می دهند هم اکنون می توانند توانایی های خود را با API های جدید که اطلاعاتی در مورد مجموعه های نمایش مانند لیست یا نمایش شبکه با استفاده از AccessibilityNodeInfo.CollectionInfo
و AccessibilityNodeInfo.CollectionItemInfo
ارائه می دهند ، افزایش دهند.
مجوزهای برنامه
موارد زیر مجوزهای جدیدی است که برنامه شما باید با برچسب <uses-permission>
درخواست کند تا از API های جدید خاصی استفاده کند:
-
INSTALL_SHORTCUT
- به یک برنامه اجازه می دهد تا میانبر را در پرتاب نصب کند
-
UNINSTALL_SHORTCUT
- به یک برنامه اجازه می دهد تا میانبر را در پرتاب حذف کند
-
TRANSMIT_IR
- در صورت وجود یک برنامه به یک برنامه اجازه می دهد تا از فرستنده IR دستگاه استفاده کند
توجه: با شروع Android 4.4 ، این پلتفرم دیگر نیازی به برنامه شما ندارد که وقتی می خواهید به مناطق خاص برنامه خود از ذخیره سازی خارجی با استفاده از روش WRITE_EXTERNAL_STORAGE
مانند getExternalFilesDir()
دسترسی پیدا کنید READ_EXTERNAL_STORAGE
برنامه شما را به دست آورد. با این حال ، در صورتی که می خواهید به مناطق قابل اشتعال ذخیره خارجی ، تهیه شده توسط getExternalStoragePublicDirectory()
دسترسی داشته باشید ، مجوزها هنوز هم لازم است.
ویژگی های دستگاه
موارد زیر ویژگی های دستگاه جدیدی است که می توانید با برچسب <uses-feature>
اعلام کنید تا الزامات برنامه خود را اعلام کرده و فیلتر را در Google Play فعال کنید یا در زمان اجرا را بررسی کنید:
-
FEATURE_CONSUMER_IR
- این دستگاه قادر به برقراری ارتباط با دستگاه های IR مصرف کننده است.
-
FEATURE_DEVICE_ADMIN
- این دستگاه از اجرای خط مشی دستگاه از طریق مدیر دستگاه پشتیبانی می کند.
-
FEATURE_NFC_HOST_CARD_EMULATION
- این دستگاه از تقلید کارت NFC مبتنی بر میزبان پشتیبانی می کند.
-
FEATURE_SENSOR_STEP_COUNTER
- این دستگاه شامل یک پیشخوان مرحله سخت افزاری است.
-
FEATURE_SENSOR_STEP_DETECTOR
- این دستگاه شامل یک ردیاب مرحله سخت افزاری است.
برای مشاهده دقیق همه تغییرات API در Android 4.4 ، به گزارش API تفاوت مراجعه کنید.