Android 11 ще въведе опция за разработчици „Съвместимост на приложения“, за да помогне за тестване на промените в платформата

Android 11 ще се предлага с нова настройка „Съвместимост на приложенията“ в опцията за разработчици, което улеснява разработчиците на приложения да тестват промените в поведението на платформата.

Всяка година на Google I/O Google подчертава някои от най-вълнуващите промени, идващи в следващата версия на Android. Докато повечето потребители преценяват версиите на Android по визуалните промени, които влияят на изживяването им, всяка актуализация на Android също идва с много промени в API и поведение на платформата. Тези промени са важни за разработчиците на приложения, които да вземат под внимание и да подготвят своите приложения за тях, тъй като те могат фундаментално да променят начините, по които техните приложения могат да бъдат използвани от крайните потребители. Със следващата версия на Android, Android 11, Google ще улесни разработчиците да тестват и подготвят своите приложения за предстоящи промени с нова настройка „Съвместимост на приложенията“ в Опции за разработчици.

Всеки път, когато Google пусне нова версия на Android, разработчиците на приложения, които се интересуват от активно поддържане техните приложения трябва да прочетат новите промени и документацията, която идва заедно с тях промени. След това те могат да решат да актуализират приложението си, за да добавят тези нови API функции, ако искат, или да мигрират използването на съществуващи API към по-нови API, път, който може или не може да бъде по избор. Разработчиците на приложения не трябва да актуализират целевия API на своите приложения веднага, но те трябва да го направят в крайна сметка, за да отговорят на

промяна на целевите изисквания за API на Google Play Store. След това разработчиците също трябва действително да тестват приложението си на новата версия на Android и това може да бъде направено на емулирано устройство, хоствано в облак устройство или локално устройство. Тестването е част от рутинната разработка, но тестването става още по-важно, когато има големи промени.

Освен това, когато Google иска да въведе големи промени в поведението на платформата, те не прилагат веднага промяната в новата версия на Android. Това има за цел да предпази потребителите от това, че много от приложенията им се счупят и загубят функционалност, а също така дава на разработчиците повече време да актуализират своите приложения. Например в Android 7 Nougat Google реши да ограничаване на някои неявни излъчвания за да спестите живота на батерията. С Android 8 Oreo, Google напълно ограничава приложенията да регистрират неявни излъчващи приемници. Но преди да бъде пуснат Android 8 Oreo, Google искаше разработчиците да се подготвят за сценарий, при който техните приложения вече няма да могат да регистрират имплицитни излъчващи приемници. И за това разработчиците биха могли използвайте ADB команда в Android 7 Nougat, за да симулирате състояние, при което неявните излъчвания са недостъпни:

adb shell cmd appops set RUN_IN_BACKGROUND ignore

ADB команди като тази по-горе са пример за това как Google позволява на разработчиците на приложения да тестват как техните приложения ще се държат при промени в поведението на платформата Android.

Друг скорошен пример е как в Android Q Beta 2, Google поиска от разработчиците да тестват Scoped Storage в техните приложения, като изпълните тази ADB команда:

adb shell cmd appops set your-package-name android: legacy_storage default && \

Като разработчик на приложения може да се предположи, че се чувствате комфортно с ADB командите и не сте особено склонни да ги използвате, за да изпробвате тези промени в платформата. Но винаги има място за подобрение и Google прави този процес на тестване по-лесен, като въвежда прост потребителски интерфейс за контролиране на тези промени.

С новото Проект PlatformCompat, разработчиците вече не трябва да изпълняват ADB команди за всяка нова промяна в поведението на платформата. С Android 11 Android ще има ново подменю в Опции за разработчици за бързо превключване на нови промени в поведението на платформата на базата на приложение, без да е необходимо да изпраща команди на обвивката на ADB. Ще има различни секции за всяко целево ниво на API – например ниво на API > 29 ще има собствен набор от промени в поведението, които могат да се превключват, докато API ниво > 30 ще има свой собствен набор от промени.

В екранната снимка по-горе, показваща секцията за съвместимост на приложението (от изграден AOSP, работещ на емулатор), полето „По подразбиране Разделът „Активирани промени“ включва промени в API на Android 11, които ще бъдат активирани по подразбиране във всички приложения, независимо от тяхната цел SDK. Разделът „активирано за targetSDKversion > 29“ са промени в API на Android 11, които са активирани само за приложения, които са насочени към Android 11/API ниво 30.

Въпреки че тази конкретна промяна няма да развълнува директно крайните потребители, тя прави работата на разработчиците на приложения по-лесна и това винаги е нещо добро.


Благодарение на XDA Recognized Developer luca020400 за съвета и за предоставянето на прикачения екран.

Допълнително покритие за Android 11:

  • Android 11 може най-накрая да премахне ограничението на Android за размер на файла от 4 GB за видеозаписи
  • Планирането на тъмен режим може да се появи в Android 11
  • Самолетният режим може най-накрая да спре да изключва Bluetooth аудиото, като се започне с Android 11 R
  • Google отхвърля AsyncTask API на Android в Android 11
  • Google ще накара разработчиците на файловия мениджър да изпратят формуляр, за да получат широк достъп до съхранение на файлове в Android 11
  • Android 11 може най-накрая да донесе правилна, естествена Wireless ADB реализация