Ანდროიდ კიოსკის დაყენება: რა უნდა გააკეთოთ, როდესაც მოწყობილობის მფლობელი გამოგირთავთ პარამეტრებში შესვლის უფლებიდან

A10,1 ინჩიანი Android ტაბლეტი კიოსკის გამოყენებისთვიალ დაკონფიგურდა ADB-ის, მომხმარებლის მიერ შექმნილი ლაუნჩერისა და Device Owner-ის საშუალებით. რებუტის შემდეგ აპლიკაცია ჩაიტვირთა მოსალოდნელად, მაგრამ მოწყობილობა ვეღარ შეძლებდა ნორმალური Android პარამეტრების ინტერფეისზე წვდომას.

Ეს შექმნა კიოსკის დაყენების გამოყენების საერთო გამოწვევას: როგორ შეიძლება მოწყობილობა აღდგენილ იქნას მომდევნო ტესტირებისთვის, როდესაც სისტემური ნავიგაცია და მოწყობილობის მართვის კონტროლები შეზღუდულია? ასევე, თუ აპლიკაციას სჭირდება Wi-Fi ან სხვა სისტემური ფუნქციების გახსნა, რომელი Android Intents შეიძლება ჯერ კიდევ გამოყენებულ იქნას?

Კლიენტმა ჯერ კიდევ ADB ბრძანებების გამოყენებით შეცვალა სისტემური UI ქცევა:

adb shell settings put system hide_navbar 1

adb shell settings put system statusbar_disp 1

adb shell settings put system swipe_show_nav_bar 0

adb shell settings put system power_button_show 0

Შემდეგ აპლიკაცია დაყენდა როგორც ნაგულისხმევი მთავარი ეკრანი, ხოლო შემდეგ აპლიკაცია დაკონფიგურდა როგორც Device Owner საჭიროების მიხედვით მოწყობილობის მართვის ფუნქციების გასააქტიურებლად.

Გადატვირთვის შემდეგ, Android kiosk tablet აპლიკაცია ავტომატურად გაიხსნა მოსალოდნელად. თუმცა, მომხმარებელს აღარ შეეძლო აპლიკაციის მთავარი ეკრანიდან გასვლა Android-ის პარამეტრების ან სხვა სისტემური ფუნქციების წვდომის მისაღებად. აპლიკაციაში ჩაშენებული პარამეტრებისა და Wi-Fi-ის ღილაკებიც შეაჩერდა შესაბამისი სისტემური გვერდების გახსნა.

Პირველად არ იყო მხოლოდ ის კითხვა, თუ როგორ გავიდეს აპლიკაციიდან. მომხმარებელს სჭირდებოდა სანდო გზა ამ Ანდროიდ ტაბლეტი -ის აღდგენის მისაღებად მომდევნო ტესტირების მიზნით, ასევე სჭირდებოდა გაგება, რომელი სისტემური Intents შეიძლება გამოიყენოს მათი აპლიკაციამ.

Რატომ გახდა Android-ის ტაბლეტი წვდომის რთული

Პრობლემა მოწყობილობის რამდენიმე დონის კონტროლის ერთდროულად გამოყენების შედეგად წარმოიშვა.

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

ADB-ის ბრძანებები სისტემური UI-ის ქცევის ცვლილებით კიდევა ერთ დამატებით სარეცხავს დაამატეს. ეს კონკრეტული პარამეტრები მოწყობილობაზე ან სტანდარტულ ხარისხზე დამოკიდებულია, არ არის უნივერსალური Android-ის API-ები, ამიტომ მათი ზუსტი ეფექტი დამოკიდებულია ტაბლეტის სტანდარტული ხარისხის მიერ მათი განხორციელებაზე.

Ეს ნიშნავს, რომ Კიოსკის მოწყობილობად გამოყენებული Android-ის ტაბლეტი შეიძლება ძალიან რთული გახდეს აღდგენა, როდესაც მისამართებლი, მოწყობილობის მფლობელის კონფიგურაცია, სისტემური UI-ის შეზღუდვები და აპლიკაციის ნავიგაცია ერთდროულად იცვლება.

Ის ფაქტი, რომ აპლიკაციის პარამეტრების ან Wi-Fi ღილაკი მეტყველებს აღარ მუშაობს, არ ნიშნავს აუცილებლად ინტენტის შეცდომით ჩაწერას. სამიზნის პარამეტრების აქტივიტი შეიძლება იყოს ხელმისაწვდომი არ ყოფილი, შეზღუდული ან სხვა გზით მიუწვდომელი მოწყობილობის მიმდინარე კონფიგურაციის შემთხვევაში. Android-ის რეკომენდაცია ასევე მოითხოვს ინტენტის გადაჭრის შესაძლებლობის შემოწმებას მის გაშვებამდე.

Დაბლოკილი Android კიოსკის ტაბლეტის აღდგენის გზები

Თუ აპლიკაცია უკევე მოწყობილობის მფლობელად არის განსაზღვრული, პირველ რიგში უნდა განხილული იყოს პროგრამული აღდგენის ვარიანტი.

Android-ის DevicePolicyManager მოწყობილობის მართვის ფუნქციებს სთავაზობს, რომლებსაც მოწყობილობის მფლობელი შეიძლება გამოიყენოს. Android-ის ვერსიისა და აპლიკაციის კონფიგურაციის მიხედვით, მოწყობილობის მფლობელის აპლიკაცია შეიძლება გამოიყენოს შესაბამისი მოწყობილობის გასუფთავების მექანიზმი, რათა ტაბლეტი სატესტო მიზნებისთვის სუფთა მდგომარეობაში დაბრუნდეს. wipeData() არის მომხმარებლის მონაცემების გასუფთავების დამკვიდრებული API, ხოლო ახალი Android-ის ვერსიები მოწყობილობის გასუფთავების დამატებით ფუნქციონალს სთავაზობს.

Მოძაბლებული clearDeviceOwnerApp() მეთოდი არ უნდა მიიჩნევოს ზოგადი წარმოების აღდგენის მეთოდად. Android ამ მეთოდს როგორც ტესტირების მიმართული API-ს აღწერს და მოწყობილობის მფლობელის ურთიერთობის წაშლის ჩვეულებრივი გზად ქარხნულ რესეტს არჩევს.

ADB ასევე მოწარმოებს მოწყობილობის პოლიტიკის მართვის ბრძანებებს, მაგრამ ეს ბრძანებები შეზღუდვებს იძლევა. მაგალითად, adb shell dpm remove-active-admin არ არის უნივერსალური მეთოდი მოწყობილობის მფლობელის წაშლისთვის; Android-ის ADB დოკუმენტაცია მოთხოვს აპლიკაციის testOnly დეკლარაციას.

Თუ პროგრამული აღდგენა შეუძლებელია, რადგან აპლიკაცია ვერ ასრულებს საჭიროებულ მოქმედებას, დარჩენილი გზა არის ჰარდვერული ქარხნული რესეტი ან Android Recovery პროცედურა .

Ზუსტი ღილაკების კომბინაცია არ უნდა დავუშვათ სხვა Android ტაბლეტის მოდელიდან. აღდგენის ქცევა განისაზღვრება ტაბლეტის ფირმვერისა და ჰარდვერის იმპლემენტაციით. მორგებული Android ტაბლეტის პროექტის შემთხვევაში, შესაბამისი აღდგენის პროცედურა ამ კონკრეტული მოდელისა და ფირმვერის მიხედვით უნდა დადასტურდეს დეპლოიმენტამდე.

Ამ ტიპის Android kiosk tablet , განსაკუთრებით სასარგებლოა აღდგენის მეთოდის არსებობა ინტეგრაციის ტესტირების დროს, რადგან სისტემური კონფიგურაცია შეიძლება მიზნად ჰარების ნავიგაციის წაშლას.

Android ტაბლეტზე პარამეტრების ინტენტებისა და სისტემური ფუნქციების ტესტირება

Მომხმარებლის მეორე კითხვა იყო, შეიძლება თუ არა აპლიკაციამ პირდაპირ გააშვას სისტემური ფუნქციები, როგორიცაა პარამეტრები და Wi-Fi.

Android ამ ფუნქციებისთვის სტანდარტულ პარამეტრებს აწარმოებს. მაგალითად:

Ფუნქცია	Სტანდარტული Android ინტენტი
Ძირითადი პარამეტრები	Settings.ACTION_SETTINGS
Wi-Fi პარამეტრები	Settings.ACTION_WIFI_SETTINGS
Უკაბელო პარამეტრები	Settings.ACTION_WIRELESS_SETTINGS
Ბლუტუთის პარამეტრები	Settings.ACTION_BLUETOOTH_SETTINGS
Ეკრანის პარამეტრები	Settings.ACTION_DISPLAY_SETTINGS
Მდებარეობის პარამეტრები	Settings.ACTION_LOCATION_SOURCE_SETTINGS
Ხმის პარამეტრები	Settings.ACTION_SOUND_SETTINGS
Უსაფრთხოების პარამეტრები	Settings.ACTION_SECURITY_SETTINGS
Აპლიკაციის პარამეტრები	Settings.ACTION_APPLICATION_SETTINGS
Კონკრეტული აპლიკაციის პარამეტრები	Settings.ACTION_APPLICATION_DETAILS_SETTINGS

 

Ეს არის სტანდარტული Android-ის პარამეტრების მოქმედებები, არ არის კონკრეტული Android-ის ტაბლეტის წარმოებლის . თუმცა, Intent-ის არსებობა არ გარანტირებს, რომ ის წარმატებით გაიხსნება ყველა მოწყობილობაზე ან ყველა კიოსკის კონფიგურაციაში. Android რეკომენდაციას აძლევს Intent-ის შემოწმებას resolveActivity() -ით მის გაშვებამდე.

Ამიტომ სისტემის ინტეგრირებული Android ტაბლეტისთვის Intent-ის ტესტირება უნდა შესრულდეს ფაქტიურად გამოყენებულ ფირმვერზე და Android-ის ვერსიაზე. ტესტი უნდა დაადასტუროს არ მხოლოდ Intent-ის არსებობა, არამედ ისიც, რომ შესაბამისი Activity ხელმისაწვდომია Device Owner-ის, ლაუნჩერის და სისტემური UI-ს შეზღუდვების გამოყენების შემდეგ.

Თუ თქვენ მუშაობთ Android კიოსკის ტაბლეტზე ან სისტემის ინტეგრაციის პროექტზე და სჭირდებათ დახმარება Device Owner-ის აღდგენაში, Settings Intent-ებში ან მათთან დაკავშირებულ კონფიგურაციურ საკითხებში, გთხოვთ დაგვიკონტაქტოთ თქვენი ტაბლეტის მოდელითა და Android-ის ვერსიით. შეგვიძლია განვიხილოთ ხელმისაწვდომი ტექნიკური მხარდაჭერა და პერსონალიზაციის ვარიანტები.

 

Იგივე პრინციპი ვრცელდება სხვა სისტემურ ფუნქციებზეც. სტანდარტული Android API შეიძლება არსებობდეს, მაგრამ მორგებული ტაბლეტის ფაქტიური მოქმედება დამოკიდებულია მისი Android-ის ვერსიაზე, ფირმვერის კონფიგურაციაზე და მოწყობილობის მართვის პოლიტიკებზე.

Ხოლო Wake Request-ების შესახებ?

Მომხმარებლის კითხვა «გაღების მოთხოვნების» შესახებ ცოტა განსხვავდება პარამეტრების გვერდის გაშვებისგან.

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

Თუ მოთხოვნა არის ეკრანის გაღება, ეკრანის გაღებულად შენახვა ან ეკრანის ჩართვის მოქმედების კონტროლი , შესაბამობის მექანიზმი დამოკიდებულია კონკრეტულ აპლიკაციის მოთხოვნებზე. Android ამ სცენარებისთვის აძლევს ენერგიის მართვისა და ფანჯრების/აქტივობების API-ებს, მათ შორის PowerManager და საჭიროების შემთხვევაში გაღების ბლოკირების ფუნქციონალობას.

Ეს განსხვავება მნიშვნელოვანია აპლიკაციების დამზადებისას Android kiosk tablet . «სისტემური ფუნქციის გაშვება» და «მოწყობილობის ენერგიის მდგომარეობის კონტროლი» სხვადასხვა სისტემური ოპერაციაა და უნდა მოიხსენიებოდეს სხვადასხვა API-ით.

Ანდროიდის ტაბლეტების ინტეგრაციის ტექნიკური მხარდაჭერა

Ეს შემთხვევა ასევე აჩვენებს, რატომ მოითხოვს კიოსკის დაყენება ანდროიდის ტაბლეტის ძირითადი აპარატული კონფიგურაციის გარდა დამატებით რამეს.

Როდესაც ტაბლეტი ინტეგრირებულია სპეციალიზებულ აპლიკაციაში, გაყიდვების სისტემაში (POS), კიოსკში, სამრეწველო სისტემაში ან სხვა მართვად მოწყობილობაში, პროგრამული უზრუნველყოფის კონფიგურაცია შეიძლება ერთდროულად მოიცავდეს ლაუნჩერს, მოწყობილობის მფლობელს (Device Owner), სისტემის ინტერფეისს, აპლიკაციის ნებართვებს, პარამეტრების ინტენტებს და აღდგენის ქცევას.

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

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

Თუ თქვენ ტესტავთ Ანდროიდ ტაბლეტი კიოსკის დაყენების ან სისტემური ინტეგრაციის მიზნით და ამ პროცესში წარმოიშობა მსგავსი პრობლემები Მოწყობილობის მფლობელი, მორგებული ლაუნჩერები, კიოსკის რეჟიმი, პარამეტრების ინტენტები, სისტემური ინტერფეისის შეზღუდვები ან მოწყობილობის აღდგენა , მიმართეთ დაგვიკავშირდით ტექნიკური მხარდაჭერის სამსახურს .

Შეგიძლიათ მიაწოდოთ თქვენი ტაბლეტის მოდელი, Android-ის ვერსია, დაყენების კონფიგურაცია და კონკრეტული ფუნქცია, რომელსაც სცადით განხორციელებას. Android-ის ტაბლეტების მორგება და ტექნიკური მხარდაჭერა თქვენს პროექტზე შესაძლებლობები.