55 respostas a este tópico

[sismeiro]

0biwan escreveu:

eu sei que têm, mas lá esta mudas o CPU e cabum. a minha ideia era dar em qualquer CPU pois todos teriam o mesmo IS.o kernel devia também gerir resoluções, botões etc. como faz para um laptop. Tem que, mesmo assim, ter todas as possibilidades no kernel para dar em qualquer dispositivo.

Não querendo dizer que estas errado, fica aqui a informação que a "plataforma virtual" no Android para correr as aplicações já existe e chama-se Dalvik:http://pt.wikipedia.org/wiki/Dalvik_virtual_machine

Android RuntimeAndroid includes a set of core libraries that provides most of the functionality available in the core libraries of the Java programming language.Every Android application runs in its own process, with its owninstance of the Dalvik virtual machine. Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable (.dex) format which is optimized for minimal memory footprint. The VM is register-based, and runs classes compiled by a Java language compiler that have been transformed intothe .dex format by the included "dx" tool.The Dalvik VM relies on the Linux kernel for underlying functionality such as threading and low-level memory management.

Fonte: http://developer.and...ndroid.htmlAqui o problema situa-se e será sempre ao nível do suporte de HW e os respectivos drivers. Não há assim uma solução fácil uma vez que cada tipo de HW precisa obrigatoriamente de drivers especificos.

[0biwan]

essa plataforma virtual, pelo que percebi, é para correr as aplicações, não o SO.Lá está, o problema é o HW, se todo o HW fosse standard com as mesmas instruções todo ele seria suportado sem problemas. O suporte a botões também teria que estar la, tem botao nao mostra no ecra a opção, nao tem mostra. Eu não percebo grande coisa de kernels mas acho que é +- assim que funciona num pc

[FernandoMiguel]

anda aki uma grande confusao... a fragmentaçao q se fala n é de OS... é isso sim de APLICAÇOES q começam a ter dificuldade em suportar tds as plataformas.ha tb a fragmentaçao de mercado por haver tts modelos disponiveis para escolha mas isso e' outra questao

[FernandoMiguel]

0biwan escreveu:

Eu não percebo grande coisa de kernels mas acho que é +- assim que funciona num pc

tu nem imaginas a quantidade codigo especifico q anda no kernel para suportar hardware especifico. as vezes ate blocos GIGANTES so por causa de UM portatil de um fabricante

[0biwan]

e porque é que têm dificuldade em suportar?não é porque cada uma carece de instruções diferentes no codigo?

[FernandoMiguel]

a questao e' q os devs tem dificuldade em suportar tds estas ROMs (desde a 1.1 ate ao 2.0), diferentes personalizaçoes q os fabricantes e comunidade vao dando.

[sismeiro]

0biwan escreveu:

essa plataforma virtual, pelo que percebi, é para correr as aplicações, não o SO.Lá está, o problema é o HW, se todo o HW fosse standard com as mesmas instruções todo ele seria suportado sem problemas. O suporte a botões também teria que estar la, tem botao nao mostra no ecra a opção, nao tem mostra. Eu não percebo grande coisa de kernels mas acho que é +- assim que funciona num pc

O SO serve para isso mesmo, para interagir com o HW. Tem que existir sempre um layer para isso, seja o HW dito "standard" ou nao. E o HW ser "standard" vai diminuir em muito a capacidade de a plataforma Android ser usada em mais e mais dispositivos.Também não fiques a pensar que esse é o problema porque é mesmo o mais facil de resolver. HW X, driver X, nada de complicado. Nao são estes possiveis "problemas" que prejudicam as aplicações e causam a fragmentaçãoTal como o BUGabundo chamou a atenção, esta fragmentação que se fala está uns quantos layers acima na parte aplicacional e não tem relação nenhuma com o suporte de HW mas sim com os ambientes que estão a ser criados pelos vários fabricantes com as suas costumizações.Essas sim estão a criar problemas aos programadores porque alem de existir Android 1.5, 1.6 e 2.0, há depois as modificações feitas pelos fabricantes que torna ainda as coisas mais complicadas. Tens um artigo na pagina principal que fala disto e tambem a opiniao do Chris na pagina da Froogloid.

[0biwan]

ah então aí o problema já é outro (Se bem que o android tem problemas no que eu tava a falar a nivel de suporte de HW...)para isso so encontro 1 solução, os updates não serem feitos todos os dias, fazerem cm no iphone 1 ano de intervalo no mínimo. Eu gosto do modo de trabalho deles, não foi porque o iphone 1.0 nao tinha 3g ou MMS ou por nao gravar videoque lançaram um update a correr. As coisas foram feitas e quando apareceram estavam a funcionar bem.É melhor do que 1 release por dia com correcções de bugs (a nao ser obviamente para as equipas de desenvolvimento)quanto aos fabricantes, impor regras para as modificações de modo a nao alterar o suporte por parte de outras aplicações

[FernandoMiguel]

como é q impoes regras aos fabricantes?? o OS é Livre. qq um o pode usar... ( n confundir com a Google Experience)qt aos updates, n te eskeças q a plataforma é mt nova (tem dois anos) e tem evoluido mt bem, pq ha mt gente a trabalhar nela.n sou da opiniao q de deva limitar os ciclos de releases a periodos tao grandes qt um ano.ainda n percebi o teu prob com o HW. AFAIK n ha grandes probs.

[0biwan]

sismeiro escreveu:

0biwan escreveu:

essa plataforma virtual, pelo que percebi, é para correr as aplicações, não o SO.Lá está, o problema é o HW, se todo o HW fosse standard com as mesmas instruções todo ele seria suportado sem problemas. O suporte a botões também teria que estar la, tem botao nao mostra no ecra a opção, nao tem mostra. Eu não percebo grande coisa de kernels mas acho que é +- assim que funciona num pc

O SO serve para isso mesmo, para interagir com o HW. Tem que existir sempre um layer para isso, seja o HW dito "standard" ou nao. E o HW ser "standard" vai diminuir em muito a capacidade de a plataforma Android ser usada em mais e mais dispositivos.

a layer é o kernel. eu quando falo standard nao é quanto a velocidade de processador, modelo etc. falo em todos os processadores suportarem as mesmas instruções, isso nao causa limitações no uso da plataforma.problemas a nivel de controlos de luminosidade etc? cada fabricante faz a sua "drive" como no windows que em nada pode afectar as outras apps

[FernandoMiguel]

ate ao momento so ha uma arquitectura nos Androids (pode e vai certamente mudar em breve) os ARM v6/7 da qualcom

[0biwan]

há software livre com limitações de modificação... é nova mas esses updates continuos, quer queiras quer nao, acabam por te prejudicar a longo prazo. Daqui a um ano a htc deixa de fazer updates para o magic e passado 2 meses sai o android 3000 todo xpto e tu nao o tens. Se os updates fossem de ano a ano, pelo menos demorava 1 ano a ficares com o sW desactualizado.A standardização do Hw neste caso ja resolvia o problema, pois nao era preciso a HTC ou alguem lançar uma versao que o teu tlm suportasse, era so instalar o novo em qq dispositivo como fazes com uma distro qq de linux quando sai.provavelmente estou muito errado, mas acho que as coisas funcionavam melhor assim

[sismeiro]

0biwan escreveu:

ah então aí o problema já é outro (Se bem que o android tem problemas no que eu tava a falar a nivel de suporte de HW...)

Sinceramente desconheço os problemas que falas mas não digo que não existam. Tudo o que é software tem bugs, uns mais graves que outros e outros que não prejudicam em nada o correcto funcionamento.Se puderes indicar alguns dos problemas de suporte de HW ou a página onde se encontra essa informação, a malta agradece que assim podemos seguir esse problemas.

para isso so encontro 1 solução, os updates não serem feitos todos os dias, fazerem cm no iphone 1 ano de intervalo no mínimo.Eu gosto do modo de trabalho deles, não foi porque o iphone 1.0 nao tinha 3g ou MMS ou por nao gravar videoque lançaram um update a correr. As coisas foram feitas e quando apareceram estavam a funcionar bem.É melhor do que 1 release por dia com correcções de bugs (a nao ser obviamente para as equipas de desenvolvimento)

Os updates da Google têm sido feitos com vários meses de intervalo e isto também significa que há desenvolvimento.Quanto ao iPhone não ter 3G, suporte MMS e video foram escolhas da Apple. Os EUA o suporte 3G so recentemente começou a ser feito no operadores moveos e o MMS/video acho que foi por embirração que nao quiseram colocar. Pensavam que a malta começava a usar email para tudo em vez de MMS.A Apple também faz escolhas erradas e muitas, consegue é impor as suas escolhas aos seus seguidores fanaticos que fazem fila durante 8 dias para comprar um equipamento caro e sem algumas feature importantes. É assim que se vê o peso de uma marca.Também já tiveram por mais que uma vez lançar updates a correr porque introduziram bugs graves numa nova versão, por isso estarem 1 ano para lançar não faz com que as coisas saiam melhor.

quanto aos fabricantes, impor regras para as modificações de modo a nao alterar o suporte por parte de outras aplicações

Concordo ou como sugerido no artigo, kits de teste de compatibilidade que teriam de passar obrigatoriamente.Agora fazer o que estão a fazer aos programadores em termos de carga de programação e testes é que não. Organizem-se!

[FernandoMiguel]

0biwan escreveu:

há software livre com limitações de modificação...

n é mt livre pois n?

A standardização do Hw neste caso ja resolvia o problema, pois nao era preciso a HTC ou alguem lançar uma versao que o teu tlm

podes ter releases de um ano, e mm assim o fabricante n lançar updates! n é isso q faz diff

provavelmente estou muito errado, mas acho que as coisas funcionavam melhor assim

se leres no texto vais ver q kem entra para aliance assina um acordo para evitar a fragmentaçao... n ker dizer q tds se juntem ou a sigam .\

[0biwan]

sim a apple tem coisas mas, mas tambem tem coisas boas.quanto aos problemas de HW é o facto do ecra por exemplo, ou o processador ter que ser sempre o mesmo. (É aqui que eu volto a entrar com a conversa de os processadores de tlm começarem a ter todos as mesmas intruções, percebes?! as limitações eram menores e nao maiores como percebeste no meu outro post)Este é o grande problema do open source, mais cedo ou mais tarde iria atingir a plataforma android. Agora ou tudo se consegue resolver e ha entendimento ou dentro em breve vai haver androids todos quitados pela marca, que nunca vao sofrer updates, nem ter acesso a markets nem nada.E depois ha os google experience com o software base e com updates enquanto os fabricantes quiserem fornece-los.

[sismeiro]

0biwan escreveu:

a layer é o kernel. eu quando falo standard nao é quanto a velocidade de processador, modelo etc. falo em todos os processadores suportarem as mesmas instruções, isso nao causa limitações no uso da plataforma.

Isto não é o problema, essa questão das instruções não existe e muito menos no kernel de Linux que suporta nem sei dizer agora quantas arquitecturas. Alias, quem tem que "suportar" as instruções são os compiladores de código que traduzem o codigo fonte para instruções na linguagem da arquitectura do processador.

problemas a nivel de controlos de luminosidade etc? cada fabricante faz a sua "drive" como no windows que em nada pode afectar as outras apps

Uma vez que actualmente o HW é o mesmo para todos os terminais Android, este problema não existe. Os fabricantes não precisam neste momento de mexer nesses controlos, são iguais e o kernel já os suporta. Ao nivel das "instruções" este problema não se passa.

[FernandoMiguel]

aberto ou fexado n muda nada! mm qd 'e fexado os fabricantes fazem acordos e metem la o q kiserem... n tem 'e um mercado de devels tao extenso como este (qt apps ha pra WinMo?)qt ao ecra o OS/SDK minimiza isso: tens tres tamanhos: pekeno, normal , grande.

[0biwan]

o kernel de linux sim, o do android ja nao sei... (nao sei mesmo )BUGabundo: e existe alguma app para winMo que da num tlm e noutro nao? Eles poe la o que quiserem mas nao tiram compatibilidade, é aí que eu quero chegar

[sismeiro]

0biwan escreveu:

sim a apple tem coisas mas, mas tambem tem coisas boas.quanto aos problemas de HW é o facto do ecra por exemplo, ou o processador ter que ser sempre o mesmo. (É aqui que eu volto a entrar com a conversa de os processadores de tlm começarem a ter todos as mesmas intruções, percebes?! as limitações eram menores e nao maiores como percebeste no meu outro post)Este é o grande problema do open source, mais cedo ou mais tarde iria atingir a plataforma android. Agora ou tudo se consegue resolver e ha entendimento ou dentro em breve vai haver androids todos quitados pela marca, que nunca vao sofrer updates, nem ter acesso a markets nem nada.E depois ha os google experience com o software base e com updates enquanto os fabricantes quiserem fornece-los.

Respeito a tua opinião mas acho que estás enganado relativamente a alguns pontos. Essa parte da "normalização" de HW e de instruções não me faz mesmo sentido nenhum principalmemte quando usamos Linux nos Androids e que suporta N arquitecturas sem problemas.Isto que falas do problema do Open Source também não me faz sentido, o problema a existir é das pessoas que usam o Open Source. É preciso não confundir as coisas, a Internet é suportada por Open Source e usa protocolos bem definidos, cabe às pessoas usar esses protocolos para que tudo funcione. Em resumo, o problemas são as pessoas, não os conceitos de desenvolvimento de software como o Open Source.O mesmo se aplica ao que se está a passar e a fragmentação, se usarem as "normas" e não alterarem as coisas de forma a que as aplicações deixem de funcionar para meterem interfaces graficas, etc, não ha problema de fragmentação entre as varias implementacoes de Android, assim como nao ha entre as varias implementacoes de Linux, como Red Hat, Ubuntu, Mandriva, OpenSuse, etc. Têm todos é que ter um denominador comum, que são as APIs e protocolos.

[FernandoMiguel]

0biwan escreveu:

BUGabundo: e existe alguma app para winMo que da num tlm e noutro nao?

nunca tive winmo, nunca mexi em nenhum mais q alguns minutos e nunca instalei uma app num, por isso n te sei responder.ha por aki varios former users deixo com eles respondam

[0biwan]

quais N arquitecturas? duvido que suporte todas as que existem para processadores de tlm (nao sao as mesmas de pc). Mas aqui falo sem conhecimento de causa, mas como disse, duvido :)A internet é suportada por open source mas, como dizes, com modelos bem definidos e standardizados, se aparecesse ai alguem com novos protocolos achas que alguem os ia usar? nao. daí ninguem mexe. Olha o IPV6 achas que algum dia se vai massificar? segundo varios professores meus, nunca. Dá trabalho a mais e despesa a mais.comunicações é diferente de sistemas operativos.exacto, essas normas eram bem-vindas. como dizes nas distros de linux tudo funciona em todas elas, podes é ter que instalar pacotes extra se mudar o ambiente grafico (gnome, kde, etc)

[sismeiro]

0biwan escreveu:

quais N arquitecturas? duvido que suporte todas as que existem para processadores de tlm (nao sao as mesmas de pc). Mas aqui falo sem conhecimento de causa, mas como disse, duvido

Não vou continuar a conversa, fica só aqui a informação sobre as N arquitecturas suportadas pelo Linux. É fácil perceber quantas são em dispositivos móveis:http://en.wikipedia.org/wiki/List_of_Linux_supported_architectures

[FernandoMiguel]

a tree Linus ( a vertente uptream ) tem todo o suporte necessario para estes processadores.em NADA é acrescentado pelos developers da OpenAliance ao kernel.e se houvesse tinham td o interesse em submete-las uptream.o q se passa por vezes sao personalizaçoes locais, ou optimizaçoes, como foi o caso do BFS, mas mm este foi desenvolvido por um guru do kernel

[FernandoMiguel]

sismeiro escreveu:

fica só aqui a informação sobre as N arquitecturas suportadas pelo Linux. É fácil perceber quantas são em dispositivos móveis:http://en.wikipedia.org/wiki/List_of_Linux_supported_architectures

curioso, n encontro ai os ARM da qualcom :Dmas sei q sao pq ate debian tem repos para esta arquitectura, e ha kem corra Debian nos devices android

[0biwan]

sismeiro escreveu:

0biwan escreveu:

quais N arquitecturas? duvido que suporte todas as que existem para processadores de tlm (nao sao as mesmas de pc). Mas aqui falo sem conhecimento de causa, mas como disse, duvido

Não vou continuar a conversa, fica só aqui a informação sobre as N arquitecturas suportadas pelo Linux. É fácil perceber quantas são em dispositivos móveis:http://en.wikipedia.org/wiki/List_of_Linux_supported_architectures

desconhecia tanto suporte para processadores móveis :)qq dia ponho o ubuntu no meu SE