AOSP'deki bir takım taahhütlere göre Google, Android P'deki belgelenmemiş veya gizli API'lere erişimi kısıtlamaya başlayabilir. Birçok markalı uygulama, işlevselliği artırmak için gizli API'ler kullanır, dolayısıyla etki yaygın olabilir.
Güncelleme 2/28/18: Google bugün değişiklikleri onaylayan bir blog yazısı yayınladı. Daha fazla ayrıntı makalenin sonunda.
Bazı Android meraklıları ise spekülasyon yapmak Android'in bir sonraki sürümüne hangi tatlının adı verilecek sorusunun perde arkasında ilginç gelişmeler yaşanıyor. Bir şey fark ettik birkaç dikkate değer Android P'de yakında çıkacak özellikler var, ancak Android Açık Kaynak Projesi'nde (AOSP) daha yeni bir keşif çok daha ilginç olduğunu kanıtladı. Bu son taahhütlere göre, uygulamaların Android SDK'da belgelenmemiş API'lere (javadoc'un @hide özelliğiyle işaretlenen API'ler gibi) erişimi kısıtlanabilir.
Bu neden önemli?
Android Yazılım Geliştirme Kiti (SDK), geliştiricilere yeni Android uygulamalarını test etmek ve oluşturmak için ihtiyaç duydukları API kitaplıklarını ve araçlarını sağlar. Android'in her yeni sürümüyle birlikte, Android SDK aracılığıyla geliştiricilerin kullanımına sunulan bir dizi yeni API gelir. Bir uygulamanın kullanabileceği API'ler, geliştiricinin hangi compileSDKVersion ayarını yaptığına bağlıdır. Bu yüzden Google'ın
yeni Play Store gereksinimleri o kadar önemlidir ki, uygulamaları güncellemeye ve daha yeni API'leri kullanmaya zorlayacaktır.Google barındırıcıları dokümantasyon sayfaları her sınıf ve onun her API düzeyinde mevcut olan tüm yöntemleri için. Bunlar, resmi Android SDK'sında bulunan belgelenmiş API'ler kümesidir. Android Engineer'ın yakın zamanda piyasaya sürülen Android SDK Arama uygulaması gibi bir Android uygulamasını kullanarak sınıf listesine kolayca göz atabilirsiniz. Jake Wharton.
Fiyat: Ücretsiz.
4.1.
Ancak her Android sürümünde bulunan tüm API'ler Google tarafından belgelenmez veya resmi Android SDK'sında mevcut değildir. Genellikle yararlı API'ler vardır belgesiz, ancak yine de çok faydalıdır. Geliştiricilerin uygulamalarını belgelenmemiş veya gizli API'ler kullanarak oluşturmaları önerilmez, ancak çoğu kişi bunu yapar çünkü belirli bir özelliği sunmak istiyorlarsa başka alternatif yoktur. Gizli veya belgelenmemiş API'leri kullanan geliştiriciler de kendilerine rekabet avantajı sağlayabilir. Android'in sunduğu API'leri kullanan rakiplerinin sunduğu özellikleri sunabildikleri için SDK—yapamaz.
Belgelenmemiş API'leri kullanan uygulamaların bir listesini sağlayamasam da (geliştiriciler muhtemelen rakiplerine avantaj sağlayacağı için hangilerini kullanıyorlar), liste muhtemelen daha büyük. Bu nedenle, gizli API'lere erişimin yasaklanmasının önemli olacağı sonucuna vardım. Kurucusu Mark Murphy Ortak yazılım, aynı fikirde:
Eğer bu gerçekleşirse, @hide ile açıklamalı öğelere erişimin toplu olarak yasaklanmasının büyük bir sorun olacağı yönündeki değerlendirmeye katılıyorum. Umarız çok az uygulama bu öğelere temel işlevlerin bir parçası olarak erişir. Ancak, pek çok markalı uygulamanın bunları zaman zaman doğrudan veya bir kütüphane aracılığıyla kullandığından şüpheleniyorum.
Android P'de neler oluyor?
Yaklaşan bu değişiklikler ilk olarak XDA Kıdemli Tanınmış Geliştiricisi tarafından fark edildi rovo89geliştiricisi Xposed Çerçevesi. Bana iki taahhütte bulunduğunu belirtti, biri Hangi oldu birleştirilmiş'hiddenapi' adı verilen yeni bir oluşturma aracını tanıtan. Bu araç, bir DEX dosyasındaki tüm sınıf üyelerinin erişim bayraklarını aşağıdaki durumlarda değiştirir: imzaları bir giriş gri listesinde veya kara listesinde görünür ve bu durumda işaretli yöntemler, kısıtlanmış dahili API'ler olarak ele alınır. erişim. Diğer taahhüt, API kara listesinin nasıl çalıştığını açıklar; erişimi engeller önyükleme sınıfı Geliştiricilerin statik bağlantı, yansıma ve JNI yoluyla erişebileceği, yukarıda adı geçen 'gizli API' ile işaretlenmiş yöntemler ve alanlar.
Rovo89'a göre Android P'deki bu iki değişikliğin nihai sonucu şu:
Bu taahhütlerin birleştirilmesi, uygulamaların artık gizli API'leri kullanamayacağı/erişemeyeceği anlamına gelir; AOSP'de @hide ile açıklamalı olan ve dolayısıyla AOSP'nin parçası olmayan sınıflar, yöntemler ve alanlar resmi SDK'dır. Bu taahhütleri kolayca geri alabileceğim veya modüllerin de çalışmasına izin verebileceğim için bu, Xposed modülleri için bir sorun olmaz. bu API'lere erişin. Ancak gizli API'lerden yararlanan birçok uygulama var ve bunlar gelecek.
Gerçekten de, daha fazla taahhüt, Google'ın planladığı şeyin bu olabileceğini gösteriyor. Bu işlemek şunları belirtir:
Bu özel taahhüt, 3 küçük taahhüt lehine terk edildiği için birleştirilmese de, taahhüt mesajı bu değişikliklerin amacını açıklar. Başka bir set taahhüt eder Google'ın herkese açık olmayan API'leri kullanmak isteyen geliştiricilere alternatifler önereceğini gösterin:
Ancak çoğu zaman belirli gizli API'lerin alternatifi yoktur. Biz XDA olarak buradaki deneyimlerimize dayanarak konuşabiliriz: ne yazık ki bu değişiklik bazı yenilikçi uygulamaların sonu anlamına gelebilir veya bazı ünlü uygulamaların performanslarını azaltmaları gerekebilir. işlevsellik. Yaklaşan bu değişiklik ruhen yakın zamandaki değişime benzer görünüyor Erişilebilirlik Hizmetlerine yönelik baskı (bu çok şükür duraklatıldı Google'ın yenilikçi kullanımları değerlendirdiği gibi). Belgelenmemiş API'leri kullanan çoğu uygulama bunu iyi niyetli sebeplerle yapsa da, bunları kötü amaçlarla kötüye kullanan bazı uygulamalar da olabilir.
Bu nedenle Google, kullanıcıları kötüye kullanan birkaç API'den korumak için Android P'deki tüm gizli API'lere erişimi kilitliyor olabilir. Bunun kullanıcılar üzerinde ne kadar bir etki yaratacağını söylemek zor, ancak eğer bir geliştiriciyseniz Gizli bir API'nin yenilikçi bir kullanımını bulmak için AOSP'ye bakmayı düşünüyorsanız, o zaman şunları yapmak isteyebilirsiniz: yeniden gözden geçirmek.
Güncelleme: Google Onaylıyor
İçinde Blog yazısı 28 Şubat'ta bugün yayınlanan Google bu değişiklikleri doğruladı. Kullanıcılar için çökme risklerini öne süren ve ardından geliştiricileri acil durum düzeltmeleri sunmaya zorlayan Google, şirketin yavaş yavaş geliştiricilerin SDK dışı erişimlere erişimini engellemeye yöneldiğini belirtiyor arayüzler. Android P'den başlayarak kısıtlamalar, SDK'nın Java dili arayüzlerini kapsayacak şekilde genişletilecektir.
Şirket, "SDK dışı bazı yöntem ve alanların kısıtlanacağını" belirtirken hangilerinin kısıtlanacağı konusunda ayrıntılı bilgi vermedi. Başlangıçta kısıtlama nadiren kullanılan arayüzlere odaklanacak ve şirket bir süreliğine bu arayüzlere izin verecek geliştiricilerin SDK dışı yöntemleri ve SDK yöntemine geçişin teknik olarak zorunlu olduğu alanları kullanmaya devam etmesi zorlu. Ancak eninde sonunda kısıtlamalar genişleyecektir, bu nedenle SDK dışı yöntemler kullanan uygulama geliştiricilerinin Android P'ye hazırlık amacıyla mümkün olan en kısa sürede geçiş yapması gerekir. SDK alternatifi olmayan yöntemlere gelince, Google, geliştiricilerin kendi hata izleyici daha fazla bilgi ile.
Görünüşe göre yakında gelecek olan bir sonraki geliştirici önizlemesi, geliştiricilerin son sürümden önce mevcut uygulamaları kara listeye veya gri listeye göre test etmelerine olanak tanıyacak.