سطح API: 18
Android 4.3 ( JELLY_BEAN_MR2
) بهروزرسانی نسخه Jelly Bean است که ویژگیهای جدیدی را برای کاربران و توسعهدهندگان برنامه ارائه میکند. این سند مقدمه ای بر قابل توجه ترین API های جدید ارائه می دهد.
بهعنوان یک توسعهدهنده برنامه، باید تصویر سیستم Android 4.3 و پلتفرم SDK را در اسرع وقت از مدیریت SDK دانلود کنید. اگر دستگاهی ندارید که Android 4.3 را روی آن آزمایش کنید، از تصویر سیستم Android 4.3 برای آزمایش برنامه خود در شبیه ساز Android استفاده کنید. سپس برنامههای خود را با پلتفرم Android 4.3 بسازید تا از جدیدترین APIها استفاده کنید.
سطح API هدف خود را به روز کنید
برای بهینه سازی بهتر برنامه خود برای دستگاه های دارای Android 4.3، باید targetSdkVersion
خود را روی "18"
تنظیم کنید، آن را روی یک تصویر سیستم Android 4.3 نصب کنید، آن را آزمایش کنید، سپس با این تغییر یک به روز رسانی منتشر کنید.
میتوانید از APIها در Android نسخه 4.3 استفاده کنید و در عین حال از نسخههای قدیمیتر نیز با افزودن شرایطی به کد خود استفاده کنید که سطح API سیستم را قبل از اجرای APIهایی که توسط minSdkVersion
شما پشتیبانی نمیشوند بررسی میکنند. برای اطلاعات بیشتر در مورد حفظ سازگاری به عقب، پشتیبانی از نسخههای مختلف پلتفرم را بخوانید.
API های مختلفی نیز در کتابخانه پشتیبانی اندروید موجود است که به شما امکان می دهد ویژگی های جدید را در نسخه های قدیمی تر این پلتفرم پیاده سازی کنید.
برای اطلاعات بیشتر در مورد نحوه عملکرد سطوح API، سطح API چیست؟
تغییرات مهم رفتاری
اگر قبلاً یک برنامه برای Android منتشر کرده اید، توجه داشته باشید که ممکن است برنامه شما تحت تأثیر تغییرات Android 4.3 قرار گیرد.
اگر برنامه شما از مقاصد ضمنی استفاده می کند...
ممکن است برنامه شما در یک محیط نمایه محدود رفتار نادرست داشته باشد.
کاربران در یک محیط نمایه محدود ممکن است همه برنامههای استاندارد Android را در دسترس نداشته باشند. برای مثال، یک نمایه محدود ممکن است مرورگر وب و برنامه دوربین را غیرفعال کند. بنابراین برنامه شما نباید در مورد اینکه کدام برنامه در دسترس است فرضیاتی داشته باشد، زیرا اگر بدون بررسی اینکه آیا برنامه ای برای مدیریت Intent
در دسترس است یا خیر، startActivity()
را فراخوانی کنید، ممکن است برنامه شما در یک نمایه محدود خراب شود.
هنگام استفاده از یک intent ضمنی، همیشه باید با فراخوانی resolveActivity()
یا queryIntentActivities()
بررسی کنید که یک برنامه برای رسیدگی به intent موجود است. به عنوان مثال:
کاتلین
val intent = Intent(Intent.ACTION_SEND) ... if (intent.resolveActivity(packageManager) != null) { startActivity(intent) } else { Toast.makeText(context, R.string.app_not_available, Toast.LENGTH_LONG).show() }
جاوا
Intent intent = new Intent(Intent.ACTION_SEND); ... if (intent.resolveActivity(getPackageManager()) != null) { startActivity(intent); } else { Toast.makeText(context, R.string.app_not_available, Toast.LENGTH_LONG).show(); }
اگر برنامه شما به حسابها وابسته است...
ممکن است برنامه شما در یک محیط نمایه محدود رفتار نادرست داشته باشد.
کاربران در یک محیط پروفایل محدود به طور پیش فرض به حساب های کاربری دسترسی ندارند. اگر برنامه شما به یک Account
وابسته است، ممکن است برنامه شما در هنگام استفاده در یک نمایه محدود از کار بیفتد یا به طور غیرمنتظره ای رفتار کند.
اگر میخواهید به طور کامل از استفاده پروفایلهای محدود شده از برنامه خود جلوگیری کنید زیرا برنامه شما به اطلاعات حساس حساب بستگی دارد، ویژگی android:requiredAccountType
در عنصر <application>
مانیفست خود مشخص کنید.
اگر میخواهید به پروفایلهای محدود شده اجازه دهید به استفاده از برنامه شما ادامه دهند، حتی اگر نمیتوانند حسابهای خود را ایجاد کنند، میتوانید ویژگیهای برنامه خود را که نیاز به یک حساب دارند غیرفعال کنید یا به پروفایلهای محدود اجازه دهید به حسابهای ایجاد شده توسط کاربر اصلی دسترسی داشته باشند. . برای اطلاعات بیشتر، بخش زیر را در مورد پشتیبانی از حسابها در نمایهای محدود ببینید.
اگر برنامه شما از VideoView استفاده می کند...
ممکن است ویدیوی شما در Android 4.3 کوچکتر به نظر برسد.
در نسخههای قبلی Android، ویجت VideoView
مقدار "wrap_content"
را برای layout_height
و layout_width
به اشتباه محاسبه کرد تا با "match_parent"
یکسان شود. بنابراین در حالی که استفاده از "wrap_content"
برای ارتفاع یا عرض ممکن است قبلاً طرحبندی ویدیوی مورد نظر شما را ارائه کرده باشد، انجام این کار ممکن است منجر به ویدیوی بسیار کوچکتری در اندروید 4.3 و بالاتر شود. برای رفع مشکل، "wrap_content"
با "match_parent"
جایگزین کنید و تأیید کنید که ویدیوی شما همانطور که انتظار میرود در Android 4.3 و همچنین در نسخههای قدیمیتر ظاهر شود.
پروفایل های محدود
در تبلتهای اندرویدی، کاربران اکنون میتوانند پروفایلهای محدود شده را بر اساس کاربر اصلی ایجاد کنند. هنگامی که کاربران یک نمایه محدود ایجاد میکنند، میتوانند محدودیتهایی مانند برنامههای موجود در نمایه را فعال کنند. مجموعه جدیدی از APIها در Android 4.3 همچنین به شما امکان میدهد تنظیمات محدودیتهای ریز را برای برنامههایی که توسعه میدهید ایجاد کنید. به عنوان مثال، با استفاده از API های جدید، می توانید به کاربران اجازه دهید هنگام اجرا در یک محیط نمایه محدود، نوع محتوایی را که در برنامه شما موجود است را کنترل کنند.
رابط کاربر برای کنترل محدودیتهایی که ایجاد کردهاید توسط برنامه تنظیمات سیستم مدیریت میشود. برای اینکه تنظیمات محدودیت برنامه خود را به کاربر نشان دهید، باید با ایجاد یک BroadcastReceiver
که هدف ACTION_GET_RESTRICTION_ENTRIES
را دریافت می کند، محدودیت هایی را که برنامه شما ایجاد می کند، اعلام کنید. سیستم این هدف را فراخوانی می کند تا از همه برنامه ها برای محدودیت های موجود پرس و جو کند، سپس رابط کاربری ایجاد می کند تا به کاربر اصلی اجازه دهد محدودیت ها را برای هر نمایه محدود شده مدیریت کند.
در متد onReceive()
BroadcastReceiver
، باید برای هر محدودیتی که برنامه شما ایجاد می کند، یک RestrictionEntry
ایجاد کنید. هر RestrictionEntry
یک عنوان محدودیت، توضیحات و یکی از انواع داده های زیر را تعریف می کند:
-
TYPE_BOOLEAN
برای محدودیتی که درست یا نادرست است. -
TYPE_CHOICE
برای محدودیتی که چندین انتخاب دارد که متقابلاً منحصر به فرد هستند (انتخاب دکمه های رادیویی). -
TYPE_MULTI_SELECT
برای محدودیتی که دارای چندین انتخاب است که متقابلاً انحصاری نیستند (انتخابهای کادر تأیید).
سپس تمام اشیاء RestrictionEntry
را در یک ArrayList
قرار داده و آن را به عنوان مقدار اضافی EXTRA_RESTRICTIONS_LIST
در نتیجه گیرنده پخش قرار دهید.
این سیستم رابط کاربری محدودیتهای برنامه شما را در برنامه تنظیمات ایجاد میکند و هر محدودیت را با کلید منحصربهفردی که برای هر شی RestrictionEntry
ارائه کردهاید ذخیره میکند. وقتی کاربر برنامه شما را باز میکند، میتوانید با فراخوانی getApplicationRestrictions()
هرگونه محدودیت فعلی را درخواست کنید. این یک Bundle
حاوی جفتهای کلید-مقدار برای هر محدودیتی را که با اشیاء RestrictionEntry
تعریف کردهاید، برمیگرداند.
اگر میخواهید محدودیتهای خاصتری ارائه کنید که با مقادیر بولی، تک انتخابی و چند گزینهای قابل کنترل نباشد، میتوانید فعالیتی ایجاد کنید که در آن کاربر بتواند محدودیتها را مشخص کند و به کاربران اجازه دهد آن فعالیت را از تنظیمات محدودیت باز کنند. . در گیرنده پخش خود، EXTRA_RESTRICTIONS_INTENT
اضافی را در Bundle
نتیجه اضافه کنید. این اضافی باید یک Intent
را مشخص کند که کلاس Activity
را برای راهاندازی نشان میدهد (از متد putParcelable()
برای عبور EXTRA_RESTRICTIONS_INTENT
با intent استفاده کنید. وقتی کاربر اصلی برای تنظیم محدودیتهای سفارشی، فعالیت شما را وارد میکند، فعالیت شما باید نتیجهای حاوی مقادیر محدودیت را با استفاده از کلید EXTRA_RESTRICTIONS_LIST
یا EXTRA_RESTRICTIONS_BUNDLE
برگرداند، بسته به اینکه به ترتیب اشیاء RestrictionEntry
یا جفتهای کلید-مقدار را مشخص کنید.
پشتیبانی از حساب ها در یک نمایه محدود
هر حسابی که به کاربر اصلی اضافه میشود، برای یک نمایه محدود در دسترس است، اما به طور پیشفرض، حسابها از طریق APIهای AccountManager
قابل دسترسی نیستند. اگر در حالی که در یک نمایه محدود هستید سعی کنید حسابی را با AccountManager
اضافه کنید، نتیجه شکست خواهید داشت. با توجه به این محدودیت ها، شما سه گزینه زیر را دارید:
برای دسترسی به یک حساب کاربری از یک نمایه محدود، باید ویژگی android:restrictedAccountType
به تگ <application> اضافه کنید:
<application ... android:restrictedAccountType="com.example.account.type" >
احتیاط: با فعال کردن این ویژگی، برنامه شما از نمایههای محدود شده به حسابهای کاربر اصلی دسترسی پیدا میکند. بنابراین، تنها در صورتی باید این اجازه را بدهید که اطلاعات نمایش داده شده توسط برنامه شما، اطلاعات قابل شناسایی شخصی (PII) را که حساس تلقی می شوند، نشان ندهد. تنظیمات سیستم به کاربر اصلی اطلاع میدهد که برنامه شما نمایههای محدودی را به حسابهایش اعطا میکند، بنابراین باید برای کاربر روشن باشد که دسترسی به حساب برای عملکرد برنامه شما مهم است. در صورت امکان، باید کنترلهای محدودیت کافی را برای کاربر اصلی نیز ارائه دهید که تعیین میکند چه مقدار دسترسی به حساب در برنامه شما مجاز است.
اگر میخواهید از حسابها استفاده کنید، اما در واقع به آنها برای عملکرد اصلی برنامهتان نیاز ندارید، میتوانید در دسترس بودن حساب را بررسی کنید و وقتی در دسترس نیست، ویژگیها را غیرفعال کنید. ابتدا باید بررسی کنید که آیا یک حساب کاربری موجود وجود دارد یا خیر. در غیر این صورت، امکان ایجاد یک حساب کاربری جدید را با فراخوانی getUserRestrictions()
بپرسید و DISALLOW_MODIFY_ACCOUNTS
اضافی را در نتیجه بررسی کنید. اگر true
است، باید هر عملکردی را که برنامه شما نیاز به دسترسی به حسابها دارد، غیرفعال کنید. به عنوان مثال:
کاتلین
val um = context.getSystemService(Context.USER_SERVICE) as UserManager val restrictions: Bundle = um.userRestrictions if (restrictions.getBoolean(UserManager.DISALLOW_MODIFY_ACCOUNTS, false)) { // cannot add accounts, disable some functionality }
جاوا
UserManager um = (UserManager) context.getSystemService(Context.USER_SERVICE); Bundle restrictions = um.getUserRestrictions(); if (restrictions.getBoolean(UserManager.DISALLOW_MODIFY_ACCOUNTS, false)) { // cannot add accounts, disable some functionality }
توجه: در این سناریو، نباید هیچ ویژگی جدیدی را در فایل مانیفست خود اعلام کنید.
اگر در عوض مهم است که برنامه شما برای نمایههای محدود در دسترس نباشد زیرا برنامه شما به اطلاعات شخصی حساس در یک حساب وابسته است (و از آنجا که نمایههای محدود در حال حاضر نمیتوانند حسابهای جدیدی اضافه کنند)، ویژگی android:requiredAccountType
را به تگ <application> اضافه کنید:
<application ... android:requiredAccountType="com.example.account.type" >
به عنوان مثال، برنامه Gmail از این ویژگی برای غیرفعال کردن خود برای نمایه های محدود استفاده می کند، زیرا ایمیل شخصی مالک نباید برای نمایه های محدود شده در دسترس باشد.
بی سیم و اتصال
بلوتوث کم انرژی (آماده هوشمند)
اندروید اکنون از بلوتوث کم انرژی (LE) با API های جدید در android.bluetooth
پشتیبانی می کند. با API های جدید، می توانید برنامه های اندرویدی بسازید که با وسایل جانبی کم انرژی بلوتوث مانند نمایشگر ضربان قلب و گام شمار ارتباط برقرار کنند.
از آنجایی که Bluetooth LE یک ویژگی سخت افزاری است که در همه دستگاه های مجهز به Android در دسترس نیست، باید در فایل مانیفست خود عنصر <uses-feature>
را برای "android.hardware.bluetooth_le"
اعلام کنید:
<uses-feature android:name="android.hardware.bluetooth_le" android:required="true" />
اگر قبلاً با API های بلوتوث کلاسیک اندروید آشنا هستید، توجه داشته باشید که استفاده از API های بلوتوث LE تفاوت هایی دارد. مهمتر از همه این است که در حال حاضر یک کلاس BluetoothManager
وجود دارد که باید برای برخی از عملیات های سطح بالا مانند به دست آوردن BluetoothAdapter
، دریافت لیستی از دستگاه های متصل و بررسی وضعیت یک دستگاه استفاده کنید. برای مثال، نحوه دریافت BluetoothAdapter
به این صورت است:
کاتلین
val bluetoothManager = getSystemService(Context.BLUETOOTH_SERVICE) as BluetoothManager bluetoothAdapter = bluetoothManager.adapter
جاوا
final BluetoothManager bluetoothManager = (BluetoothManager) getSystemService(Context.BLUETOOTH_SERVICE); bluetoothAdapter = bluetoothManager.getAdapter();
برای کشف لوازم جانبی بلوتوث LE، startLeScan()
را در BluetoothAdapter
فراخوانی کنید و آن را به عنوان پیاده سازی رابط BluetoothAdapter.LeScanCallback
ارسال کنید. هنگامی که آداپتور بلوتوث یک وسیله جانبی بلوتوث LE را شناسایی می کند، اجرای BluetoothAdapter.LeScanCallback
شما تماسی با روش onLeScan()
دریافت می کند. این روش یک شئ BluetoothDevice
که نشان دهنده دستگاه شناسایی شده، مقدار RSSI برای دستگاه، و یک آرایه بایت حاوی رکورد تبلیغات دستگاه است را در اختیار شما قرار می دهد.
اگر میخواهید فقط انواع خاصی از تجهیزات جانبی را اسکن کنید، میتوانید در عوض startLeScan()
را فراخوانی کنید و آرایهای از اشیاء UUID
را اضافه کنید که سرویسهای GATT را که برنامه شما پشتیبانی میکند را مشخص کنید.
توجه: فقط میتوانید دستگاههای بلوتوث LE یا دستگاههای بلوتوث کلاسیک را با استفاده از APIهای قبلی اسکن کنید. شما نمی توانید هر دو دستگاه بلوتوث LE و کلاسیک را به طور همزمان اسکن کنید.
سپس برای اتصال به یک دستگاه جانبی بلوتوث LE، connectGatt()
را در شیء BluetoothDevice
مربوطه فراخوانی کنید و آن را به عنوان اجرای BluetoothGattCallback
ارسال کنید. اجرای BluetoothGattCallback
شما در رابطه با وضعیت اتصال با دستگاه و رویدادهای دیگر، تماسهایی را دریافت میکند. در حین فراخوانی onConnectionStateChange()
است که اگر متد STATE_CONNECTED
را به عنوان حالت جدید عبور دهد، میتوانید با دستگاه ارتباط برقرار کنید.
دسترسی به ویژگیهای بلوتوث در یک دستگاه همچنین مستلزم این است که برنامه شما مجوزهای کاربر بلوتوث خاصی را درخواست کند. برای اطلاعات بیشتر، راهنمای API کم مصرف بلوتوث را ببینید.
حالت فقط اسکن Wi-Fi
هنگام تلاش برای شناسایی مکان کاربر، Android ممکن است از Wi-Fi برای کمک به تعیین مکان با اسکن نقاط دسترسی نزدیک استفاده کند. با این حال، کاربران اغلب برای صرفه جویی در مصرف باتری، Wi-Fi را خاموش نگه میدارند و در نتیجه دادههای مکان دقیقتر هستند. اندروید اکنون دارای یک حالت فقط اسکن است که به Wi-Fi دستگاه اجازه میدهد نقاط دسترسی را اسکن کند تا بدون اتصال به نقطه دسترسی، موقعیت مکانی را به دست آورد، بنابراین مصرف باتری را تا حد زیادی کاهش میدهد.
اگر میخواهید موقعیت مکانی کاربر را بدست آورید اما Wi-Fi در حال حاضر خاموش است، میتوانید با فراخوانی startActivity()
با عملکرد ACTION_REQUEST_SCAN_ALWAYS_AVAILABLE
از کاربر درخواست کنید حالت فقط اسکن Wi-Fi را فعال کند.
پیکربندی Wi-Fi
APIهای جدید WifiEnterpriseConfig
به سرویسهای سازمانی اجازه میدهند تا پیکربندی Wi-Fi را برای دستگاههای مدیریتشده خودکار کنند.
پاسخ سریع برای تماس های دریافتی
از اندروید 4.0، قابلیتی به نام «پاسخ سریع» به کاربران این امکان را میدهد تا بدون نیاز به دریافت تماس یا باز کردن قفل دستگاه، به تماسهای دریافتی با یک پیام متنی فوری پاسخ دهند. تا به حال، این پیامهای سریع همیشه توسط برنامه پیامرسانی پیشفرض مدیریت میشد. اکنون هر برنامهای میتواند با ایجاد یک Service
با فیلتر قصد برای ACTION_RESPOND_VIA_MESSAGE
، توانایی خود را برای مدیریت این پیامها اعلام کند.
هنگامی که کاربر به تماس ورودی با پاسخ سریع پاسخ میدهد، برنامه تلفن هدف ACTION_RESPOND_VIA_MESSAGE
را با یک URI که گیرنده (تماسگیرنده) را توصیف میکند و EXTRA_TEXT
اضافی را با پیامی که کاربر میخواهد ارسال کند، ارسال میکند. وقتی سرویس شما هدف را دریافت کرد، باید پیام را ارسال کند و بلافاصله متوقف شود (برنامه شما نباید فعالیتی را نشان دهد).
برای دریافت این هدف، باید مجوز SEND_RESPOND_VIA_MESSAGE
را اعلام کنید.
چند رسانه ای
بهبود MediaExtractor و MediaCodec
Android اکنون نوشتن جریان تطبیقی پویا خود را بر روی پخش کننده های HTTP (DASH) مطابق با استاندارد ISO/IEC 23009-1 با استفاده از API های موجود در MediaCodec
و MediaExtractor
آسان تر می کند. چارچوب زیربنای این APIها برای پشتیبانی از تجزیه فایل های MP4 تکه تکه شده به روز شده است، اما برنامه شما همچنان مسئول تجزیه فراداده MPD و ارسال جریان های جداگانه به MediaExtractor
است.
اگر می خواهید از DASH با محتوای رمزگذاری شده استفاده کنید، توجه کنید که متد getSampleCryptoInfo()
فراداده MediaCodec.CryptoInfo
را برمی گرداند که ساختار هر نمونه رسانه رمزگذاری شده را توصیف می کند. همچنین، متد getPsshInfo()
به MediaExtractor
اضافه شده است تا بتوانید به ابرداده PSSH برای رسانه DASH خود دسترسی داشته باشید. این روش نقشه ای از اشیاء UUID
را به بایت ها برمی گرداند، با UUID
که طرح کریپتو را مشخص می کند، و بایت ها داده های خاص آن طرح هستند.
رسانه DRM
کلاس MediaDrm
جدید یک راه حل مدولار برای مدیریت حقوق دیجیتال (DRM) با محتوای رسانه ای شما با جدا کردن نگرانی های DRM از پخش رسانه ارائه می دهد. به عنوان مثال، این جداسازی API به شما امکان می دهد محتوای رمزگذاری شده با Widevine را بدون نیاز به استفاده از فرمت رسانه Widevine پخش کنید. این راهحل DRM از رمزگذاری مشترک DASH نیز پشتیبانی میکند تا بتوانید از انواع طرحهای DRM با محتوای پخش خود استفاده کنید.
میتوانید از MediaDrm
برای دریافت پیامهای درخواست کلید غیرشفاف و پردازش پیامهای پاسخ کلیدی از سرور برای دریافت مجوز و تهیه استفاده کنید. برنامه شما مسئول مدیریت ارتباط شبکه با سرورها است. کلاس MediaDrm
تنها توانایی تولید و پردازش پیام ها را فراهم می کند.
APIهای MediaDrm
برای استفاده همراه با APIهای MediaCodec
که در Android 4.1 (سطح API 16) معرفی شدند، از جمله MediaCodec
برای رمزگذاری و رمزگشایی محتوای شما، MediaCrypto
برای مدیریت محتوای رمزگذاری شده و MediaExtractor
برای استخراج و حذف محتوای شما استفاده میشوند.
ابتدا باید اشیاء MediaExtractor
و MediaCodec
را بسازید. سپس می توانید به UUID
شناسایی کننده طرح DRM، معمولاً از فراداده در محتوا، دسترسی داشته باشید و از آن برای ساختن نمونه ای از یک شی MediaDrm
با سازنده آن استفاده کنید.
رمزگذاری ویدیو از یک Surface
Android 4.1 (سطح API 16) کلاس MediaCodec
را برای رمزگذاری و رمزگشایی سطح پایین محتوای رسانه اضافه کرد. هنگام رمزگذاری ویدیو، Android 4.1 نیاز داشت که یک آرایه ByteBuffer
برای رسانه ارائه کنید، اما Android 4.3 اکنون به شما امکان می دهد از یک Surface
به عنوان ورودی رمزگذار استفاده کنید. به عنوان مثال، این به شما امکان می دهد ورودی را از یک فایل ویدیویی موجود یا با استفاده از فریم های تولید شده از OpenGL ES رمزگذاری کنید.
برای استفاده از Surface
به عنوان ورودی رمزگذار خود، ابتدا configure()
برای MediaCodec
خود فراخوانی کنید. سپس createInputSurface()
را فراخوانی کنید تا Surface
را دریافت کنید که می توانید رسانه خود را روی آن استریم کنید.
برای مثال، میتوانید از Surface
دادهشده بهعنوان پنجرهای برای یک متن OpenGL با ارسال آن به eglCreateWindowSurface()
استفاده کنید. سپس هنگام رندر کردن سطح، eglSwapBuffers()
را فراخوانی کنید تا فریم را به MediaCodec
ارسال کنید.
برای شروع رمزگذاری، start()
را در MediaCodec
فراخوانی کنید. پس از اتمام، signalEndOfInputStream()
برای پایان دادن به کدگذاری فراخوانی کنید و release()
را روی Surface
فراخوانی کنید.
مزاحمت رسانه ای
کلاس MediaMuxer
جدید امکان مالتی پلکس شدن بین یک جریان صوتی و یک جریان ویدئو را فراهم می کند. این APIها بهعنوان همتای کلاس MediaExtractor
اضافه شده در اندروید 4.2 برای مالتیپلکسزدایی (دمکسسازی) رسانهها عمل میکنند.
فرمت های خروجی پشتیبانی شده در MediaMuxer.OutputFormat
تعریف شده اند. در حال حاضر، MP4 تنها فرمت خروجی پشتیبانی شده است و MediaMuxer
در حال حاضر تنها از یک جریان صوتی و/یا یک جریان ویدئو در یک زمان پشتیبانی می کند.
MediaMuxer
بیشتر برای کار با MediaCodec
طراحی شده است، بنابراین می توانید پردازش ویدیو را از طریق MediaCodec
انجام دهید و سپس خروجی را از طریق MediaMuxer
در یک فایل MP4 ذخیره کنید. همچنین می توانید از MediaMuxer
در ترکیب با MediaExtractor
برای انجام ویرایش رسانه بدون نیاز به رمزگذاری یا رمزگشایی استفاده کنید.
پیشرفت پخش و تمیز کردن برای RemoteControlClient
در Android 4.0 (سطح API 14)، RemoteControlClient
اضافه شد تا کنترلهای پخش رسانه از کلاینتهای کنترل از راه دور مانند کنترلهای موجود در صفحه قفل را فعال کند. اکنون اندروید 4.3 این امکان را برای چنین کنترلهایی فراهم میکند که موقعیت پخش و کنترلهایی را برای پاک کردن پخش نمایش دهند. اگر کنترل از راه دور را برای برنامه رسانه خود با API های RemoteControlClient
فعال کرده اید، می توانید با پیاده سازی دو رابط جدید اجازه پاکسازی پخش را بدهید.
ابتدا باید پرچم FLAG_KEY_MEDIA_POSITION_UPDATE
را با ارسال آن به setTransportControlsFlags()
فعال کنید.
سپس دو رابط جدید زیر را پیاده سازی کنید:
-
RemoteControlClient.OnGetPlaybackPositionListener
- این شامل callback
onGetPlaybackPosition()
است که موقعیت فعلی رسانه شما را زمانی که کنترل از راه دور نیاز به به روز رسانی پیشرفت در رابط کاربری خود دارد درخواست می کند. -
RemoteControlClient.OnPlaybackPositionUpdateListener
- این شامل callback
onPlaybackPositionUpdate()
میشود که وقتی کاربر پخش را با رابط کاربری کنترل از راه دور پاک میکند، کد زمان جدید رسانه شما را به برنامه شما میگوید.هنگامی که پخش خود را با موقعیت جدید به روز کردید،
setPlaybackState()
را فراخوانی کنید تا وضعیت، موقعیت و سرعت پخش جدید را نشان دهد.
با تعریف این رابطها، میتوانید با فراخوانی setOnGetPlaybackPositionListener()
و setPlaybackPositionUpdateListener()
آنها را برای RemoteControlClient
خود تنظیم کنید.
گرافیک
پشتیبانی از OpenGL ES 3.0
اندروید 4.3 رابط های جاوا و پشتیبانی بومی را برای OpenGL ES 3.0 اضافه می کند. عملکردهای کلیدی جدید ارائه شده در OpenGL ES 3.0 شامل موارد زیر است:
- تسریع جلوه های بصری پیشرفته
- فشرده سازی بافت ETC2/EAC با کیفیت بالا به عنوان یک ویژگی استاندارد
- نسخه جدیدی از زبان سایه بان GLSL ES با پشتیبانی از اعداد صحیح و ممیز شناور 32 بیتی
- رندر بافت پیشرفته
- استانداردسازی گستردهتر اندازه بافت و فرمتهای رندر بافر
رابط جاوا برای OpenGL ES 3.0 در اندروید با GLES30
ارائه شده است. هنگام استفاده از OpenGL ES 3.0، مطمئن شوید که آن را در فایل مانیفست خود با تگ <uses-feature> و ویژگی android:glEsVersion
اعلام کرده اید. به عنوان مثال:
<manifest> <uses-feature android:glEsVersion="0x00030000" /> ... </manifest>
و به یاد داشته باشید که متن OpenGL ES را با فراخوانی setEGLContextClientVersion()
مشخص کنید و 3
را به عنوان نسخه ارسال کنید.
برای اطلاعات بیشتر در مورد استفاده از OpenGL ES، از جمله نحوه بررسی نسخه پشتیبانی شده OpenGL ES دستگاه در زمان اجرا، راهنمای OpenGL ES API را ببینید.
Mipmapping برای نقشه کشی ها
استفاده از mipmap به عنوان منبع بیت مپ یا قابل ترسیم یک راه ساده برای ارائه یک تصویر با کیفیت و مقیاس های مختلف تصویر است که اگر انتظار دارید تصویر شما در طول یک انیمیشن کوچک شود، می تواند مفید باشد.
Android 4.2 (سطح API 17) پشتیبانی از mipmaps را در کلاس Bitmap
اضافه کرد—Android تصاویر mip را در Bitmap
شما تعویض می کند زمانی که منبع mipmap را ارائه کرده باشید و setHasMipMap()
را فعال کرده باشید. اکنون در اندروید 4.3، میتوانید mipmaps را برای یک شی BitmapDrawable
نیز با ارائه یک دارایی mipmap و تنظیم ویژگی android:mipMap
در یک فایل منبع بیت مپ یا با فراخوانی hasMipMap()
فعال کنید.
رابط کاربری
مشاهده همپوشانی ها
کلاس ViewOverlay
جدید یک لایه شفاف در بالای View
ارائه می دهد که می توانید محتوای بصری را روی آن اضافه کنید و سلسله مراتب طرح بندی را تحت تاثیر قرار نمی دهد. می توانید با فراخوانی getOverlay()
یک ViewOverlay
برای هر View
دریافت کنید. همپوشانی همیشه اندازه و موقعیت یکسانی با نمای میزبان خود دارد (نمایی که از آن ایجاد شده است)، به شما امکان می دهد محتوایی را اضافه کنید که در جلوی نمای میزبان ظاهر می شود، اما نمی تواند محدوده آن نمای میزبان را گسترش دهد.
استفاده از ViewOverlay
مخصوصاً زمانی مفید است که میخواهید انیمیشنهایی مانند لغزش نما به خارج از ظرف آن یا حرکت دادن آیتمها در اطراف صفحه بدون تأثیر بر سلسلهمراتب نمایش ایجاد کنید. با این حال، از آنجایی که ناحیه قابل استفاده یک همپوشانی محدود به همان ناحیه نمای میزبان آن است، اگر میخواهید نمایی را متحرک کنید که خارج از موقعیت خود در طرحبندی حرکت میکند، باید از یک همپوشانی از نمای والد استفاده کنید که دارای محدودههای طرحبندی مورد نظر است. .
هنگامی که یک پوشش برای نمای ویجت مانند یک Button
ایجاد می کنید، می توانید با فراخوانی add(Drawable)
اشیای Drawable
را به پوشش اضافه کنید. اگر getOverlay()
برای یک نمای طرح بندی، مانند RelativeLayout
، فراخوانی کنید، شی برگردانده شده یک ViewGroupOverlay
است. کلاس ViewGroupOverlay
یک زیر کلاس از ViewOverlay
است که به شما امکان می دهد با فراخوانی add(View)
اشیاء View
را اضافه کنید.
توجه: همه طرحها و نماهایی که به یک پوشش اضافه میکنید فقط بصری هستند. آنها نمی توانند رویدادهای کانونی یا ورودی را دریافت کنند.
برای مثال، کد زیر با قرار دادن نما در همپوشانی نمای والد، یک نما را متحرک می کند که به سمت راست می لغزد و سپس یک انیمیشن ترجمه را روی آن نمای انجام می دهد:
کاتلین
val view: View? = findViewById(R.id.view_to_remove) val container: ViewGroup? = view?.parent as ViewGroup container?.apply { overlay.add(view) ObjectAnimator.ofFloat(view, "translationX", right.toFloat()) .start() }
جاوا
View view = findViewById(R.id.view_to_remove); ViewGroup container = (ViewGroup) view.getParent(); container.getOverlay().add(view); ObjectAnimator anim = ObjectAnimator.ofFloat(view, "translationX", container.getRight()); anim.start();
طرح کرانه های نوری
برای نماهایی که حاوی تصاویر پسزمینه نه وصلهای هستند، اکنون میتوانید تعیین کنید که آنها باید با نماهای همسایه بر اساس مرزهای "اپتیکال" تصویر پسزمینه به جای مرزهای "کلیپ" نما تراز شوند.
برای مثال، شکلهای 1 و 2 هر کدام طرحبندی یکسانی را نشان میدهند، اما نسخه در شکل 1 از کرانهای کلیپ (رفتار پیشفرض) استفاده میکند، در حالی که شکل 2 از کرانهای نوری استفاده میکند. از آنجایی که تصاویر نه وصلهای که برای دکمه و قاب عکس استفاده میشوند شامل لایهبندی در اطراف لبهها میشوند، به نظر نمیرسد هنگام استفاده از کرانهای کلیپ با یکدیگر یا متن تراز شوند.
توجه: اسکرین شات در شکلهای 1 و 2 دارای تنظیمات برنامهنویس «نمایش محدودههای طرحبندی» است. برای هر نما، خطوط قرمز مرزهای نوری، خطوط آبی مرزهای کلیپ و صورتی نشان دهنده حاشیه ها هستند.
برای تراز کردن نماها بر اساس مرزهای نوری آنها، ویژگی android:layoutMode
روی "opticalBounds"
در یکی از طرحبندیهای والد تنظیم کنید. به عنوان مثال:
<LinearLayout android:layoutMode="opticalBounds" ... >
برای این کار، تصاویر 9 پچ اعمال شده بر روی پسزمینه نماهای شما باید با استفاده از خطوط قرمز در امتداد پایین و سمت راست فایل نه پچ، مرزهای نوری را مشخص کنند (همانطور که در شکل 3 نشان داده شده است). خطوط قرمز ناحیه ای را نشان می دهد که باید از مرزهای کلیپ کم شود و مرزهای نوری تصویر باقی بماند.
وقتی مرزهای نوری را برای یک ViewGroup
در طرحبندی خود فعال میکنید، همه نماهای نسلدار حالت طرحبندی محدوده نوری را به ارث میبرند، مگر اینکه با تنظیم android:layoutMode
روی "clipBounds"
، آن را برای گروهی لغو کنید. همه عناصر چیدمان نیز به مرزهای نوری نماهای فرزند خود احترام می گذارند و محدوده های خود را بر اساس محدوده های نوری نماهای درون آنها تطبیق می دهند. با این حال، عناصر طرحبندی (زیر کلاسهای ViewGroup
) در حال حاضر از کرانهای نوری برای تصاویر ۹ پچ اعمال شده در پسزمینه خود پشتیبانی نمیکنند.
اگر یک نمای سفارشی را با زیر کلاس بندی View
، ViewGroup
یا هر زیر کلاس آنها ایجاد کنید، نمای شما این رفتارهای محدود نوری را به ارث می برد.
توجه: تمام ویجت های پشتیبانی شده توسط تم Holo با کران های نوری، از جمله Button
، Spinner
، EditText
و موارد دیگر به روز شده اند. بنابراین اگر برنامه شما از یک تم Holo ( Theme.Holo
، Theme.Holo.Light
و غیره) استفاده میکند، میتوانید فوراً با تنظیم ویژگی android:layoutMode
روی "opticalBounds"
سود ببرید.
برای تعیین مرزهای نوری برای تصاویر 9 پچ خود با ابزار Draw 9-patch ، هنگام کلیک کردن بر روی پیکسل های حاشیه، Control را نگه دارید.
انیمیشن برای مقادیر Rect
اکنون می توانید بین دو مقدار Rect
با RectEvaluator
جدید متحرک سازی کنید. این کلاس جدید پیاده سازی TypeEvaluator
است که می توانید آن را به ValueAnimator.setEvaluator()
منتقل کنید.
اتصال پنجره و شنونده متمرکز
قبلاً، اگر میخواستید به زمانی که نمای شما به پنجره متصل/ جدا میشود یا زمانی که فوکوس آن تغییر میکند گوش دهید، باید کلاس View
را برای پیادهسازی onAttachedToWindow()
و onDetachedFromWindow()
یا onWindowFocusChanged()
رد کنید.
اکنون، برای دریافت پیوست و جدا کردن رویدادها، میتوانید در عوض ViewTreeObserver.OnWindowAttachListener
پیادهسازی کنید و با addOnWindowAttachListener()
آن را روی یک view تنظیم کنید. و برای دریافت رویدادهای فوکوس، میتوانید ViewTreeObserver.OnWindowFocusChangeListener
را پیادهسازی کنید و با addOnWindowFocusChangeListener()
آن را روی یک view تنظیم کنید.
پشتیبانی از اسکن تلویزیون
برای اطمینان از اینکه برنامه شما تمام صفحه نمایش هر تلویزیون را پر می کند، اکنون می توانید Overscan را برای طرح بندی برنامه خود فعال کنید. حالت Overscan توسط پرچم FLAG_LAYOUT_IN_OVERSCAN
تعیین میشود، که میتوانید با تمهای پلتفرم مانند Theme_DeviceDefault_NoActionBar_Overscan
یا با فعال کردن سبک windowOverscan
در یک موضوع سفارشی فعال کنید.
جهت صفحه نمایش
ویژگی screenOrientation
تگ <activity>
اکنون از مقادیر اضافی برای رعایت اولویت کاربر برای چرخش خودکار پشتیبانی می کند:
-
"userLandscape"
- مانند
"sensorLandscape"
عمل می کند، به جز اگر کاربر چرخش خودکار را غیرفعال کند، در جهت افقی معمولی قفل می شود و نمی چرخد. -
"userPortrait"
- مانند
"sensorPortrait"
عمل می کند، به جز اگر کاربر چرخش خودکار را غیرفعال کند، سپس در جهت عمودی معمولی قفل می شود و نمی چرخد. -
"fullUser"
- مانند
"fullSensor"
عمل می کند و امکان چرخش را در هر چهار جهت می دهد، مگر اینکه کاربر چرخش خودکار را غیرفعال کند و سپس در جهت دلخواه کاربر قفل شود.
علاوه بر این، اکنون می توانید برای قفل کردن جهت برنامه خود در جهت فعلی صفحه "locked"
نیز اعلام کنید.
انیمیشن های چرخشی
فیلد جدید rotationAnimation
در WindowManager
به شما امکان میدهد یکی از سه انیمیشنی را که میخواهید هنگام تغییر جهتهای صفحه نمایش استفاده کنید، انتخاب کنید. این سه انیمیشن عبارتند از:
توجه: این انیمیشن ها فقط در صورتی در دسترس هستند که فعالیت خود را برای استفاده از حالت "تمام صفحه" تنظیم کرده باشید، که می توانید با تم هایی مانند Theme.Holo.NoActionBar.Fullscreen
فعال کنید.
به عنوان مثال، در اینجا نحوه فعال کردن انیمیشن "crossfade" آمده است:
کاتلین
override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) val params: WindowManager.LayoutParams = window.attributes params.rotationAnimation = WindowManager.LayoutParams.ROTATION_ANIMATION_CROSSFADE window.attributes = params ... }
جاوا
protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); WindowManager.LayoutParams params = getWindow().getAttributes(); params.rotationAnimation = WindowManager.LayoutParams.ROTATION_ANIMATION_CROSSFADE; getWindow().setAttributes(params); ... }
ورودی کاربر
انواع سنسور جدید
سنسور جدید TYPE_GAME_ROTATION_VECTOR
به شما امکان می دهد بدون نگرانی از تداخل های مغناطیسی، چرخش های دستگاه را تشخیص دهید. برخلاف حسگر TYPE_ROTATION_VECTOR
، TYPE_GAME_ROTATION_VECTOR
مبتنی بر شمال مغناطیسی نیست.
حسگرهای جدید TYPE_GYROSCOPE_UNCALIBRATED
و TYPE_MAGNETIC_FIELD_UNCALIBRATED
دادههای خام حسگر را بدون در نظر گرفتن برآوردهای سوگیری ارائه میکنند. یعنی سنسورهای TYPE_GYROSCOPE
و TYPE_MAGNETIC_FIELD
موجود، دادههای حسگر را ارائه میکنند که به ترتیب بایاس تخمینی ناشی از ژیروسکوپ و آهن سخت در دستگاه را در نظر میگیرد. در حالی که نسخههای جدید "غیر کالیبره" این حسگرها در عوض دادههای خام حسگر را ارائه میدهند و مقادیر بایاس تخمینی را جداگانه ارائه میدهند. این حسگرها به شما این امکان را میدهند که کالیبراسیون سفارشی خود را برای دادههای حسگر با افزایش تعصب تخمینی با دادههای خارجی ارائه دهید.
شنونده اعلان
Android 4.3 یک کلاس سرویس جدید به نام NotificationListenerService
اضافه می کند که به برنامه شما امکان می دهد اطلاعات مربوط به اعلان های جدید را همانطور که توسط سیستم ارسال می شود دریافت کند.
اگر برنامه شما در حال حاضر از APIهای سرویس دسترسپذیری برای دسترسی به اعلانهای سیستم استفاده میکند، باید برنامه خود را برای استفاده از این APIها بهروز کنید.
ارائه دهنده مخاطبین
پرس و جو برای "قابل تماس"
جستجوی جدید ارائهدهنده مخاطبین، Contactables.CONTENT_URI
، یک راه کارآمد برای دریافت یک Cursor
ارائه میدهد که شامل همه آدرسهای ایمیل و شماره تلفن متعلق به همه مخاطبین منطبق با عبارت جستجوی مشخص شده است.
پرس و جو برای دلتاهای مخاطبین
API های جدیدی به Contacts Provider اضافه شده است که به شما امکان می دهد تغییرات اخیر در داده های مخاطبین را به طور مؤثر جستجو کنید. قبلاً، برنامه شما میتوانست وقتی چیزی در اطلاعات مخاطبین تغییر میکند مطلع شود، اما شما دقیقاً نمیدانستید چه چیزی تغییر کرده است و باید همه مخاطبین را بازیابی کنید و سپس از طریق آنها تکرار کنید تا تغییر را کشف کنید.
برای ردیابی تغییرات در درجها و بهروزرسانیها، اکنون میتوانید پارامتر CONTACT_LAST_UPDATED_TIMESTAMP
را با انتخاب خود بگنجانید تا فقط مخاطبینی را که از آخرین باری که از ارائهدهنده درخواست کردهاید تغییر کردهاند پرس و جو کنید.
برای ردیابی مخاطبین حذف شده، جدول جدید ContactsContract.DeletedContacts
گزارشی از مخاطبین حذف شده را ارائه می دهد (اما هر مخاطب حذف شده برای مدت محدودی در این جدول نگهداری می شود). مشابه CONTACT_LAST_UPDATED_TIMESTAMP
، میتوانید از پارامتر انتخاب جدید، CONTACT_DELETED_TIMESTAMP
استفاده کنید تا بررسی کنید کدام مخاطبین از آخرین باری که از ارائهدهنده سؤال کردهاید، حذف شدهاند. جدول همچنین حاوی DAYS_KEPT_MILLISECONDS
ثابت است که حاوی تعداد روزهای (بر حسب میلی ثانیه) است که گزارش نگهداری می شود.
علاوه بر این، ارائهدهنده مخاطبین اکنون اقدام CONTACTS_DATABASE_CREATED
را هنگامی که کاربر فضای ذخیرهسازی مخاطبین را از طریق منوی تنظیمات سیستم پاک میکند، پخش میکند و به طور موثر پایگاه داده ارائهدهنده مخاطبین را دوباره ایجاد میکند. در نظر گرفته شده است که به برنامهها نشان دهد که باید تمام اطلاعات تماسی را که ذخیره کردهاند حذف کنند و آن را با یک درخواست جدید بارگیری کنند.
برای نمونه کد با استفاده از این APIها برای بررسی تغییرات در مخاطبین، به نمونه ApiDemos موجود در دانلود SDK Samples نگاه کنید.
بومی سازی
پشتیبانی بهبود یافته از متن دو جهته
نسخههای قبلی اندروید از زبانها و طرحبندی از راست به چپ (RTL) پشتیبانی میکنند، اما گاهی اوقات به درستی متنهای با جهت ترکیبی را مدیریت نمیکنند. بنابراین Android 4.3 API های BidiFormatter
را اضافه می کند که به شما کمک می کند متن را با محتوای خلاف جهت فرمت صحیح بدون بهم ریختن قسمتی از آن، قالب بندی کنید.
به عنوان مثال، هنگامی که می خواهید جمله ای با یک متغیر رشته ایجاد کنید، مانند "آیا منظورتان 15 Bay Street, Laurel, CA بود؟"، معمولاً یک منبع رشته محلی و متغیر را به String.format()
ارسال می کنید:
کاتلین
val suggestion = String.format(resources.getString(R.string.did_you_mean), address)
جاوا
Resources res = getResources(); String suggestion = String.format(res.getString(R.string.did_you_mean), address);
با این حال، اگر منطقه زبان عبری باشد، رشته قالب بندی شده به این صورت ظاهر می شود:
האם התכונת ל 15 Bay Street, Laurel, CA؟
این اشتباه است زیرا "15" باید از "Bay Street" باقی بماند. راه حل استفاده از BidiFormatter
و متد unicodeWrap()
آن است. به عنوان مثال، کد بالا تبدیل می شود:
کاتلین
val bidiFormatter = BidiFormatter.getInstance() val suggestion = String.format( resources.getString(R.string.did_you_mean), bidiFormatter.unicodeWrap(address) )
جاوا
Resources res = getResources(); BidiFormatter bidiFormatter = BidiFormatter.getInstance(); String suggestion = String.format(res.getString(R.string.did_you_mean), bidiFormatter.unicodeWrap(address));
بهطور پیشفرض، unicodeWrap()
از اولین اکتشافی تخمین جهتگیری استفاده میکند، که اگر اولین سیگنال برای جهت متن، جهت مناسب را برای کل محتوا نشان ندهد، ممکن است اشتباه کند. در صورت لزوم، میتوانید با انتقال یکی از ثابتهای TextDirectionHeuristic
از TextDirectionHeuristics
به unicodeWrap()
اکتشافی متفاوتی را مشخص کنید.
توجه: این APIهای جدید برای نسخههای قبلی Android از طریق کتابخانه پشتیبانی Android با کلاس BidiFormatter
و APIهای مرتبط نیز در دسترس هستند.
خدمات دسترسی
رویدادهای کلیدی را مدیریت کنید
یک AccessibilityService
اکنون میتواند برای رویدادهای ورودی کلیدی با روش callback onKeyEvent()
یک پاسخ تماس دریافت کند. این به سرویس دسترسپذیری شما اجازه میدهد تا ورودیهای دستگاههای ورودی مبتنی بر کلید مانند صفحهکلید را مدیریت کند و آن رویدادها را به اقدامات خاصی ترجمه کند که قبلاً ممکن بود فقط با ورودی لمسی یا صفحه جهت دستگاه امکانپذیر بوده باشد.
متن را انتخاب کنید و کپی/پیست کنید
AccessibilityNodeInfo
اکنون API ها را فراهم می کند که به یک AccessibilityService
می تواند متن را در یک گره انتخاب ، برش ، کپی و چسباند.
برای مشخص کردن انتخاب متن برای برش یا کپی ، سرویس دسترسی شما می تواند از عمل جدید ، ACTION_SET_SELECTION
استفاده کند ، موقعیت شروع و پایان انتخاب را با ACTION_ARGUMENT_SELECTION_START_INT
و ACTION_ARGUMENT_SELECTION_END_INT
عبور دهید. از طرف دیگر می توانید متن را با دستکاری موقعیت مکان نما با استفاده از عمل موجود ، ACTION_NEXT_AT_MOVEMENT_GRANULARITY
(قبلاً فقط برای حرکت موقعیت مکان نما) انتخاب کنید و اضافه کردن استدلال ACTION_ARGUMENT_EXTEND_SELECTION_BOOLEAN
.
سپس می توانید با ACTION_CUT
، ACTION_COPY
برش داده یا کپی کنید ، سپس بعداً با ACTION_PASTE
چسبانده شوید.
توجه: این API های جدید همچنین برای نسخه های قبلی Android از طریق کتابخانه پشتیبانی Android ، با کلاس AccessibilityNodeInfoCompat
در دسترس هستند.
ویژگی های دسترسی را اعلام کنید
با شروع Android 4.3 ، یک سرویس دسترسی باید قابلیت های دسترسی را در پرونده ابرداده خود اعلام کند تا از ویژگی های خاص دسترسی استفاده کند. اگر توانایی در پرونده ابرداده درخواست نشده باشد ، این ویژگی بدون هیچ گونه OP خواهد بود. برای اعلام قابلیت های دسترسی خدمات خود ، باید از ویژگی های XML استفاده کنید که مطابق با ثابت های مختلف "توانایی" در کلاس AccessibilityServiceInfo
باشد.
به عنوان مثال ، اگر یک سرویس از قابلیت flagRequestFilterKeyEvents
درخواست نکند ، پس از آن رویدادهای کلیدی دریافت نمی کند.
تست و اشکال زدایی
تست خودکار UI
کلاس UiAutomation
جدید API ها را فراهم می کند که به شما امکان می دهد اقدامات کاربر را برای اتوماسیون تست شبیه سازی کنید. با استفاده از API های AccessibilityService
Platformservice ، API UiAutomation
به شما امکان می دهد تا محتوای صفحه را بازرسی کرده و صفحه کلید دلخواه و رویدادهای لمسی را تزریق کنید.
برای به دست آوردن نمونه ای از UiAutomation
، call Instrumentation.getUiAutomation()
. برای این کار ، باید هنگام اجرای InstrumentationTestCase
خود از adb shell
، گزینه -w
را با دستور instrument
تهیه کنید.
با استفاده از نمونه UiAutomation
، می توانید رویدادهای دلخواه را برای آزمایش برنامه خود با فراخوانی executeAndWaitForEvent()
، عبور از آن برای اجرای ، یک دوره زمان Runnable
برای عملیات و اجرای رابط UiAutomation.AccessibilityEventFilter
اجرا کنید. این در UiAutomation.AccessibilityEventFilter
شما است. AccessibilityEventFilter که شما یک تماس دریافت خواهید کرد که به شما امکان می دهد رویدادهایی را که به آنها علاقه مند هستید فیلتر کنید و موفقیت یا عدم موفقیت یک مورد آزمایش خاص را تعیین کنید.
برای مشاهده تمام وقایع در طی یک آزمایش ، اجرای UiAutomation.OnAccessibilityEventListener
ایجاد کرده و آن را به setOnAccessibilityEventListener()
منتقل کنید. رابط شنونده شما هر بار که یک رویداد رخ می دهد ، تماس با onAccessibilityEvent()
دریافت می کند ، و یک شیء AccessibilityEvent
دریافت می کند که این رویداد را توصیف می کند.
انواع مختلفی از عملیات دیگر وجود دارد که API های UiAutomation
در سطح بسیار کمی در معرض نمایش قرار می گیرند تا توسعه ابزارهای تست UI مانند Uiautomator را ترغیب کنند. به عنوان مثال ، UiAutomation
همچنین می تواند:
- رویدادهای ورودی را تزریق کنید
- جهت گیری صفحه را تغییر دهید
- اسکرین شات بگیرید
و از همه مهمتر برای ابزارهای تست UI ، API های UiAutomation
بر خلاف موارد موجود در Instrumentation
، در مرزهای کاربردی کار می کنند.
رویدادهای systrace برای برنامه ها
Android 4.3 کلاس Trace
با دو روش استاتیک ، beginSection()
و endSection()
اضافه می کند ، که به شما امکان می دهد بلوک های کد را با گزارش Systrace تعریف کنید. با ایجاد بخش هایی از کد قابل ردیابی در برنامه خود ، سیاهههای Systrace تجزیه و تحلیل بسیار مفصلی را در مورد مکان های کندی در برنامه شما ارائه می دهند.
برای اطلاعات در مورد استفاده از ابزار Systrace ، تجزیه و تحلیل نمایش و عملکرد با Systrace را بخوانید.
امنیت
فروشگاه کلید Android برای کلیدهای برنامه خصوصی
Android اکنون یک ارائه دهنده امنیتی جاوا را در مرکز KeyStore
با نام Android Key Store ارائه می دهد که به شما امکان می دهد کلیدهای خصوصی را که فقط توسط برنامه خود دیده و استفاده می شود ، تولید و ذخیره کنید. برای بارگیری فروشگاه کلید Android ، "AndroidKeyStore"
به KeyStore.getInstance()
منتقل کنید.
برای مدیریت اعتبار خصوصی برنامه خود در فروشگاه Key Android ، یک کلید جدید با KeyPairGenerator
با KeyPairGeneratorSpec
ایجاد کنید. ابتدا با فراخوانی getInstance()
نمونه ای از KeyPairGenerator
را دریافت کنید. سپس initialize()
تماس بگیرید ، و نمونه ای از KeyPairGeneratorSpec
را منتقل کنید ، که می توانید با استفاده از KeyPairGeneratorSpec.Builder
دریافت کنید. در آخر ، با فراخوانی generateKeyPair()
KeyPair
خود را دریافت کنید.
ذخیره اعتبار سخت افزاری
Android همچنین اکنون از ذخیره سازی پشت سخت افزار برای اعتبارنامه های KeyChain
شما پشتیبانی می کند و با ایجاد کلیدها برای استخراج ، امنیت بیشتری را فراهم می کند. یعنی ، هنگامی که کلیدها در یک فروشگاه کلیدی تحت حمایت سخت افزار (عنصر ایمن ، TPM یا TrustZone) قرار دارند ، می توان آنها را برای عملیات رمزنگاری مورد استفاده قرار داد اما مواد کلیدی خصوصی را نمی توان صادر کرد. حتی هسته سیستم عامل نمی تواند به این ماده کلیدی دسترسی پیدا کند. در حالی که همه دستگاه های دارای Android از ذخیره سازی از سخت افزار پشتیبانی نمی کنند ، می توانید در زمان اجرا بررسی کنید که آیا ذخیره سازی با پشت سخت افزار با فراخوانی KeyChain.IsBoundKeyAlgorithm()
در دسترس است.
اعلامیه های آشکار
ویژگی های مورد نیاز قابل اعلام
مقادیر زیر اکنون در عنصر <uses-feature>
پشتیبانی می شوند ، بنابراین می توانید اطمینان حاصل کنید که برنامه شما فقط در دستگاه هایی که ویژگی های برنامه شما را ارائه می دهند ، نصب شده است.
-
FEATURE_APP_WIDGETS
- اعلام می کند که برنامه شما یک ویجت برنامه را فراهم می کند و فقط باید در دستگاه هایی که شامل صفحه اصلی یا مکان مشابهی هستند که در آن کاربران می توانند ابزارک های برنامه را تعبیه کنند ، نصب شود. مثال:
<uses-feature android:name="android.software.app_widgets" android:required="true" />
-
FEATURE_HOME_SCREEN
- اعلام می کند که برنامه شما به عنوان جایگزینی صفحه اصلی رفتار می کند و فقط باید در دستگاه هایی که از برنامه های صفحه اصلی شخص ثالث پشتیبانی می کنند ، نصب شود. مثال:
<uses-feature android:name="android.software.home_screen" android:required="true" />
-
FEATURE_INPUT_METHODS
- اعلام می کند که برنامه شما یک روش ورودی سفارشی (یک صفحه کلید ساخته شده با
InputMethodService
) را ارائه می دهد و فقط باید در دستگاه هایی که از روش های ورودی شخص ثالث پشتیبانی می کنند ، نصب شود. مثال:<uses-feature android:name="android.software.input_methods" android:required="true" />
-
FEATURE_BLUETOOTH_LE
- اعلام می کند که برنامه شما از API های کم انرژی بلوتوث استفاده می کند و فقط باید در دستگاه هایی که قادر به برقراری ارتباط با سایر دستگاه ها از طریق انرژی کم بلوتوث هستند ، نصب شود. مثال:
<uses-feature android:name="android.software.bluetooth_le" android:required="true" />
مجوزهای کاربر
مقادیر زیر در حال حاضر در <uses-permission>
برای اعلام مجوزهای برنامه مورد نیاز شما برای دسترسی به API های خاص پشتیبانی می شود.
-
BIND_NOTIFICATION_LISTENER_SERVICE
- مورد نیاز برای استفاده از API های جدید
NotificationListenerService
. -
SEND_RESPOND_VIA_MESSAGE
- برای دریافت هدف
ACTION_RESPOND_VIA_MESSAGE
مورد نیاز است.
برای مشاهده دقیق از کلیه تغییرات API در Android 4.3 ، به گزارش API تفاوت مراجعه کنید.