AOSP-ის ვალდებულებების ნაკრების მიხედვით, Google-მა შეიძლება დაიწყოს წვდომის შეზღუდვა დაუსაბუთებელ ან ფარულ API-ებზე Android P-ში. მრავალი სახელის ბრენდის აპლიკაცია იყენებს ფარულ API-ებს ფუნქციონირების გასაძლიერებლად, ამიტომ ეფექტი შეიძლება ფართოდ იყოს გავრცელებული.
განახლება 2/28/18: Google-მა დღეს გამოაქვეყნა ბლოგის პოსტი, რომელიც ადასტურებს ცვლილებებს. დამატებითი დეტალები სტატიის ბოლოს.
მიუხედავად იმისა, რომ Android-ის ზოგიერთი ენთუზიასტი არის სპეკულირება რა დესერტს დაერქმევა ანდროიდის შემდეგი ვერსია, კულისებში რამდენიმე საინტერესო განვითარება მიმდინარეობს. ჩვენ შევნიშნეთ ა რამდენიმე საყურადღებოა Android P-ის მომავალი ფუნქციები, მაგრამ უფრო ახალი აღმოჩენა Android Open Source Project-ში (AOSP) ბევრად უფრო საინტერესო აღმოჩნდა. ამ ბოლო ვალდებულებების მიხედვით, აპლიკაციებს შეიძლება შეეზღუდოს წვდომა API-ებზე, რომლებიც არადოკუმენტირებულია Android SDK-ში (როგორიცაა API-ები, რომლებიც მონიშნულია javadoc-ის ატრიბუტით @hide).
რატომ აქვს ამას მნიშვნელობა
Android Software Development Kit (SDK) უზრუნველყოფს დეველოპერებს API ბიბლიოთეკებით და ინსტრუმენტებით, რომლებიც მათ სჭირდებათ ახალი Android აპლიკაციების შესამოწმებლად და შესაქმნელად. Android-ის ყოველი ახალი გამოშვებით მოდის ახალი API-ების მთელი რიგი, რომლებიც ხელმისაწვდომია დეველოპერებისთვის Android SDK-ის მეშვეობით. რომელი API ხელმისაწვდომია აპისთვის, დამოკიდებულია იმაზე, თუ რა კომპილSDKVersion-ს აყენებს დეველოპერი. ამიტომ Google-ის
Google მასპინძლებს დოკუმენტაციის გვერდები თითოეული კლასისთვის და მისი ყველა მეთოდისთვის, რომლებიც ხელმისაწვდომია თითოეულ API დონეზე. ეს არის დოკუმენტირებული API-ების ნაკრები, რომლებიც ხელმისაწვდომია ოფიციალურ Android SDK-ში. თქვენ შეგიძლიათ მარტივად დაათვალიეროთ კლასების სია Android აპლიკაციის გამოყენებით, როგორიცაა Android Engineer-ის ახლახან გამოშვებული Android SDK Search აპი. ჯეიკ უორტონი.
ფასი: უფასო.
4.1.
თუმცა, ყველა API, რომელიც ხელმისაწვდომია Android-ის თითოეულ გამოშვებაში, არ არის დოკუმენტირებული Google-ის მიერ ან ხელმისაწვდომია ოფიციალურ Android SDK-ში. ხშირად არის სასარგებლო API-ები დაუსაბუთებელი, მაგრამ მაინც ძალიან სასარგებლოა. არ არის რეკომენდებული, რომ დეველოპერებმა შექმნან თავიანთი აპლიკაციები დაუსაბუთებელი ან ფარული API-ების გამოყენებით, მაგრამ ბევრი ამას აკეთებს, რადგან უბრალოდ ალტერნატივა არ არსებობს, თუ მათ სურთ შესთავაზონ გარკვეული ფუნქცია. დეველოპერებს, რომლებიც იყენებენ ფარულ ან დაუსაბუთებელ API-ებს, შეუძლიათ თავიანთი თავი კონკურენტულ უპირატესობაშიც დააყენონ, რადგან მათ შეუძლიათ შესთავაზონ ფუნქციები, რომლებიც მათ კონკურენტებს აქვთ, რომლებიც იცავენ Android-ის მიერ შემოთავაზებულ API-ებს SDK - არ შეიძლება.
მიუხედავად იმისა, რომ მე არ შემიძლია მოგაწოდოთ აპების სია, რომლებიც იყენებენ დაუსაბუთებელ API-ებს (დეველოპერები ალბათ არ აზიარებენ რომელ მათგანს იყენებენ, რადგან ეს მათ კონკურენტებს ფეხს აძლევდა), სია ალბათ საკმაოდ არის დიდი. ამრიგად, მე დავასკვენი, რომ ფარული API-ებზე წვდომის აკრძალვა მნიშვნელოვანი იქნება. მარკ მერფი, დამფუძნებელი Commonsware, თანახმაა:
ვეთანხმები შეფასებას, რომ @hide-ანოტირებულ ელემენტებზე წვდომის დიდი აკრძალვა დიდი საქმე იქნება, თუ ეს მოხდება. იმედია, რამდენიმე აპს აქვს წვდომა ამ ელემენტებზე, როგორც ძირითადი ფუნქციონირების ნაწილი. თუმცა, მე ეჭვი მაქვს, რომ მრავალი სახელის აპი იყენებს მათ ზოგჯერ, პირდაპირ ან ბიბლიოთეკის მეშვეობით.
რა ხდება Android P-ში?
ეს მომავალი ცვლილებები პირველად შენიშნა XDA Senior Recognized Developer-ის მიერ rovo89, დეველოპერი Xposed Framework. მან მიმითითა ორი ვალდებულება, ერთი რომელიც ყოფილა გაერთიანდა, რომელიც წარმოგიდგენთ ახალ აგებულ ინსტრუმენტს სახელწოდებით "hiddenapi". ეს ინსტრუმენტი ცვლის ყველა კლასის წევრის წვდომის დროშებს DEX ფაილში if მათი ხელმოწერები გამოჩნდება შეყვანის ნაცრისფერ სიაში ან შავ სიაში და თუ ასეა, მონიშნული მეთოდები განიხილება, როგორც შიდა API-ები შეზღუდული შეზღუდვით. წვდომა. სხვა commit აღწერს, თუ როგორ მუშაობს API შავი სია; ის ხელს უშლის წვდომას ჩექმის კლასი მეთოდები და ველები, რომლებიც აღნიშნულია ზემოაღნიშნული „დამალული“-ით, რომლებზეც დეველოპერებს შეუძლიათ წვდომა სტატიკური ბმულით, ასახვით და JNI-ით.
rovo89-ის მიხედვით, Android P-ში ამ ორი ცვლილების საბოლოო შედეგი შემდეგია:
თუ ეს დავალებები გაერთიანდება, ეს ნიშნავს, რომ აპებს აღარ შეუძლიათ ფარული API-ების გამოყენება/წვდომა, ანუ კლასები, მეთოდები და ველები, რომლებიც ანოტირებულია @hide-ით AOSP-ში და, შესაბამისად, არ არის ნაწილი ოფიციალური SDK. ეს არ იქნებოდა პრობლემა Xposed მოდულებისთვის, რადგან მე ადვილად შემეძლო ამ ვალდებულებების დაბრუნება ან მოდულების უფლება წვდომა ამ API-ებზე. მაგრამ არის ბევრი აპი, რომლებიც სარგებლობენ ფარული API-ებით და ისინი ვერ მოხერხდება მომავალი.
მართლაც, შემდგომი ვალდებულებები აჩვენებს, რომ ეს შეიძლება იყოს ის, რასაც Google გეგმავს. ეს ჩაიდინოს აცხადებს შემდეგს:
მიუხედავად იმისა, რომ ეს კონკრეტული commit არ გაერთიანდა, რადგან იგი მიტოვებული იყო 3 მცირე კომისიის სასარგებლოდ, commit შეტყობინება აღწერს ამ ცვლილებების მიზანს. კიდევ ერთი ნაკრები ახორციელებს აჩვენეთ, რომ Google შესთავაზებს ალტერნატივას დეველოპერებს, რომლებიც ცდილობენ გამოიყენონ არასაჯარო API:
თუმცა, ხშირად არ არსებობს გარკვეული ფარული API-ების ალტერნატივა. ჩვენ XDA-ში შეგვიძლია ვისაუბროთ გამოცდილებიდან აქ, როგორც სამწუხაროდ, ამ ცვლილებამ შეიძლება დაასრულოს ზოგიერთი ინოვაციური აპი, ან შეიძლება მოითხოვოს ზოგიერთი ცნობილი აპლიკაციის შემცირება მათი ფუნქციონირება. ეს მომავალი ცვლილება სულისკვეთებით მსგავსია ბოლო დროს ხელმისაწვდომობის სერვისების დარბევა (ეს იყო საბედნიეროდ შეაჩერა როგორც Google-მა შეაფასა ინოვაციური გამოყენება). მიუხედავად იმისა, რომ აპლიკაციების უმეტესობა, რომლებიც იყენებს დაუსაბუთებელ API-ებს, ამას აკეთებს კეთილსაიმედო მიზეზების გამო, შეიძლება არსებობდეს აპლიკაციები, რომლებმაც ისინი ბოროტად გამოიყენეს მავნე მიზნებისთვის.
ამის გამო, Google-მა შესაძლოა ჩაკეტოს წვდომა Android P-ის ყველა ფარულ API-ზე, რათა დაიცვას მომხმარებლები იმ მცირერიცხოვანებისგან, ვინც მათ ბოროტად იყენებს. ძნელი სათქმელია, რამდენად დიდი გავლენა შეიძლება ჰქონდეს ამას მომხმარებლებზე, მაგრამ თუ თქვენ ხართ დეველოპერი თუ გავითვალისწინებთ AOSP-ს ფარული API-ის ინოვაციური გამოყენების პოვნას, მაშინ შეიძლება გინდოდეთ გადახედოს.
განახლება: Google ადასტურებს
Ში ბლოგის პოსტი დღეს, 28 თებერვალს გამოქვეყნდა, Google-მა დაადასტურა ეს ცვლილებები. მომხმარებლისთვის ავარიის რისკების მოტივით და შემდგომში დეველოპერების იძულებით გადაუდებელი გამოსწორების გამოსწორების მიზნით, Google აცხადებს, რომ კომპანია თანდათან გადადის დეველოპერებისადმი წვდომაზე არა SDK-ზე ინტერფეისები. Android P-დან დაწყებული, შეზღუდვები გაფართოვდება და მოიცავს SDK-ის Java ენის ინტერფეისებს.
კომპანია აცხადებს, რომ „ზოგიერთი არა SDK მეთოდი და ველი შეიზღუდება“, თუმცა არ აკონკრეტებენ, რომელი მათგანი შეიზღუდება. თავდაპირველად შეზღუდვა ყურადღებას გაამახვილებს ინტერფეისებზე, რომლებიც იშვიათად გამოიყენება და გარკვეული პერიოდის განმავლობაში კომპანია დაუშვებს დეველოპერებმა გააგრძელონ არა SDK მეთოდებისა და ველების გამოყენება, სადაც ტექნიკურად არის SDK მეთოდზე გადასვლა გამომწვევი. თუმცა, საბოლოოდ შეზღუდვები გაფართოვდება, ამიტომ აპლიკაციების შემქმნელებმა, რომლებიც იყენებენ SDK მეთოდებს, რაც შეიძლება მალე უნდა გადავიდნენ Android P-სთვის მოსამზადებლად. რაც შეეხება მეთოდებს SDK ალტერნატივის გარეშე, Google სთხოვს დეველოპერებს გამოაქვეყნონ მათზე შეცდომების ტრეკერი მეტი ინფორმაციით.
შემდეგი დეველოპერის გადახედვა, რომელიც სავარაუდოდ მალე მოვა, საშუალებას მისცემს დეველოპერებს შეამოწმონ არსებული აპლიკაციები შავ სიაში ან ნაცრისფერ სიაში საბოლოო გამოშვებამდე.