Android 11 მოვა ახალი „აპლიკაციის თავსებადობის“ პარამეტრით Developer Option-ში, რაც აპის დეველოპერებს გაუადვილებს პლატფორმის ქცევის ცვლილებების გამოცდას.
ყოველწლიურად Google I/O-ზე Google ხაზს უსვამს ყველაზე საინტერესო ცვლილებებს Android-ის შემდეგ ვერსიაში. მიუხედავად იმისა, რომ მომხმარებელთა უმეტესობა ანდროიდის ვერსიებს აფასებს ვიზუალური ცვლილებების მიხედვით, რომლებიც გავლენას ახდენს მათ გამოცდილებაზე, Android-ის თითოეულ განახლებას ასევე მოყვება ტონა ცვლილებები API-ებში და პლატფორმის ქცევა. ეს ცვლილებები მნიშვნელოვანია აპლიკაციების დეველოპერებისთვის, რომ გაითვალისწინონ და მოამზადონ თავიანთი აპლიკაციები, რადგან მათ შეუძლიათ ძირეულად შეცვალონ გზები, რომლითაც მათი აპლიკაციები შეიძლება მოხმარდეს საბოლოო მომხმარებლებს. Android-ის შემდეგი ვერსიით, Android 11, Google გაუადვილებს დეველოპერებს შეამოწმონ და მოამზადონ თავიანთი აპლიკაციები მომავალი ცვლილებებისთვის ახალი "აპების თავსებადობის" პარამეტრით დეველოპერის ოფციებში.
ყოველ ჯერზე, როცა Google გამოუშვებს Android-ის ახალ ვერსიას, აპლიკაციის დეველოპერები, რომლებიც დაინტერესებულნი არიან აქტიურად შეინარჩუნონ მათ განაცხადებში უნდა წაიკითხონ ახალი ცვლილებები და დოკუმენტაცია, რომელიც თან ახლავს მათ ცვლილებები. შემდეგ მათ შეუძლიათ გადაწყვიტონ განაახლონ თავიანთი აპი ამ ახალი API ფუნქციების დასამატებლად, თუ მათ სურთ ან გადაიტანონ არსებული API-ების გამოყენება ახალ API-ებზე, გზა, რომელიც შეიძლება იყოს ან არ იყოს არჩევითი. აპლიკაციის დეველოპერებს არ სჭირდებათ დაუყოვნებლივ განაახლონ თავიანთი აპების სამიზნე API, მაგრამ საბოლოოდ უნდა გააკეთონ ეს, რომ დააკმაყოფილონ
Google Play Store-ის სამიზნე API მოთხოვნების შეცვლა. ამის შემდეგ, დეველოპერებმა ასევე უნდა შეამოწმონ თავიანთი აპლიკაცია 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 ignoreADB ბრძანებები, როგორიცაა ზემოთ მოცემული, არის მაგალითი იმისა, თუ როგორ აძლევს 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-ს ექნება ახალი ქვემენიუ Developer Options-ში, რათა სწრაფად გადართოს ახალი პლატფორმის ქცევის ცვლილებები თითო აპლიკაციაზე, ყოველგვარი ADB shell ბრძანებების გაგზავნის საჭიროების გარეშე. იქნება სხვადასხვა სექცია თითოეული სამიზნე API დონისთვის -- მაგალითად, API დონე > 29 ექნება ქცევის ცვლილებების საკუთარი ნაკრები, რომლის შეცვლაც შესაძლებელია, ხოლო API > 30 დონეს ექნება საკუთარი ნაკრები ცვლილებები.
ზემოთ მოცემულ ეკრანის სურათზე, სადაც ნაჩვენებია აპლიკაციის თავსებადობის განყოფილება (წყაროში აშენებული AOSP, რომელიც მუშაობს ემულატორზე), "ნაგულისხმევი ჩართული ცვლილებების განყოფილება მოიცავს Android 11 API-ის ცვლილებებს, რომლებიც ნაგულისხმევად ჩართული იქნება ყველა აპზე, მიუხედავად მათი მიზნისა SDK. განყოფილება „ჩართულია targetSDKversion > 29-ისთვის“ არის Android 11 API ცვლილებები, რომლებიც ჩართულია მხოლოდ აპებისთვის, რომლებიც მიზნად ისახავს Android 11/API დონეს 30.
მიუხედავად იმისა, რომ ეს ცვლილება პირდაპირ არ აღელვებს საბოლოო მომხმარებლებს, ის აადვილებს აპლიკაციების შემქმნელებს და ეს ყოველთვის კარგია.
მადლობა XDA აღიარებული დეველოპერის luca020400 წვერისთვის და თანდართული სკრინშოტის მოწოდებისთვის.
დამატებითი გაშუქება Android 11-ზე:
- Android 11-მა შესაძლოა საბოლოოდ ამოიღოს Android-ის 4 GB ფაილის ზომის ლიმიტი ვიდეო ჩანაწერებისთვის
- ბნელი რეჟიმის დაგეგმვა შესაძლოა გამოვიდეს Android 11-ში
- თვითმფრინავის რეჟიმში შესაძლოა საბოლოოდ შეწყვიტოს Bluetooth აუდიოს გამორთვა Android 11 R-ით დაწყებული
- Google უარყოფს Android-ის AsyncTask API-ს Android 11-ში
- Google აიძულებს ფაილების მენეჯერის შემქმნელებს წარმოადგინონ ფორმა, რათა მიიღონ ფაილების ფართო საცავში წვდომა Android 11-ში
- Android 11-მა შეიძლება საბოლოოდ მოიტანოს სათანადო, მშობლიური უსადენო ADB დანერგვა