Според набор от ангажименти в AOSP, Google може да започне да ограничава достъпа до недокументирани или скрити API в Android P. Много приложения на различни марки използват скрити API за разширяване на функционалността, така че ефектът може да е широко разпространен.
Актуализация 2/28/18: Google публикува днес публикация в блог, потвърждаваща промените. Повече подробности в края на статията.
Докато някои ентусиасти на Android са спекулиране на какъв десерт ще бъде кръстена следващата версия на Android, има някои интересни развития, които се случват зад кулисите. Забелязахме a няколко заслужаващи внимание предстоящи функции в Android P, но по-скорошно откритие в Android Open Source Project (AOSP) се оказа много по-интересно. Според тези скорошни ангажименти, приложенията може да бъдат ограничени от достъп до API, които са недокументирани в Android SDK (като API, маркирани с атрибута @hide на javadoc).
Защо това има значение
Комплектът за разработка на софтуер за Android (SDK) предоставя на разработчиците API библиотеки и инструменти, от които се нуждаят, за да тестват и създават нови приложения за Android. С всяка нова версия на Android идва цял набор от нови API, които са достъпни за разработчиците чрез Android SDK. Какви API са достъпни за дадено приложение, зависи от това каква версия на compileSDK е зададена от разработчика. Ето защо на Google
Google хоства страници с документация за всеки клас и всички негови методи, които са налични във всяко ниво на API. Това са набор от документирани API, които са налични в официалния Android SDK. Можете лесно да преглеждате списъка с класове, като използвате приложение за Android, като наскоро пуснатото приложение за Android SDK Search от Android Engineer Джейк Уортън.
Цена: Безплатно.
4.1.
Въпреки това, не всички API, които са налични във всяка версия на Android, са документирани от Google или са налични в официалния SDK за Android. Често има полезни API, които са без документи, но въпреки това са много полезни. Не се препоръчва разработчиците да създават приложенията си, използвайки недокументирани или скрити API, но много го правят, защото просто няма алтернатива, ако искат да предложат определена функция. Разработчиците, които използват скрити или недокументирани API, също могат да се поставят в конкурентно предимство, тъй като те могат да предложат функции, които техните конкуренти, които се придържат към API, предлагани от Android SDK — не може.
Въпреки че не мога да предоставя списък с приложения, които използват недокументирани API (разработчиците вероятно не споделят кои от тях използват, защото това би дало предимство на техните конкуренти), списъкът вероятно е по-скоро голям. По този начин бих стигнал до извода, че забраната на достъп до скрити API би била важна. Марк Мърфи, основател на Commonsware, съгласен:
Съгласен съм с оценката, че груповата забрана на достъпа до @hide-анотирани елементи ще бъде голяма работа, ако това се случи. Надяваме се, че малко приложения имат достъп до тези елементи като част от ключова функционалност. Подозирам обаче, че много приложения на марки ги използват понякога, директно или чрез библиотека.
Какво се случва в Android P?
Тези предстоящи промени бяха отбелязани за първи път от XDA Senior Recognized Developer rovo89, разработчикът на Xposed Framework. Той ми посочи два ангажимента, един от който е била обединени, който въвежда нов инструмент за изграждане, наречен „hiddenapi“. Този инструмент променя флаговете за достъп на всички членове на класа в DEX файл, ако техните подписи се появяват във входен сив списък или черен списък и ако е така, маркираните методи ще бъдат третирани като вътрешни API с ограничени достъп. Другият комит описва как работи черният списък на API; предотвратява достъпа до клас за зареждане методи и полета, маркирани с гореспоменатия „hiddenapi“, до които разработчиците могат да имат достъп чрез статично свързване, отражение и JNI.
Според rovo89 крайният резултат от тези две промени в Android P е следният:
Ако тези ангажименти бъдат обединени, това би означавало, че приложенията вече не могат да използват/достъп до скрити API, т.е. класове, методи и полета, които са анотирани с @hide в AOSP и следователно не са част от официален SDK. Това не би било проблем за модулите Xposed, тъй като мога лесно да върна тези ангажименти или да позволя на модулите също достъп до тези API. Но има много приложения, които се възползват от скрити API, и те биха се провалили в бъдеще.
Наистина, допълнителни ангажименти показват, че това може да е това, което Google планира. Това ангажирам заявява следното:
Въпреки че този конкретен ангажимент не беше обединен, тъй като беше изоставен в полза на 3 по-малки комита, съобщението за ангажимент описва целта на тези промени. Друг набор от ангажира показват, че Google ще предложи алтернативи на разработчиците, които искат да използват непублични API:
Често обаче няма алтернативи на някои скрити API. Ние от XDA можем да говорим от опит тук като за съжаление тази промяна може да означава края на някои иновативни приложения или може да изисква някои известни приложения да намалят своите функционалност. Тази предстояща промяна изглежда подобна по дух на скорошната репресии срещу услугите за достъпност (това беше за щастие на пауза тъй като Google оцени новаторските употреби). Въпреки че повечето приложения, които използват недокументирани API, го правят по благоприятни причини, може да има някои приложения, които са ги използвали неправомерно за престъпни цели.
Поради това Google може да блокира достъпа до всички скрити API в Android P, за да предпази потребителите от малцината, които злоупотребяват с тях. Трудно е да се каже колко голямо въздействие може да има това върху потребителите, но ако сте разработчик обмисляте да разгледате AOSP, за да намерите иновативно използване на скрит API, тогава може да искате преразгледайте.
Актуализация: Google потвърждава
В блог пост публикувани днес, 28 февруари, Google потвърди тези промени. Позовавайки се на рисковете от срив за потребителите и впоследствие принуждавайки разработчиците да внедряват спешни корекции, Google заявява, че компанията постепенно се пренасочва към обезсърчаване на разработчиците от достъп до не-SDK интерфейси. Започвайки с Android P, ограниченията ще се разширят, за да обхванат езиковите интерфейси на Java на SDK.
Компанията заявява, че „някои методи и полета, които не са SDK, ще бъдат ограничени“, въпреки че не уточняват кои ще бъдат ограничени. Първоначално ограничението ще се фокусира върху интерфейси, които се използват рядко, и за известно време компанията ще разреши разработчиците да продължат да използват различни от SDK методи и полета, където преминаването към SDK метод е технически предизвикателен. Въпреки това, в крайна сметка ограниченията ще се разширят, така че разработчиците на приложения, използващи методи, различни от SDK, трябва да преминат възможно най-скоро в подготовка за Android P. Що се отнася до методите без алтернатива на SDK, Google изисква от разработчиците да публикуват в своите програма за проследяване на грешки с повече информация.
Следващата предварителна версия за разработчици, която привидно пристига скоро, ще позволи на разработчиците да тестват съществуващи приложения спрямо черния или сивия списък преди окончателното издание.