Როგორ ირჩევენ სმარტ ჰომის ჰაბის OEM პროექტები AOSP-სა და GMS Android არქიტექტურებს შორის

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

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

Ამიტომ ზოგიერთი მომხმარებელი იწყებს უფრო ღრმა კითხვების დასმას Android არქიტექტურაზე -ს შესახებ: უნდა იყოს მოწყობილობა სტანდარტული Android-ით და Google Mobile Services ( GMS )-ით? მოითხოვს თუ არ მოითხოვს პროექტი AOSP -ზე დაფუძნებული სისტემა გუგლის სერვისების გარეშე? რა ხარისხის კონტროლი არის საჭიროებული ყიდვას ახდენს პროგრამული უზრუნველყოფის დაყენებასა და მოწყობილობის ქცევაზე?

Სამი რეალური სახლის ცენტრალური მოწყობილობის წარმოებლის მოთხოვნა ნორვეგიიდან, ბელგიიდან და აშშ-დან სასარგებლო მაგალითებს წარმოადგენს. ისინი არ წარმოადგენენ მთლიანად სტუმრის სახლის სისტემების ბაზარს, მაგრამ აჩვენებენ, თუ როგორ აფასებენ სხვადასხვა ყიდვას ახდენს სისტემის მოთребებს თავიანთი დაყენების მიზნების მიხედვით.

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

Რატომ არის ზოგიერთი სტუმრის სახლის ცენტრალური მოწყობილობის პროექტს ანდროიდის სისტემებზე უფრო მეტი კონტროლი სჭირდება

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

Სპეციალიზებული ჭკვიანი სახლის ცენტრი მოჰყვება სხვადასხვა ლოგიკას. ბევრი OEM პროექტისთვის მოწყობილობას აქვს ერთი ძირითადი მიზანი: კონტროლირებულ გარემოში კონკრეტული პროგრამის სანდო გაშვება.

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

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

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

Სამი OEM-ის მოთხოვნა აჩვენებს Android-ის მორგების სხვადასხვა მიზეზს.

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

Ერთი ნორვეგიული სისტემის ინტეგრატორი მოუთხოვა AOSP -ფუძეზე დაფუძნებული ეკრანი без GMS , ასევე მოწყობილობის შეზღუდვები, როგორიცაა კამერისა და მიკროფონის კომპონენტების მოცილება. პროექტს სჭირდებოდა კიოსკის რეჟიმი ავტომატური APK-ის გაშვებით.

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

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

Მეორე პროექტი, რომელიც მოდის ბელგიაში მდებარე მოხუცების მოვლის ამოხსნის მიმწოდებლისგან, სხვა პრიორიტეტებზე იყო მიმართული. მოთხოვნილი ფუნქციები მოიცავდა 4G-კავშირს, WiFi-ს, კიოსკის რეჟიმი და გამარტებულ ინტერაქციის გამოცდილობას.

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

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

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

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

Სწორი Android არქიტექტურა დამოკიდებულია იმ პირზე, ვინ აკონტროლებს სახელმძღვანელოს გამოცდილებას.

Გადაწყვეტილება AOSP და GMS უნდა დაიწყოს აპლიკაციის მოდელით, არ არის საჭიროების მიხედვით ოპერაციული სისტემის პრეფერენციებით.

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

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

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

Ყიდვის მომხმარებლისთვის კი კითხვა არ არის უბრალოდ:

"შეუძლია ამ მომაწოდებელს Android-ტაბლეტის მომარაგება?"

Უფრო მნიშვნელოვანი კითხვა არის:

"შეძლებს თუ არა ეს მომწოდებელი ჩვენს პროექტს საჭიროებული სრული აპარატურისა და პროგრამული უზრუნველყოფის დაყენების მოდელის მხარდაჭერას?"

Უნდა დავადასტუროთ კონფიდენციალურობის მოთხოვნები, არ უნდა ვივარაუდოთ ისინი

Მოთხოვნები, როგორიცაა "GMS-ის გარეშე", "კამერის გარეშე" ან "მიკროფონის გარეშე", ხშირად იზიდავენ ყურადღებას, რადგან შეიძლება მიუთითონ მკაცრი კონფიდენციალურობის ლოგიკაზე.

Თუმცა, ზუსტი მოტივაცია არ უნდა ვივარაუდოთ.

Სამ შემოწმებულ პროექტში მხოლოდ ერთი ყიდვის მომხმარებელი მოუთხოვა საკონკრეტო GMS-საფუძველგარეშე  AOSP გარემო. დანარჩენი ორი პროექტი არ ახსენებს ამ მოთხოვნას.

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

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

Ამ მოთხოვნების ადრეული შემოწმება შეიძლება შეამციროს არასაჭიროებრივი ინჟინერული სამუშაოები და თავიდან აიცილოს ძვირადღირებული ცვლილებები განვითარების დაწყების შემდეგ.

Კიოსკების განთავსება ხდება სპეციალიზებული სმარტ-ეკრანების საფუძვლად.

Მიუხედავად იმისა, რომ სამივე მყიდველს სხვადასხვა პრიორიტეტი ჰქონდა, ყველა პროექტს ჰქონდა მსგავსი მიმართულება: ეკრანს საჭიროებდა სპეციალიზებული სერვისის ინტერფეისის ფუნქციონირება.

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

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

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

OEM სმარტ-ეკრანის პროექტის დაწყებამდე ჯერ კიდევ განსაზღვრეთ ეს გადაწყვიტებები

Მოთხოვნის გაკეთებამდე Ანდროიდის დისპლეის OEM ამოხსნა, ყიდვის პროცესში უნდა განისაზღვროს ოთხი პროექტის საზღვარი:

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

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

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

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

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

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

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

Დაუკავშირდეთ ჩვენს გუნდს თქვენი პროექტის მოთხოვნების განხილვის ან მოთხოვნის წარდეგების გასაგზავნად მორგებული Android დისპლეის ამოხსნის მისაღებად.