Android 11 AMA: არ არის გადახვევის ეკრანის ანაბეჭდები, აპების უფრო სწრაფი გაშვება და სხვა

გუშინ Google-მა გამოუშვა Android 11 Beta 2, მოაქვს დასრულებული SDK, NDK, აპისკენ მიმართული ზედაპირები, პლატფორმის ქცევები და შეზღუდვები არა SDK ინტერფეისებზე დეველოპერებისთვის. დღეს Google პასუხობს Android 11-თან დაკავშირებულ კითხვებს Reddit-ის /r/AndroidDev საზოგადოებაში გასულ კვირას კითხვების დასმის შემდეგ. აქ მოცემულია ყველაფრის შეჯამება, რაც ვისწავლეთ Google-ის AMA-დან (მკითხე რაიმე).

Android 11-ის ერთ-ერთი ყველაზე მოსალოდნელი ფუნქცია არ იქნება ხელმისაწვდომი, როდესაც OS გამოდის ბეტა 8 სექტემბერს: ეკრანის გადახვევა. თავდაპირველად დაგეგმილია Android 11-ში გაშვება, Google-მა ახლა დაადასტურა, რომ ფუნქცია "არ გააკეთა შემცირება R-ისთვის." Android 11 Developer Preview 1 და ყველა მომდევნო DP და Beta გამოშვებას აქვს ჩანაცვლების ღილაკი გადახვევის ეკრანის ანაბეჭდის გადასაღებად, რომელიც შეიძლება იყოს ხელით გამოჩნდა დამალული დეველოპერის ბრძანებით

, მაგრამ ღილაკზე დაჭერით უბრალოდ გამოჩნდება სადღეგრძელო შეტყობინება, რომელშიც ნათქვამია, რომ ფუნქცია "არ არის განხორციელებული".

ჩვენ ვიმედოვნებდით, რომ ფუნქცია ბეტა ან თუნდაც მხოლოდ სტაბილურ გამოშვებაში მოხვდებოდა, მაგრამ, როგორც ჩანს, ეს არ მოხდება.

გასაგებია, რომ ეს სიახლე შემაშფოთებელი იქნება ზოგიერთი მომხმარებლისთვის. ყოველივე ამის შემდეგ, ბევრ OEM-ს აქვს ეს ფუნქცია საკუთარ პროგრამულ უზრუნველყოფაში წლების განმავლობაში, ასე რომ, რა სჭირდება Google-ს ამდენი დროის დასამატებლად Pixel ტელეფონებში? როგორც დენ სენდლერმა განმარტა Google-ის System UI გუნდიდან, პრობლემა ის არის, რომ Google-ს სურს ამის სწორად გაკეთება. ზოგიერთი გადახვევის სკრინშოტის იმპლემენტაცია უბრალოდ ამსგავსებს გადახვევას და შემდეგ აერთიანებს რამდენიმე ეკრანის სურათს ეკრანის მოძრაობისას. თუ ოდესმე გქონიათ საქმე ანდროიდის ინტერფეისის ავტომატიზაციასთან, გეცოდინებათ, რომ ეს ყოველთვის არ მუშაობს, რადგან, როგორც მისტერ სენდლერი აღნიშნავს, აპები შეუძლია გამოიყენოს "bog-სტანდარტული RecyclerView ან დანერგოს საკუთარი OpenGL-ის დაჩქარებული გადახვევის ძრავა." ვინაიდან Google გეგმავს დანერგონ ეს ფუნქცია არა მხოლოდ Pixel სმარტფონებისთვის, არამედ მთელი Android ეკოსისტემისთვის, როგორც AOSP-ის ნაწილი, მათ უნდა დარწმუნდნენ იმუშავებს ყველა აპები და არა მხოლოდ „ერთი ან ორი ხელით შერჩეული აპი კონკრეტულ მოწყობილობაზე“.

იმის გამო, რომ გუნდს მოუწია „შეზღუდული რესურსების ფოკუსირება“, განსაკუთრებით გამოწვეული გამოწვევების გამო COVID-19-ით, გუნდმა გადაწყვიტა დაეყენებინა გადახვევის ეკრანის ანაბეჭდები ფონზე მომავალი Android გამოშვებისთვის.

ახალი CDD მოთხოვნა, რათა აცნობოს მომხმარებლებს ფონური შეზღუდვების შესახებ

საიდუმლო არ არის, რომ Android-ის ბევრ OEM-ს, განსაკუთრებით ჩინურს, აქვს აგრესიული შეზღუდვები ფონზე გაშვებულ აპებზე. ზოგიერთი დეველოპერი იმდენად იმედგაცრუებული იყო მათი აპლიკაციების ფონზე მოკვლით, რომ ისინი გაერთიანდნენ და შექმნეს ვებსაიტი სახელწოდებით "არ მოკლა ჩემი აპლიკაციაOEM-ების რანჟირება იმის მიხედვით, თუ რამდენად ცუდად უმკლავდებიან აპლიკაციების ფონურ პროცესებს. იგივე დეველოპერები თუნდაც ცოტა ხნის წინ გააკეთა საორიენტაციო ასე რომ, მომხმარებლებს შეუძლიათ შეამოწმონ, რამდენად აგრესიულად კლავს მათი მოწყობილობა აპებს ფონზე. მიზეზი, რის გამოც ბევრ OEM-ს უყვარს ფონური აპლიკაციების პროცესების მოკვლა, რთულია, მაგრამ ვფიქრობ, ეს საუკეთესოდ არის ახსნილი ამ კომენტარში Redditor /u/-ის მიერ.შესაძლოა სადავო. კომენტარი ასახავს Android აპლიკაციის განვითარების რთულ სტატუსს ჩინეთში, როგორია ჩინური ტექნიკური კომპანიები ჩართული არიან საქმის შემდგომ გართულებაში და როგორ უწყობს ხელს Google-ის სერვისების ნაკლებობა მიმდინარეობას არეულობა.

მიუხედავად ამისა, ბევრი აპლიკაციის დეველოპერი გასაგებია იმედგაცრუებული Android პლატფორმის ქცევის ამ შესწორებით, რამაც გამოიწვია დეველოპერებმა კომენტარის გაკეთება. ეკითხება Google-ს, რას აკეთებენ ამის შესახებ Reddit AMA-ს მწვერვალზე. აი Google-ის პასუხი:

არსებობს რამდენიმე რამ, რაც ამ პასუხს უნდა წაართვან. პირველ რიგში, Google-ს სურს, რომ OEM-ები იყოს უფრო გამჭვირვალე მომხმარებლებთან აპლიკაციების ფონური შეზღუდვების შესახებ, რომლებსაც ისინი მიმართავენ. მე შევამოწმე (გამოუქვეყნებელი) Android 11 თავსებადობის განმარტების დოკუმენტი (CDD) და აღმოვაჩინე შემდეგი შემოთავაზებული დამატება განყოფილებაში 3.5 - API ქცევითი თავსებადობა:

თუ მოწყობილობის დანერგვა ახორციელებს საკუთრების მექანიზმს აპების შეზღუდვისთვის და ეს მექანიზმი უფრო შემზღუდველია, ვიდრე "იშვიათი" ლოდინის თაიგული AOSP-ზე, ისინი:

[C-1-5] უნდა აცნობოს მომხმარებლებს, თუ აპის შეზღუდვები ავტომატურად გამოიყენება აპზე. (ახალი) ასეთი ინფორმაცია არ უნდა იყოს მოწოდებული ასეთი შეზღუდვების გამოყენებამდე 24 საათით ადრე.

(შენიშვნა) Force Stop ითვლება უფრო შემზღუდველად, ვიდრე "Rare" და უნდა შეესაბამებოდეს 3.5.1-ის ყველა მოთხოვნას, მათ შორის ახალი 3.5.1/C-1-5

ძირითადად, Google არ არის ძალიან მნიშვნელოვანი, რომ შეაჩეროს OEM-ები, განახორციელონ საკუთარი შემზღუდავი აპლიკაციების მოკვლის ფუნქციები. ისინი მხოლოდ მოითხოვენ, რომ OEM-ებმა აცნობონ მომხმარებლებს, თუ მათი აპლიკაციის შეზღუდვები ავტომატურად გამოიყენება. OEM-ს შეუძლია აჩვენოს დიალოგი, რომ ისინი აპირებენ შეაჩერონ ბატარეის მწოვი ფონური აპების გაშვება მასში ფონზე და მომხმარებელს შეუძლია თანხმობა დაეთანხმოს ისე, რომ არ გააცნობიეროს ის აპლიკაციები, რომელთა გაშვებაც ნამდვილად სურთ ფონზე დაზარალდა! Google აკისრებს დეველოპერებს იმ შემთხვევებს, როდესაც მათი აპლიკაცია მოულოდნელად კვდება ფონზე. მართლაც, Reddit-ის კომენტარი ხაზს უსვამს ახალს.აპლიკაციის პროცესიდან გასვლის მიზეზებიAPI, რომელსაც შეუძლია აცნობოს დეველოპერებს, მოკვდა თუ არა მათი აპლიკაცია მომხმარებელმა, ოპერაციულმა სისტემამ, თუ ის უბრალოდ დაიშალა.

მეორეს მხრივ, Google საბოლოოდ მიმართავს OEM-ების უსამართლო პრაქტიკას, რომელიც საშუალებას აძლევს გარკვეულ პრივილეგირებულ აპლიკაციებს გადალახონ მათი ფონური აპლიკაციების შეზღუდვები. ეს საშუალო პოსტი დეველოპერის მიერ ტიმოთე ასიიმვე დეტალურად აღწერს აპლიკაციებს, როგორიცაა WhatsApp, Facebook და სხვა აპლიკაციები, ავტომატურად გათავისუფლებულია ზოგიერთი OEM პროგრამული უზრუნველყოფის მკაცრი ფონური შეზღუდვებისგან. Google ამბობს, რომ ისინი „მოითხოვენ, რომ მოწყობილობის მწარმოებლებმა არ შექმნან ნებადართული სიები საუკეთესო აპებისთვის“. ჩვენ არ ვიცით, როგორ აღსრულდება ეს, მაგრამ კარგია იცოდეთ, რომ OEM-ები საბოლოოდ იძულებულნი იქნებიან მესამე მხარის დეველოპერებს თანაბარი პირობებით მოეპყრონ, რაც არ უნდა იყოს დიდი თუ პატარა მათი აპლიკაციები. არიან.

დაბოლოს, Google ასევე აღნიშნავს, თუ როგორ დაამატა Android 11-მა „დამატებითი ზომები, რათა თავიდან აიცილოს შეურაცხმყოფელი ქცევა აპლიკაციების არასწორი ქცევით“, რაც ნაკლებად მიმზიდველს გახდის OEM-ებისთვის აგრესიულად მოკვლა ფონური პროცესები. თუმცა, კომპანიამ არ დააკონკრეტა, თუ რას გულისხმობს ეს "დამატებითი ზომები".

გაუმჯობესებული Device-to-Device Backups

გასულ თვეში ჩვენ შევნიშნეთ ცვლილება Android 11-ის დოკუმენტაციაში, რომელიც მიანიშნებდა ადგილობრივი მონაცემების უკეთესი სარეზერვო ასლების მხარდაჭერაზე. Android 11-ში, სისტემა უგულებელყოფს allowBackup Manifest ატრიბუტს ნებისმიერი აპისთვის, რომელიც მიზნად ისახავს API დონეს 30, როდესაც მომხმარებელი იწყებს აპის ფაილების „მოწყობილობა-მოწყობილობა“ მიგრაციას. Google-ის თანამშრომელი ელიოტ სტოკი ამბობს, რომ ეს ფუნქცია მიზნად ისახავს ტელეფონების მწარმოებლებს გაუადვილოს მოწყობილობების მოწყობილობაზე მიგრაციის ხელსაწყოების შექმნა, როგორიცაა „Samsung-ის შესანიშნავი Smart Switch პროდუქტი“ დაეხმარეთ "აპების უფრო საიმედო გადაცემას მოწყობილობებს შორის მომხმარებლის თვალსაზრისით." სამწუხაროდ, ეს არ ეხება ღრუბელზე დაფუძნებულ სარეზერვო ასლებს, რადგან Google-ს სურს „პროგრამის დეველოპერებს მისცეს კონტროლი იმაზე, თუ რა ხდება მათი აპლიკაციის მონაცემებით." როგორც ასეთი, Android 11 კვლავ პატივს სცემს allowBackup ატრიბუტს ღრუბელზე დაფუძნებული სარეზერვო ასლის და აღდგენისთვის, როგორიცაა Google Play Service-ის ჩაშენებული Google Drive-ის მეშვეობით. სარეზერვო. და ბოლოს, Google აღიარებს, რომ 25 მბაიტი თითო აპლიკაციაზე სარეზერვო ჭერი შეიძლება არ იყოს საკმარისი ზოგიერთი დეველოპერისთვის, ამიტომ ისინი ეძებენ გზებს ამის გადასაჭრელად. თუმცა, კომპიუტერის ლოკალური სარეზერვო ასლები არ განიხილება და Google იმეორებს თავის გეგმას adb-ის სარეზერვო ასლის გაუქმება Android-ის მომავალ გამოშვებაში.

დეველოპერებს ურჩევენ დანერგონ მონაცემთა უხახუნის მიგრაციის მეთოდები. The ახალი Block Store ბიბლიოთეკა, რომელიც არის Google Identity Services Library-ის ნაწილი, შექმნილია იმისათვის, რომ გააადვილოს აღდგენილ აპებში შესვლა ღრუბლიდან ახალ მოწყობილობებზე, მაგრამ დეველოპერების გადასაწყვეტია, სურთ თუ არა ამის განხორციელება ბიბლიოთეკა.

აპლიკაციის გაშვების უფრო სწრაფი სიჩქარე I/O Read Ahead პროცესით (IORap)

Google ყოველთვის ატარებს ექსპერიმენტებს Android-ში მუშაობის გაუმჯობესების გზებზე. ერთ-ერთ ნაკლებად ცნობილ მახასიათებელს, რომელიც მათ დაამატეს Android 10-ში, ეწოდება არასპეციალიზებული აპლიკაციის პროცესის ფონდი (USAP). ეს ფუნქცია გამორიცხავს Zygote-ის გაფუჭებას აპლიკაციის გაშვების პროცესში, დაზოგავს დაახლოებით ~ 5ms აპის გაშვების საშუალო სიჩქარეს Pixel 2 მოწყობილობაზე. ფუნქცია ამჟამად არის ნაგულისხმევად გამორთულია AOSP-ში, და Google განმარტავს, რომ მისი დამატებული მეხსიერების გამოყენება ჯერ კიდევ საჭიროებს ტესტირებას. რაც უფრო საინტერესოა, არის ახალი ფუნქცია, რომელიც მოდის Android 11-ში, სახელწოდებით I/O Read Ahead Process (IORap). Google-ის ცნობით, ეს ფუნქცია გამოიწვევს "5%-ზე მეტ სწრაფ ცივ სტარტაპებს, გმირების შემთხვევები 20%-ით უფრო სწრაფად აღწევს." ეს თვისება "წინასწარ მოიტანს აპლიკაციების არტეფაქტებს (როგორიცაა კოდი და რესურსები) გაშვების პროცესში" აპლიკაციის გაშვების გასაძლიერებლად სიჩქარეები.

Google-მა ასევე „გააუმჯობესა პროფილები, რომლებიც გამოიყენება ჩატვირთვის კლასის ბილიკის და სისტემის სურათის ოპტიმიზაციისთვის“. რაც გააუმჯობესებს აპლიკაციის მუშაობას და შეამცირებს სისტემასთან დაკავშირებულ მეხსიერებისა და შენახვის ხარჯებს არტეფაქტები. ეს ცვლილებები ძირითადად სარგებელს მოუტანს RAM-ის უფრო მაღალი მოცულობის მქონე მოწყობილობებს, თუმცა Google-ს არ უთქვამს რა არის შეზღუდვა, სადაც ვნახავთ ყველაზე მეტ სარგებელს.

Android 11-ის Scoped Storage ცვლილებები - რატომ არის შეზღუდული წვდომა/ჩამოტვირთვებზე?

აპები, რომლებიც მიზნად ისახავს Android 11-ს და იყენებენ ACTION_OPEN_DOCUMENT_TREE განზრახვას, რომ მოითხოვონ წვდომა კონკრეტულ კატალოგებზე გარედან საცავი ვეღარ შეძლებს მომხმარებლებს მოსთხოვოს წვდომა გარე მეხსიერების ძირეულ დირექტორიაში (/data/media/{user}), ჩამოტვირთვა დირექტორია (/data/media{user}/ჩამოტვირთვა) ან რომელიმე აპისთვის სპეციფიკური მონაცემთა დირექტორია გარე მეხსიერებაზე (/Android/მონაცემები ან /Android/obb). რატომ არის შეზღუდული წვდომა ჩამოტვირთვის დირექტორიაზე? Google-ის მიხედვით Roxanna Aliabadi, ეს იმიტომ, რომ ჩამოტვირთვის საქაღალდე "ყველაზე მეტად ემუქრება პირადი ინფორმაციის ქონას." მაგალითად, მომხმარებლები, რომლებიც ჩამოტვირთავენ თავიანთ გადასახადს ანაზღაურება ან საბანკო ამონაწერი არ უნდა ინერვიულოთ იმის შესახებ, რომ აპებმა ბოროტად გამოიყენონ მათი უწყვეტი წაკითხვის წვდომა დირექტორია. Google ამბობს, რომ დოკუმენტის ამომრჩეველს ექნება "განახლებული ტექსტი...იმისთვის, რომ Android-მა შეზღუდა გარკვეული საქაღალდეები შეირჩევა." ეს იმედია შეამცირებს დაბნეულობას იმის შესახებ, თუ რატომ არ შეუძლიათ აპებს წვდომის მინიჭება გარკვეულ დირექტორიაში აღარ.

დამატებითი ინფორმაციისთვის Scoped Storage და Play წესების ცვლილებების შესახებ, მიმართეთ ამ სტატიას.

სხვადასხვა თემები

• Google-ის პოზიცია rooting/modding-ზე
  • ჯეფ ბეილი Google-ის AOSP გუნდიდან იმეორებს კომპანიის პოზიციას არჩევანის მხარდასაჭერად. Google „გააგრძელებს იმის უზრუნველსაყოფად, რომ Pixel-ის ხაზის მოწყობილობების მოდიფიკაცია/დაფესვიანება შესაძლებელია“, მაგრამ ასევე „მხარდაჭერს OEM-ების არჩევანს, რომ არ დაუშვან მათი მოწყობილობები. გარდა ამისა, Google აძლევს პროგრამული უზრუნველყოფის დეველოპერებს არჩევანს „არ დაუშვან თავიანთი პროგრამული უზრუნველყოფის გაშვება root მოწყობილობებზე“, რაც შეეხება ბოლო ცვლილებებს SafetyNet Attestation API-ის პროგრამული შეყოვნების გამოვლენა.
• რა მოხდა "გახსნა და ნაგულისხმევად დაყენება"?
  • დამზადებულია Android 10 საკმაოდ შემაშფოთებელია აპლიკაციის ნაგულისხმევ დამმუშავებლად დაყენება კონკრეტული ბმულებისთვის, რომელიც Google-ის თქმით, გაკეთდა მომხმარებლების დასაცავად „ექსპლუატაციური აპებისგან“. Google-მა უკან დაიხია ამ ცვლილებაზე გადახედვის შემდეგ, მომხმარებლის დასაცავად "ცვლილების რაოდენობა კულისებში".
• იყენებთ Vulkan Graphics API-ს ინტერფეისის გასაფორმებლად?
  • Google საბოლოოდ აპირებს გამოყენებას Vulkan Graphics API ინტერფეისის გასაფორმებლად, რაც გამოიწვევს შესრულების გარკვეულ გაუმჯობესებას. Ეს არის ჯერ კიდევ ფასდება, მაგრამ კომპანიას არ ჰქონდა რაიმე სპეციფიკა გასაზიარებელი.
• გამოტოვებული CallScreeningService ბევრ მოწყობილობაზე
  • ანდროიდის აპებს შეუძლიათ დანერგონ CallScreeningService API ახალი შემომავალი და გამავალი ზარების აღკვეთა, რაც მათ საშუალებას აძლევს ამოიცნონ აბონენტი და მიიღონ ან უარყონ ზარი. მიუხედავად იმისა, რომ ეს არის ოფიციალურად დოკუმენტირებული API, როგორც ჩანს, ბევრი OEM არ ახორციელებს მას სათანადოდ, დეველოპერის /u/-ს მიხედვით._zeromod_. Google ადასტურებს რომ ეს API დადასტურებულია თავსებადობის ტესტის კომპლექტის (CTS) მიერ, ავტომატური ტესტირების კომპლექტით, რომელიც ყველა მოწყობილობამ უნდა გაიაროს, რომ ჩაითვალოს Android თავსებადად. ნებისმიერი მიზეზის გამო, ეს API ბრუნდება ნულოვანი, როდესაც გამოიძახებენ OEM-ის მოწყობილობებს, როგორიცაა Huawei, Vivo, Xiaomi ან Samsung, ასე რომ, სავარაუდოდ, ამ OEM-ებს აქვთ ხარვეზი პროგრამულ უზრუნველყოფაში.
• არ არის გეგმები აუდიო დანამატის ჩარჩოსთვის
  • დეველოპერმა ჰკითხა Google-ს, აპირებენ თუ არა აუდიო დანამატის ჩარჩოს დანერგვას, როგორიცაა Apple's Audio Units, მაგრამ პასუხი არის ის, რომ ნაკლებად სავარაუდოა, რომ ეს მოხდეს უახლოეს მომავალში.

თქვენ შეგიძლიათ წაიკითხოთ ყველა პასუხი Android-ის საინჟინრო გუნდისგან აქ. გუნდი რამდენიმე კომენტარში საუბრობს Java-ზე, Kotlin-ზე, Android build სისტემაზე, CameraX API-ზე და სხვა თემებზე. ასევე არის რამდენიმე კომენტარი Wear OS-ის, Android TV-სა და Android Auto-ს შესახებ, მაგრამ Google ძირითადად იმეორებს მათი არსებული მუშაობა ამ პლატფორმებზე და ეუბნება დეველოპერებს, რომ თვალყური ადევნონ მეტი ინფორმაციის მისაღებად "Android ტელეფონების მიღმა"კვირა, რომელიც იწყება 10 აგვისტოდან.