Згідно з набором комітів в AOSP, Google може почати обмежувати доступ до незадокументованих або прихованих API в Android P. Багато фірмових програм використовують приховані API для розширення функціональності, тому ефект може бути широко поширеним.
Оновлення 28.02.18: Сьогодні Google опублікував допис у блозі, який підтверджує зміни. Детальніше в кінці статті.
Хоча деякі ентузіасти Android є спекулюючи на честь якого десерту буде названа наступна версія Android, за кадром відбуваються цікаві події. Ми помітили a кілька заслуговують на увагу майбутні функції в Android P, але нещодавнє відкриття в Android Open Source Project (AOSP) виявилося набагато цікавішим. Згідно з цими нещодавніми комітами, програмам може бути обмежено доступ до API, які не задокументовані в Android SDK (наприклад, API, позначені атрибутом @hide документа javadoc).
Чому це важливо
Android Software Development Kit (SDK) надає розробникам бібліотеки API та інструменти, необхідні для тестування та створення нових програм Android. З кожним новим випуском Android з’являється ціла низка нових API, які доступні розробникам через Android SDK. Які API доступні для програми, залежить від того, яку версію compileSDKVersion встановлює розробник. Ось чому Google
Google hosts сторінки документації для кожного класу та всіх його методів, доступних на кожному рівні API. Це набір задокументованих API, які доступні в офіційному Android SDK. Ви можете легко переглядати список класів за допомогою програми Android, наприклад нещодавно випущеної програми Android SDK Search від Android Engineer Джейк Вартон.
Ціна: безкоштовно.
4.1.
Однак не всі API, доступні в кожному випуску Android, задокументовані Google або доступні в офіційному Android SDK. Часто існують корисні API бездокументований, але тим не менш дуже корисні. Не рекомендується, щоб розробники створювали свої програми за допомогою недокументованих або прихованих API, але багато хто робить це, оскільки просто немає альтернативи, якщо вони хочуть запропонувати певну функцію. Розробники, які використовують приховані або недокументовані API, також можуть отримати конкурентну перевагу, оскільки вони можуть запропонувати функції, що й їхні конкуренти, які дотримуються API, запропонованих Android SDK — не може.
Хоча я не можу надати список програм, які використовують недокументовані API (розробники, ймовірно, не поділяють які з них вони використовують, оскільки це дасть перевагу їхнім конкурентам), список, мабуть, скоріше великий. Таким чином, я б зробив висновок, що заборона доступу до прихованих API була б важливою. Марк Мерфі, засновник Загальне програмне забезпечення, погоджується:
Я погоджуюся з оцінкою, що масова заборона доступу до елементів із анотаціями @hide стане великою проблемою, якщо це відбудеться. Сподіваємося, лише деякі програми мають доступ до цих елементів як частини ключових функцій. Однак я підозрюю, що багато фірмових додатків іноді використовують їх безпосередньо або через бібліотеку.
Що відбувається в Android P?
Ці майбутні зміни вперше помітив старший визнаний розробник XDA 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 просить розробників опублікувати на своїх трекер помилок з додатковою інформацією.
Наступна попередня версія для розробників, яка нібито з’явиться незабаром, дозволить розробникам перевірити існуючі програми на відповідність чорному або сірому списку перед остаточним випуском.