Google mostra as versões do Android mais populares

Por: em 04/05/10 na(s) categoria(s): Celular, Google, Meio Bit, Mobile, Software

comentários 23

O Android, mesmo não estando exatamente sob as asas do Google, mostra que guarda consigo algumas características herdadas da empresa que o lançou no mercado, como o rápido e constante desenvolvimento. Em pouco mais de dois anos no mercado, esse sistema móvel já encontra-se na versão 2.1, e a próxima, 2.2, já está sendo preparada.

Fazer os usuários atualizarem seus sistemas já é complicado por si só, quando entram operadoras e questões burocráticas no meio, então… Um dos maiores problemas da plataforma Android é a fragmentação de versões disponíveis no mercado. Isso porque novos recursos/APIs inviabilizam a execução de um aplicativo em todas as versões, restringindo-as, em alguns casos, às mais novas. O cliente oficial do Twitter para Android, lançado recentemente, é um belo exemplo disso. Como só funciona na versão 2.1 ou posterior, muitos usuários ficaram privados de usá-lo.

Para ajudar desenvolvedores a tomar decisões nessa área, regularmente são liberados gráficos que mostram, em média, qual a participação de mercado de cada versão do Android. Os dados não são absolutos porque baseiam-se nos acessos ao Android Market, e como sistema aberto que é, fabricantes e operadoras têm o direito e realmente vedam o acesso de alguns de seus aparelhos à principal loja de apps do Android. De qualquer maneira, é um bom (se não o único) parâmetro para conhecer essa divisão.

Versões do Android que rodam por aí...

Versões do Android que rodam por aí...

O gráfico é baseado nos acessos ao Android Market realizados entre 19 de abril e 3 de maio, e mostra que, hoje, três versões dominam o cenário: 1.6, com 29,4%; 2.1, com 32,4%; e 1.5, a mais popular de todas, com 37,2%.

Uma olhada no gráfico de dezembro de 2009 mostra que a fragmentação está aumentando na medida em que novas versões do Android são lançadas. Naquela época, a versão 1.6 respondia por cerca de 56% dos dispositivos.

Divisão de versões do Android em dezembro de 2009.

Divisão de versões do Android em dezembro de 2009.

Será que é hora da Open Handset Alliance dedicar tempo ao desenvolvimento de uma solução de atualização mais unificada e eficiente? Ou a própria natureza aberta do Android inviabiliza esforços nessa área?

Fonte: BetaNews.

Assuntos: #, #, #, #, #

Blogger, bacharel em Direito e acadêmico de Sistemas de Informação.

Mais textos de | Site | Twitter

  • Quantum

    Mesmo problema do Linux.

  • dalraf

    Acho que o Android 2.2 virá com a possibilidade de atualizar o aparelho via android market, isto pode amenizar o problema.

    • Edu Lacerda

      @dalraf, Atualizar programas pode até ser. Mas e quanto às interfaces customizadas, APIs, e coisas como baseband?

      • dalraf

        @Edu Lacerda, é uma atualização do OS.

      • http://www.bsrsoft.com.br André Luis Pereira dos Santos

        @Edu Lacerda,

        Isso é tarefa de quem embarcou a versão X do Android em determinado dispositivo.

        Assim como a Canonical, Red Hat, SUSE etc atualizam seus sistemas, aplicativos e APIs e todos compartilham o mesmo kernel (Linux), o pessoal que distribui dispositivos com Android deveriam fazer o mesmo.

        Todas essas empresas de Linux que eu enumerei acima seguem bem de perto os lançamentos do kernel Linux. Nenhuma fica pra traz.

        Parece ser puro relaxo das empresas que vendem celulares e gadgets com Android. Essa é a impressão que fica.

        Tecnologicamente falando, atualização de sistemas Linux (Android incluido) é uma coisa muito bem resolvida à muito tempo.

        • Edu Lacerda

          @André Luis Pereira dos Santos,
          Sim, concordo contigo. Há um certo relapso sim das empresas. Espero que nos telefones realmente Google (Nexus One alguém?) o próprio Google tenha controle direto, dando suporte nos mesmos moldes que a Apple faz e por no mínimo 2 anos.

  • livestrong

    Rodrigo, a partir da versão Froyo, a disponibilização de atualizações deverá ocorrer pelo Market, o que minimizará bastante o problema de fragmentação. Resta saber se os usuários estarão dispostos a abrir mão das versões personalizadas pelos fabricantes (Sense e afins). Eu particularmente troquei por uma ROM do Cyanogen e estou satisfeito. O problema (creio eu) é que os fabricantes investem em personalizar o SO e quando vão lançar um produto já há outra versão oficial disponível. Por exemplo, o novíssimo Xperia X10 vem com a versão 1.6 personalizada e após uma enxurrada de reclamações teve até que dar satisfação e prometer uma atualização de versão para o próximo trimestre:

    http://www.sonyericsson.com/br/preview/geral/o-xperia%E2%84%A2-x10-o-android-1-6-e-o-2-1

    Abraço.

    • Wallacy

      @livestrong,

      Nesse caso basta as empresas criarem “pacotes” com suas customizações. Ao atualizar a versão, basta rodar novamente o “pacotão” de customizações e pronto.

      Seria análogo aos complementos do Firefox, onde mesmo que o “complemento” não seja portado, o usuário poderá usar a nova versão até o complemento se compatibilizar.

      Fora que muitas vezes não é necessário fazer nenhuma alteração no novo complemento, basta compilar novamente na nova versão. (Assim como vários softwares da versão 1.6 funcionam na versão 2.1 sem modificações.)

      • livestrong

        @Wallacy,
        Acredito que não seja tão simples assim. Tomo por base vendo o trabalho que o pessoal (Cyanogen, XDA-Developers, etc) tem para portar uma ROM para outra versão. Estava olhando o ChangeLog onde eles portam o Eclair para rodar no Hero ou no G1/Magic. São inúmeros problemas a serem resolvidos até a versão passar a ser estável, principalmente devido a conflitos de drivers cujo hardware foram especificados para rodar sobre uma versão anterior.

        • Wallacy

          @livestrong,

          São contextos diferentes.

          Uma coisa é um software ter que se adequar a uma ou outra biblioteca, outra é o SO ter que selecionar a biblioteca padrão a ser usada em cada device.

          Um excelente exemplo é o sistema de gerenciamento de pacotes do Linux. Você sai do openSUSE 11.1 para o 11.2 que usam bibliotecas e temas totalmente diferentes tudo em “1 clique”, assim como do Ubuntu 9.04 para o 9.10, por exemplo. Veja que nesse contexto todo o core do SO é mudado, inclusive a versão do kernel. Se um software usa uma biblioteca na versão 9.04 e ela não é usada na versão 9.10 (ou foi atualizada e não suporta mais o software) essa biblioteca é mantida. E por ai vai.

          Manter dependências dos softwares é outra historia. Mesmo no caso de uma operadora ter que fazer atualizações diretas na compilação das “personalizações”, essas “mudanças” podem muito bem vir direto no pacote. Outro exemplo extraído do Linux é quando precisamos instalar um modulo no kernel. Esse modulo é instalado “online” na versão presente do kernel independente que a minha é a .23 e a sua a .26. Cabe ao programa (e o programador) exclarecer exatamente qual requisito ele precisa do SO, para o SO previamente poder dizer: OK, a versão .27 não suporta tal recurso, o software não pode ser instalado. Nesse caso as operadoras (ou qualquer outra empresa) teria exatamente o mesmo trabalho que teria para adaptar o software.

          Isso obriga as operadoras a praticarem “boa programação” e evitar fazer personalizações “amarradas”, a uma unica e exclusiva versão.

          Sem contar que falei de um “pacote” que faz as modificações em uma versão que é padrão em todos os aparelhos. Quando uma nova versão do Android for liberada no Market, a empresa/operadora terá acesso a mesma (até porque ela está no Market), assim ela irá saber exatamente o que é necessário ou não conter nesse pacote para fazer tais mudanças. Mesmo que não fosse o caso, essa versão seria exatamente a que ela receberia antes do Google, afinal o Google não libera uma versão diferente para cada empresa, ela libera a mesma versão e a partir dessa elas fazem as modificações. Seria no caso necessário só que elas fizessem um pacote para fazer essas mesmas alterações na versão disponibilizada do merket.

          • livestrong

            @Wallacy,
            Acho que me expressei mal. Quando disse que não acredito ser simples como você citou, não me referia a atualizações por pacote, de forma online. Isto o CMUpdater já faz e funciona muito bem, tal como o Linux faz e como o Froyo promete fazer. O que discordei é quando você disse “Ao atualizar a versão, basta rodar novamente o “pacotão” de customizações e pronto.”

            Nos casos das Roms do Cyanogen, sem dúvida não é tão simples assim, pois eles não tratam apenas de customizações de interface, vão mais a fundo como melhorias no gerenciamento da bateria, tempo de latência do processador, entre outros. No caso de personalizações que visam principalmente interface, como o Sense UI, talvez seja mais simples mas não acredito que a tal ponto de simplesmente “ter algo pronto para novas versões”. Por exemplo, para lançar uma customização projetada no Android 1.6 para o Android 2.1, você precisa ver quais novos recursos foram incorporados, quais melhorias a interface recebeu originalmente, testar se a sua interface personalizada se adapta ou não a essas alterações (um pequeno exemplo são os live wallpapers, gerenciamento de janelas, pilha de atividades, sem nem entrar na questão de compatibilidade de hardware).

            Este esforço que eu acredito (infelizmente) que os fabricantes não estejam dispostos a realizar. Talvez simplesmente prefiram se concentrar no desenvolvimento de novos produtos.

            Mesmo assim fiquei curioso e vou tentar me aprofundar mais no assunto.
            Abraço.

          • Wallacy

            @livestrong,

            E qual a diferença? Eles vão ter que seguir todos esses passos de qualquer forma. e todos referentes ao mesmo modelo de base.

            Vou tentar falar de outra forma.

            Google Libera versão X do android -> fabricante recebe e analisa versão X -> fabricante propõe modificações na versão X -> fabricante implementa alterações -> fabricante libera versão modificada para o usuário.

            Google Libera versão X do android -> Usuário recebe versão X do android “limpa” / Fabricante também recebe e analisa versão X -> fabricante propõe modificações na versão X -> fabricante implementa alterações -> Fabricante libera versão modificada como patch para a versão já presente no aparelho do usuário.

            Por isso dei o exemplo do kernel Linux, independente de quais alterações são feitas, elas não precisas ser feitas necessariamente antes de ser instalado, basta aplicar o patch depois, isso se o sistema de pacotes for inteligente.

            Exemplo: Kernel Linux full com 40MB, usuário vai lá e instala. Digamos que o SuSE faça diversas modificações, incluindo mudança como o kernel da boot e gerencia memória e retira varios modulos, a versão “full” com essas modificações fica em 19MB. Dai ela empacota uma versão com 19MB com “tudo”, e outra “delta” (patch rpm no caso) com 5MB (por exemplo) que aplica todas as modificações no pacote de 40MB tornando exatamente igual ao de 19MB. Ou seja, no pacote possui as rotinas para remover os modulos considerados desnecessários, e aplicar as modificações onde tiver que ser aplicada.

            No caso do pacote RPM por exemplo, esses pacotes deltas e patch (os deltas são só as modificações de uma versão para outra, os patchs rpm podem fazer isso além de aplicar modificações em outro pacote) são feitos com algoritmos especializados que analisam as “transformações” de um pacote em outro.

            A tecnologia existe, basta eles usarem.

      • http://AlexandreCunha.com Alexandre Cunha

        @Wallacy,

        O conceito de criação de “pacotes” com as customizações do fabricante é interessante, mas pode ser contrário aos interesses comerciais do fabricante. Muitas vezes o que assistimos é que o fabricante quer descontinuar o suporte a um produto para poder ter espaço e mercado para vender outro que apesar de não ser muito diferente, distingue-se por novas versões de software.

        Assisti a isso com a HTC com não disponibilização de ROMs com novas versões de windows mobile. Por tenho duvidas eles que façam a criação de pacotes das customizações para as novas versões do SO Android.

        Dono de Android há menos de uma semana e não tenciono depender do fabricante no que refere a atualizações de software.

        • Wallacy

          @Alexandre Cunha,

          Isso é verdade, porém “destruir” é mais fácil que “construir”, vale a esperteza da empresa para adicionar um requerimento impossível de ser resolvida em uma versão anterior do device.

          E de quebra ela ainda culpa o SO pela incompatibilidade. Como o gerenciamento dos pacotes é feito online, o usuário não saberia nem qual é tal requerimento, só receberia uma mensagem de erro por falta de requisitos. Mesmo que esse requisito seja um arquivo fantasma.

          Basta usar a criatividade.

  • Wallacy

    Se não me engana esse vai ser o grande “diferencial” da versão 2.2, como os colegas acima frisaram, permitir que o “gerenciador de pacotes” (Market) atualize também o núcleo do SO.

    Como um bom SO Linux o Android já deveria ter feito isso desde o inicio, até porque já possui um repositório centralizado e comum a todas as versões (Market alô??).

  • http://www.csrenan.com Renan the Geek

    Acho que o problema é o Android ser muito novo no mercado, não podemos dizer que está “maduro”. Olha só, o Symbian é customizável e as operadoras tacam conteúdo próprio nele, mas não fica dando grandes paus de incompatibilidade de uma versão pra outra.

  • http://vitorgatti.sites.uol.com.br vitorgatti

    O Android deveria ser um só… ficamos na dependência de cada empresa em lançar as atualizações de Android para determinado celular ou não.

    É só olhar para o Samsung Galaxy i7500, por exemplo. A Samsung Brasil ignora as reclamações dos consumidores e deixa o Android na versão 1.5 com diversos bugs, como bateria que acaba em um dia sem muito uso e travadas nas ligações. Sou um “infeliz” proprietário desse celular e tive que me virar pra atualizar, no máximo, pra uma versão 1.6 customizada por um hacker, chamada de Galaxo. Ainda tive que fazer overclock no processador, porque o firmware da Samsung não deixa passar dos 256MHz, e com gambiarras, estou usando ele @710MHz (e não esquenta tanto).

    Ficar dependendo da Samsung, Motorola e Sony Ericsson pra atualizar o celular é um saco. Nisso a Apple ganha, já que iPhone é um só, então saiu uma atualização, saiu pra todos.

    O Multitouch do Android 2.1 é um diferencial muito grande, e todas essas empresas deveriam dar o máximo pra atualizar seus celulares para o Android 2.1 o mais rápido possível.

    O firmware do Android deveria ser lançado pela Google e deveria ser compatível com todos os celulares que utilizam Android no mercado, sem precisar ficar customizando.

    • Wallacy

      @vitorgatti,

      E provavelmente assim será daqui pra frente. Até as operadoras já não devem ter mais saco para ficar atualizando.

  • Manuel

    Se for só o problema dos programas das versões mais novas não funcionarem nas antigas, até dá pra aceitar. Mas se programas que funcionam em versões antigas não funcionarem mais novas ou paralelas, coisa que acontece bastante no Linux, aí vai ser uma porcaria.

  • antonioagpizolato

    Não sei! Acho que nessa guerra pelo mercado mobile, a democracia do Software aberto tende a deixar a plataforma heterogênea, morosa no seu desenvolvimento, uma ditadora com modela da Apple traz comando, direção e padronização; Você pode ver que um iPhone de primeira geração pode evoluir no software se mantendo atual isso não se vê isso nos outros concorrente, esse aparelhos recebem atualização sim mais raro o casa que seja na geração do software e sim de correções.

    Em relação ao desenvolvimento de Apps, o punho de ferro da dupla iPhone SDK e App Store pelo menos garante um ambiente com programas mais otimizados e com retro-compatibilidade, essa mesma muito bem cuidada, veja o cuidado da Apple em manter os Apps do iPHone funcionais no iPad fora agora opções de criar Apps Universais.

    Não sou contra os softwares livres, inclusive muitas empresas obtem tecnologia de pontas para seu produtos livres da ditadura dos licenças proprietárias, há Apple é um exemplo em seu OS e Aplicativos ela se vale do fetchmail, Bind, OpenGL, WebKit, Samba, CUPS e outros, quem é familiarizado com o Linux sabe que esse são programas fundamentais para se ter um distro funcional em Linux e outros OS como Solaris, BeOS, e outras variantes Unix.

    Temos que diferenciar que o kernel do linux, OpenGL, Samba, Cups,BIND e outros que são ofertas de tecnologia livre, diferente das distro de Linux e o Android são ofertas de soluções para clientes final na maioria usuários leigos, nesse campo o modelo OpenSoure por falta de integração entre si, gera essa desvantagem.

    • Wallacy

      @antonioagpizolato,

      Isso só funciona para uma só empresa e não para um consorcio.

      Até parece que a Motorola por exemplo ia ficar recebendo ordens da Apple. Dizendo o que ela deve ou não fazer no seu sistema.

      Ditadura dentro da empresa funciona, porém quando falamos de algo que abrange varias não.

      Veja que nesse caso, temos uma “despadronização padronizada”, você sai do geto onde cada operadora tem seu próprio sistema proprietário que não coversam um com os outros nem com reza brava. Para um onde todos são interoperaveis e conversam entre sí, salvo exceções.

      Estamos muito acostumados com monopólio por causa do domínio da Microsoft no Desktop, porém em outras areas ficar discutindo essa desfragmentação é pura perda de tempo, ela vai existir com ou sem software livre pelo simples fato de ser empresas diferentes que tomam decisões diferentes. Nesse contexto adotar um software proprietário não vai mudar nada.

      Você deu o exemplo do desenvolvimento de Apps para o iPhone, ok. Você desenvolve para uma serie de iPhones, porém só para eles. É perfeitamente análogo a desenvolver para Android 2.1 e todos os aparelhos com aquele requisito. A diferença que no ultimo caso, você está falando de milhares de dispositivos de varias empresas.

      Entendo sua critica, porém você está buscando algo que simplesmente não existe. Você deseja que todas as empresas façam exatamente a mesma coisa, usem o mesmo SO da mesma forma, etc. etc. Nesse caso você deixou de ter “varias empresas” e sim uma unica dominante, como é o caso do Desktop.

      O que se pode fazer é o que já está sendo feito, apesar de cada empresa obviamente poder fazer o que quiser com sua versão, é incentivar evitar mudanças estruturais muito grande, e criar uma forma de interoperar tais versões, além de criar um sistema “universal” de atualização.

      Veja que diferente do sistema Linux para desktop, o Android “resolve” esse problema pois possui um “gerenciador de pacotes” comum a todos, o Market. Logo é possível mitigar esses riscos.

      Pense que por exemplo a Apple resolva usar o Android, porém ela use sua “liberdade” para fazer centenas de modificações deixando ele extremamente otimizado para seu iPhone. Digamos que essas modificações sejam tão grandes que nenhum aplicativo feito para os outros Android seja compatível com o Android apple. Qual a grande diferença para a situação atual onde isso já não acontece? – O tratamento do problema.

      É muito mais “simples” fazer um software feito para um Android X rodar no Android Y, que o aplicativo feito para o iPhone rodar no Android, e vive versa. Pelo menos é o que pode analisar de forma genérica. Problemas de customização podem ser tratas pelo sistema de gerenciamento de pacotes, já problemas de arquitetura de software é outra estoria.

      Um bom exemplo, é que apesar da fragmentação de distros, posso instalar um programa feito para o Ubunto no meu OpenSUSE mesmo com pacotes totalmente diferentes um do outro. A diferença está no trabalho que vou ter e obviamente nas dependências a serem resolvidas, e nem é um trabalho tão grande assim, poderia ser automatizado por uma ferramenta no caso, como de fato já é feito por algumas.

      Agora tenta instalar um programa do Linux no Windows… O Abismo é muito maior.

      Parece um problema a fragmentação, e de fato é. Porém ela é só um efeito colateral para o tratamento de um outro problema muito maior.

  • http://www.shimatai.com.br Shimatai

    Esperem até chegarem os celulares chineses xing-ling com Android instalado. Essas estatísticas vão saltar.

  • lookez69

    Esse desde sempre foi o meu problema com o Android. Eu gostei do sistema, parece ser muito bom, e os celulares não parecem ser ruins (vide HTC 4G EVO).

    Porém o que muitos dizem ser o ponto fraco da Apple é justamente seu ponto forte. Eles tem controle completo da plataforma e podem satisfazer todos os usuários. É claro que em alguns updates nem todos os aparelhos ficam com todas as funções, mas isso (mesmo que propositalmente) é de se esperar. O importante é que todos podem rodar os mesmos apps e desfrutar das mesmas funções principais (como busca, game central etc), afinal o cara que comprou o iPhone em 2007 ainda ter updates está no lucro.

    A Google deixou a perna aberta e com as empresas tendo controle de como o software vai ser implementado o prejuízo é muito grande.

    Eu ia ficar muito P. da vida se comprasse um HTC 4G EVO e depois não pudesse instalar o 2.2 ou o 3.0 sei lá.