Recepta na rozgardiasz dotyczący zróżnicowania wersji Androida
- Dodano: 31 marca 2010
- Wprowadził: Szymon Barczak
- Komentarze: 15
Firma Google, twórca systemu operacyjnego Android, ogłosiła, iż ma zamiar zaradzić w końcu problemowi zróżnicowania wersji swej mobilnej platformy na poszczególnych telefonach.
Według Engadget, Google ma zamiar zmienić sposób w jaki dostarczany jest Android – zamiast obecnej, zwartej całości, która wraz z każdą kolejną wersją posiada większe wymagania odnośnie zasobów systemowych, system firmy Google będzie dostarczany goły, z możliwością dogrania poszczególnych aplikacji z Android Marketu. W ten sposób telefony, które nie mogą stanąć w szranki z nowymi modelami – te, które są znacznie słabsze pod względem wykorzystanych podzespołów – będą mogły posiadać Androida w najnowszej wersji, ze zmniejszonym, odpowiednim do wymagań użytkownika pakietem aplikacji.
Pomysł firmy Google brzmi naprawdę świetnie. Miejmy nadzieję, że dzięki niemu użytkownicy nareszcie będą mogli przestać zawracać sobie głowę informacjami od producenta telefonu dotyczącymi nowej wersji Androida dla konkretnego modelu, czy też nie będą musieli instalować nieoficjalnych wydań Androida, tylko po to, by posiadać jego najnowszą wersję. Jest to o tyle problematyczne, iż często użytkownicy muszą wybierać między oficjalną, ale nieaktualną wersją Androida, a nową, nieoficjalną, gdy chcą korzystać z nowych funkcjonalności, np. nie posiadając odpowiedniej wersji systemu nie można zainstalować Google Maps.
Więcej informacji: http://androidlab.pl/wersje-androida-zos...dnolicone/
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
15 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
jeszcze, żeby dało się usunąć zbędne dodatki typu TouchFlo, to już byłaby bomba!
no tak, ale co to zmieni? jak nowy chrome będzie potrzebował 2.1 to będzie dalej potrzebował. będą musieli utrzymać kompatybilność wsteczną z 1.6, a to doprowadzi do zwiększenia objętości programów i spowolnienia systemu. najlepiej jakby po prostu wymuszali na producentach zmiany softu i ustalenie wymagań co do pamięci na odpowiednio wysokim poziomie, tak żeby co chwilę nie trzeba było zmieniać telefonu.
IMHO to jest bardzo dobry pomysł. Producent komórek dostarcza tylko driverów a nie systemu z wbudowanymi driverami (ja tak rozumiem ten mechanizm). Drivery będą pasować do nowego OSu tak długo aż w jajku nie zmieni się coś bardzo poważnego (czyli raczej bardzo długo).
W dodtychczasowym modeli jest mocny problem: mam komórkę Samsung Galaxy z Androidem 1.5 i żadnych perspektyw na upgrade do choćby 1.6. Dzięki temu kilka aplikacji już mi nie działa a część ma ograniczoną funkcjonalność – nie wynika to z ograniczeń sprzętu tylko softu.
Producent sprzętu chętniej wypuści nowy sprzęt niż aktualizację – więcej na tym zarobi. Ten pomysł Googla uprości sprawę, producent sprzętu praktycznie nic nie będzie musiał robić a użytkownik będzie miał możliwość upgrade systemu operayjnego.
Android odziedziczył problemy po swojej matce-linuxie
Co by nie mówić o Windowsie to nie ma dużych problemów w uruchamianiu oprogramowania pomiędzy różnymi jego wersjami. Pod Linuxem jak przenoszę np. program zrobiony z użyciem Qt na inny komputer to muszę go przekompilować żeby dało się odpalić bo wersja bibliotek jest zamiast 4.5.0 to 4.5.1 
Dla Linuxa jedynym ratunkiem jest chyba statyczna kompilacja. Takie rzeczy niestety odstraszają firmy produkujące soft przez co nie wydają wersji na linuxa. Generuje to duże koszta, bo trzeba program przetestować na bardzo wielu wersjach systemu w różnych konfiguracjach bibliotek. Wracając do androida to niedługo będzie kiladziesiąt różnych jego wersji, które będą nijak kompatybilne ze sobą i użytkownicy przestraszeni mnogością wersji będą wybierać iPhona 
z tą kompatybilnością bibliotek to przesadzasz. od dwóch lat mając Opensuse NIGDY nie miałem takiego problemu, a często mam wersje unstable. Tak dla ciekawości mam teraz Qt 4.6.2.-98.1 i wszystko działa rewelacyjnie
Jeśli masz program skompilowany z Qt 4.4 to i uruchomisz go bez rekompilacji z Qt 4.5, a tym bardziej przy przejściu z Qt 4.5 na Qt 4.5.1.
Jesteś pewien?
Wielokrotnie robiłem upgrade Qt na wersję o "jedno oczko wyżej" tj. zmiana drugiego numerka, i KDE albo nie chciało ruszyć w ogóle albo wstawało, ale sypały się niektóre programy. Zresztą problem nie dotyczy tylko Qt. W praktyce bardzo łatwo zerwać kompatybilność wsteczną biblioteki, zwłaszcza kodując w językach, które nie wspierają enkapsulacji (rozdzielenia interfejsu od implementacji).
Ba, nawet w językach, które mają porządną enkapsulację i lepszy model kompilacji, też nie zawsze się udaje zachować kompatybilność wsteczną bibliotek.
Wielokrotnie robiłem upgrade GTK+ na wersję o "jedno oczko wyżej" tj. zmiana drugiego numerka i GNOME działał po takiej operacji bez problemów
Jak się linkuję program dynamicznie z Qt to nie ma siły by z ciut inną wersją Qt ten program dalej działał stabilnie lub się w ogóle uruchamiał (przerabiałem to pisząc własne na Windows i Linux).
To jest niestety następstwo eksportowania zwykłych klas C++ z biblioteki Qt – gdyby to były "pure abstract/virtual bace class" – czyli interface, a implementacja była by ukryta, to nie było by problemu.
Takie mechanizmy pisania komponentów z użyciem "interface" są używane w technologii COM/DCOM/COM+/ActiveX(+ATL) Microsoftu, ale także w XPCOM Mozilli.
Niestety używanie takich "komponentów" już nie jest takie fajne z poziomu C++.
GTK i gołe WinAPI ma tę piekielną zaletę nad Qt, że jest zgodne z export "C" i używa "uchwytów" i przez to łatwo o zachowanie zgodności i jednocześnie rozszerzalności interface.
Proszę o trochę minusów… jak zwykle.
Dlatego instalacja Windows Vista zajmuje 4GB – bo musi zawierać wszystkie stare biblioteki. Dla mnie to nie jest rozwiązanie problemu tylko ich mnożenie… Utrzymanie głębokiej wstecznej kompatybilności jest bardzo kosztowne.
W przypadku OpenSource wszystko jest w źródłach więc dla każdego nowego systemu można przekompilować do bieżącej wersji, ale powinie to zrobić wydawca dystrybucji a nie Ty.
Chyba ci jedynka sprzed tej czwórki uciekła
nie chodzi o "dostarczanie gołego systemu" a o pakietyzację, oddzielenie jądra i sterowników (dostarczanych przez producentów telefonów) od wyższych warstw systemu tak aby bez zmiany jądra (bo działa i nie wymaga zmiany) można było odpalać sobie instalować aplikacje z nowszych wersji (system zależności zadba aby potrzebne pakiety zostały zaktualizowane, nie jesteśmy zdani na łaskę lub brak producenta który musi nową wersję przygotować). Android wreszcie wyszedł z modelu dostarczania systemu w tradycyjnych telefonach (dostarczanie pełnego obrazu systemu) do modelu obecnego w systemach operacyjnych.
A jaki system pakietów będzie rpm deb czy coś jeszcze?
Prawdę powiedziawszy to nie wiem, czy "rozgardiasz" się zmniejszy.
Wg autora artykułu: do tej pory musiałem wiedzieć, czy telefon obsłuży np. Androida 2.1. Teraz będę musiał wiedzieć, czy obsłuży np. jednocześnie jądro 2.1 (potrzebuję do jakiejś aplikacji), mój pakiet GPS, najnowszy pakiet z odtwarzaczem audio-video i pakiet modemu 3G.
Pożyjemy – zobaczymy. Mam nadzieję, że nie przegną, bo >95% użytkowników nie ma zamiaru myśleć jaki ma OS w telefonie i w nim grzebać albo podejmować trudne decyzje zakupowe. Wielu kupuje iPoda dlatego, że "to mają inni" i to jest "bezpieczne rozwiązanie". Dlatego platforma dla geeków umrze z przyczyn komercyjnych.
Rozwiązanie, które _pozwoli_ na "customizację", jest O.K. Ale rozwiązanie, które ją _wymusi_, umrze.
Ty to złośliwie piszesz?