BRPI0616218A2 - tÉcnicas para gerenciar aplicativos em um dispositivo de comunicaÇço portÁtil - Google Patents

Abstract

TÉCNICAS PARA GERENCIAR APLICATIVOS EM UM DISPOSITIVO DE COMUNICAÇçO PORTÁTIL. Um mecanismo de arbitragem gerencia aplicativos em um dispositivo de comunicação portátil identificando uma imagem DSP abrangente que inclua todos os módulos necessários para rodar um novo aplicativo assim como os aplicativos atualmente ativos, O mecanismo de arbitragem inclui também uni detector de conflitos que determina se a execução simultânea do novo aplicativo com os aplicativos atualmente ativos resulta em um conflito de regras ou um conflito de hardware. Se nenhuma imagem DSP for identificada ou se existir um conflito, um avaliador de prioridades no mecanismo de arbitragem avalia a prioridade do novo aplicativo com relação à prioridade máxima dos aplicativos atualmente ativos. Se a prioridade for maior ou igual à prioridade máxima dos aplicativos atualmente ativos, o novo aplicativo é rodado.

Description

"TÉCNICAS PARA GERENCIAR APLICATIVOS EM XJM DISPOSITIVO DECOMUNICAÇÃO PORTÁTIL"

FUNDAMENTOS

A invenção refere-se em geral a dispositivos decomunicação portáteis e, mais especificamente, a técnicaspara gerenciar aplicativos em um dispositivo de comunicaçãoportátil.

Dispositivos de comunicação portáteis tais comotelefones celulares e assistentes digitais pessoais(PDAs) estão proporcionando cada vez mais funções eserviços. Além de proporcionar funções de comunicação devoz, muitos dispositivos de comunicação portáteis rodamoutros aplicativos tais como jogos, exibição e gravaçãode video, exibição e captura de fotografias digitais,execução de som e música e aplicativos de gravação desom. Os dispositivos de comunicação portáteisconvencionais incluem processadores de sinais digitais(DSPs) que rodam módulos que facilitam a operação dosdiferentes aplicativos. Os módulos são seções de códigode firmware que executam uma tarefa ou cálculoespecifico. Entretanto, os dispositivos de comunicaçãoportáteis são limitados, entretanto, no sentido de que osmódulos necessários para todos os aplicativos suportadospodem não ser carregados no DSP por causa do tamanhoagregado dos módulos. Além disto, a potência deprocessamento de um mecanismo de DSP não é suficientepara rodar simultaneamente todos os módulos.

Adicionalmente, não existe nenhum mecanismo parasuspender aplicativos de modo a carregar módulos no DSPpara dar suporte a outros aplicativos.

Por conseguinte, há necessidade de técnicas paragerenciar aplicativos em um dispositivo de comunicaçãoportátil.BREVE DESCRIÇÃO DOS DESENHOS

A Figura 1 é um diagrama de blocos de umdispositivo de comunicação portátil.

A Figura 2 é um diagrama de blocos de ummecanismo de arbitragem.

A Figura 3 é um fluxograma de um método paraefetuar detecção de conflito.

A Figura 4 é um diagrama de blocos da relaçãoentre módulos de DSP e imagens DSP.

A Figura 5 é um fluxograma de um método paraidentificar uma imagem DSP abrangente.

DESCRIÇÃO DETALHADA DAS MODALIDADES PREFERIDAS

A presente revelação refere-se a técnicas paragerenciar aplicativos em um dispositivo de comunicaçãoportátil pela identificação de uma imagem DSP que incluitodos os módulos necessários para rodar simultaneamenteaplicativos ativos e aqueles necessários para rodar um novoaplicativo. Em uma modalidade, um detector de conflitosconfirma que não existe conflito de hardware ou conflito "deregras antes que um qualificador de DSP identifique umaimagem DSP abrangente a partir de um conjunto de imagensDSP. A imagem DSP abrangente inclui um conjunto de módulosrequeridos pelos aplicativos atualmente ativos assim comomódulos requeridos pelo novo aplicativo. Se nenhuma imagemDSP abrangente puder ser identificada ou se um conflito fordetectado, uma avaliação de prioridade é efetuada de modo adeterminar se alguns aplicativos devem ser suspensos ou seo novo aplicativo deve ser rejeitado.

A Figura 1 é um diagrama de blocos do dispositivode comunicação portátil 100 de acordo com uma modalidade. Odispositivo de comunicação portátil 100 é qualquerdispositivo, tal como um telefone celular ou um assistentedigital pessoal (PDA), que proporcione serviços decomunicação assim como rodar um ou mais outros aplicativos.0 dispositivo de comunicação portátil 100 inclui pelo menosum processador principal 102, um processador de sinaisdigitais (DSP) 104, uma memória 108 e um hardware 106.

0 processador principal 102 pode ser qualquercontrolador, processador, micro-processador ou disposiçãode processadores que execute código dos diversosaplicativos, o software e protocolos de comunicação quefacilitam a funcionalidade total do dispositivo decomunicação portátil 100. 0 processador principal 102 podecompreender capacidade de processamento dispersa entre umou mais circuitos integrados aplicação especifica (ASICs)ou outro hardware capaz de processar software decomputador. Um exemplo de ASIC adequado para comunicaçõessem fio é um chip de Modem de Estação Móvel (MSM) queincorpora o processador 102 e outra funcionalidade deAcesso Múltiplo por Divisão de Código (CDMA). 0 MSM éresponsável pela modulação e demodulação de sinais CDMA demodo a manter um link de comunicação com a rede celular.

0 DSP 104 é um processador de alta velocidade queefetua tarefas computacionalmente intensivas ou sensíveis àvelocidade. O DSP 104 e o processador principal 102 podemser implementados dentro do mesmo ASIC. Além disto, outrostipos de processador, microprocessadores, FPGAs e circuitosintegrados podem ser utilizados em algumas circunstânciaspara efetuar as funções aqui descritas sem que hajaafastamento do alcance da invenção. Durante operação dodispositivo de comunicação portátil 100, os aplicativos querodam no processador principal invocam processos no DSP104. Por exemplo, um aplicativo tocador de música que rodano processador principal 102 pode chamar um módulo de MP3no DSP 104 para efetuar decodificação de MP3.O dispositivo de comunicação portátil 100 incluium hardware 106, como dispositivos de entrada e saida.Exemplos de hardware 106 incluem alto-falantes, microfones,teclados, monitores, botões, LEDs e sensores de câmera. Ohardware 106 inclui dispositivos ou componentes individuaispara efetuar funções especificas. Um componente de hardware106 pode incluir múltiplos componentes discretos e podeincluir portas lógicas ou dispositivos processadores emalgumas circunstâncias.

A memória 108 inclui qualquer combinação dedispositivos de memória não volátil e RAM que proporcionemarmazenamento de dados e código. Módulos de DSP sãoarmazenados na memória e carregados no DSP 104 parafacilitar a execução dos processos que rodam no DSP 104.Todos os módulos necessários para todos os aplicativospodem não ser passíveis de carregamento simultâneo no DSP104. Por conseguinte, os módulos são dispostos dentro dasimagens DSP. Uma imagem DSP compreende um conjunto !demódulos, em que cada módulo inclui um firmware, ou outrocódigo executável, para operar o hardware ou efetuar umafunção especifica para um aplicativo que roda noprocessador principal. Por exemplo, uma imagem DSP podeconter um módulo para efetuar codificação/decodificação devoz para processamento de chamadas de voz, um módulo páraefetuar codificação JPEG para tirar fotografias e um módulopara gerar tons para a ativação do teclado. Um aplicativode chamada de voz e um aplicativo de câmera podem rodarsimultaneamente com esta imagem DSP e o usuário podeutilizar o dispositivo de comunicação portátil para tirarfotografias enquanto participa de uma chamada de voz.

Durante a operação do dispositivo de comunicaçãoportátil 100, um ou mais aplicativos ativos efetuam funçõesutilizando os módulos da imagem DSP carregada no DSP. Porconseguinte, um aplicativo ativo é um aplicativo que rodano processador principal que é suportado pelos móduloscarregados no DSP 104. Quando uma solicitação para novoaplicativo é feita, são avaliados critérios para sedeterminar a ação apropriada. Conforme discutido aqui,portanto, um novo aplicativo é um aplicativo que não estárodando atualmente no processador principal e pode não sersuportado pela imagem DSP atualmente carregada.

Conforme discutido a seguir com referência àmodalidade exemplar, um mecanismo de arbitragem que roda noprocessador principal 102 gerencia as imagens DSP que sãocarregadas no DSP 104. Um qualificador de imagens DSP nomecanismo de arbitragem identifica uma imagem DSPabrangente que inclui os módulos necessários aosaplicativos atualmente ativos assim como os necessários aum novo aplicativo. O avaliador de prioridades 2.06determina se o novo aplicativo deve ser carregado no casode existir um conflito de hardware ou conflito de regras ouno caso de nenhuma imagem DSP abrangente puder seridentificada.

A Figura 2 é um diagrama de blocos de ummecanismo de arbitragem 200 de acordo com a modalidadeexemplar da invenção. Na modalidade exemplar, o mecanismode arbitragem 200 compreende código executável que roda noprocessador principal 102 no dispositivo de comunicaçãoportátil 100. Os blocos funcionais descritos com referênciaà Figura 2, contudo, podem ser implementados utilizando-sequalquer combinação de hardware, software e/ou firmware.Além disto, as funções e operações dos blocos descritos naFigura 2 podem ser implementadas em qualquer número dedispositivos, circuitos ou infra-estrutura. Dois ou maisdos blocos funcionais podem ser integrados a um únicodispositivo e as funções descritas como efetuadas emqualquer dispositivo único podem ser implementadas atravésde vários dispositivos, códigos de software ou aplicativosde software.

0 mecanismo de arbitragem 200 compreende umdetector de conflitos 202, um qualificador de imagens deprocessador de sinais digitais (DSP) 204 e um avaliador deprioridades de aplicativo 206 na modalidade exemplar. 0detector de conflitos 202 aplica restrições de hardware 208e regras operacionais de aplicativo 210 que correspondem aonovo aplicativo e aos aplicativos atualmente ativos de modoa determinar se existe um conflito de hardware ou umconflito de regras na execução simultânea do novoaplicativo (Ax) com os aplicativos atualmente ativos (Ai).Na Figura 2, Ax representa um identificador do novoaplicativo e Ai representa um identificador dos aplicativosatualmente ativos, onde i=laNeNéo número deaplicativos atualmente ativos. Depois de receber umasolicitação para avaliar o novo aplicativo (Ax) , o detectorde conflitos 202 recupera, a partir da memória 108, osrequisitos de hardware 210 para o novo aplicativo e osaplicativos atualmente ativos e recupera da memória 108 asregras de funcionamento de aplicativo 212 relacionadas como novo aplicativo. O detector de conflitos 202 determina seos requisitos de hardware 208 para o novo aplicativo e osaplicativos atualmente ativos podem ser satisfeitos. Porexemplo, se o novo aplicativo assim como um dos aplicativosatualmente ativos exigirem um alto-falante parafuncionamento, o detector de conflitos 202 determina queexiste um conflito de hardware.

A execução simultânea de uma combinação deaplicativos pode ser proibida pelas regras de aplicativo210. As regras de aplicativo 210 ditam quais aplicativosnão podem rodar simultaneamente mesmo se os recursos dehardware 106 estiverem disponíveis. Um exemplo de regra deaplicativo 210 inclui a restrição ao rodar um aplicativogravador de som durante uma chamada de voz. Embora hardwarepossa suportar o funcionamento simultâneo de ambos osaplicativos, a regra de aplicativo restringe a execuçãosimultânea dos aplicativos devido a requisitos legais. Demodo a se evitar a gravação não autorizada de uma chamadade voz, a regra de aplicativo 210 proíbe a operaçãosimultânea do aplicativo gravador de som e o aplicativo decomunicação de voz.

Se não existe conflito de regras ou conflito dehardware ao rodar o novo aplicativo com os aplicativosatualmente ativos, o qualificador de imagens DSP 204identifica uma imagem DSP abrangente que suporte a execuçãodo novo aplicativo e dos aplicativos atualmente ativos. Seum conflito for detectado ou se o qualificador de imagensDSP não puder identificar uma imagem DSP abrangente, oavaliador de prioridades 206 determina, com base em níveisde prioridade, se aplicativos atualmente ativos devem sersuspensos ou interrompidos de modo a se rodar o novoaplicativo.

Uma imagem DSP compreende um conjunto de módulos,onde cada módulo inclui código executável para operarhardware ou efetuar uma função específica para umaplicativo. Por exemplo, uma imagem DSP pode compreender ummódulo para codificar/decodificar voz e um módulo paraencontrar visão de câmera e um modo para gerar tons deaperto de teclas. Com esta imagem DSP carregada, o usuáriopode utilizar o recurso de encontrar visão de câmeradurante uma chamada de voz. Conforme descrito em detalhesadicionais a seguir, o qualificador de imagens DSPidentifica a imagem DSP abrangente, que inclui pelo menosos módulos necessários para os aplicativos atualmenteativos e os módulos necessários para o novo aplicativo. Oconjunto de módulos necessários é comparado com os móduloscontidos em cada imagem DSP. A imagem DSP que contém todosos módulos necessários é identificada como a imagem DSPabrangente e é carregada no DSP 104.

Se nenhuma imagem DSP abrangente for identificadaou se existir um conflito, o avaliador de prioridades 206aval ia as prioridades do novo aplicativo e dos aplicativosatualmente ativos e determina se o novo aplicativo deve serrodado. Na modalidade exemplar, o avaliador de prioridades206 determina se o novo aplicativo tem uma prioridade maiordo que a prioridade máxima dos aplicativos atualmenteativos. 0 nivel de prioridade associado ao novo aplicativo(prioridade de novo aplicativo) é comparado com o nivel 'deprioridade máximo de todos os aplicativos atualmenteativos, Na modalidade exemplar, se o novo aplicativo tiveruma prioridade maior que a ou igual à prioridade maior dosaplicativos ativos, um ou mais dos aplicativos atualmenteativos são suspensos e o novo aplicativo é invocado eautorizado para rodar. Outros critérios podem serutilizados para avaliar as prioridades em algumascircunstâncias. Na modalidade exemplar, todos osaplicativos atualmente ativos são suspensos -ouinterrompidos e os recursos são atribuídos ao novoaplicativo. Uma imagem DSP que tenha os módulos necessáriospara suportar o novo aplicativo é carregada e o novoaplicativo é executado. Se a prioridade máxima dosaplicativos atualmente ativos for maior que a prioridade 'donovo aplicativo, o novo aplicativo é rejeitado. Em algumassituações, pode ser iniciado um procedimento que analisa aprioridade dos aplicativos assim como as imagens DSP demodo a identificar um ou mais aplicativos de DSP que têmuma prioridade mais baixa e devem ser suspensos parapermitir rodar o novo aplicativo. Em tais situações, nemtodos os aplicativos atualmente ativos são suspensos.

A Figura 3 é um fluxograma de um método paraefetuar detecção de conflitos de acordo com a modalidadeexemplar da invenção. O método pode ser efetuado porqualquer combinação de hardware, software e/ou firmware. Namodalidade exemplar, o método é efetuado pela execução decódigo no processador principal 102.

Na etapa 302, i é fixado como igual a 1.Na etapa 304, é determinado se existe conflito deregras. Na modalidade exemplar, cada par de aplicativos quecontêm o novo aplicativo, Ax, e cada aplicativo atualmenteativo, Ai, é comparado com uma lista de pares deaplicativos proibidos. A lista de pares de aplicativosproibidos inclui todos os pares de aplicativos que sãoproibidos de rodar simultaneamente por uma ou mais regras.Por conseguinte, os conflitos de regras são refletidosdentro da lista de pares de aplicativos proibidos namodalidade exemplar. Outras técnicas são utilizadas emalgumas circunstâncias para aplicar as regras de modo a sedeterminar se existe um conflito de regras ao rodar osnovos aplicativos com os aplicativos atualmente ativos. =Seo par de aplicativos (Ai, Ax) for encontrado na lista, oconflito de regras é identificado na etapa 306.

Na etapa 308, é determinado se os recursos dehardware 106 exigidos pelos aplicativos atualmente ativosse sobrepõem aos recursos de hardware exigidos pelo novoaplicativo. Por conseguinte, o conjunto de recursos dehardware para o aplicativo atualmente ativo, Ai, écomparado com o conjunto de recursos de hardware exigidospelo novo aplicativo Ax para cada i de 1 a N. Se ainterseção dos conjuntos for zero (isto é, o conjuntonulo), não existe conflito de hardware e o procedimentocontinua na etapa 312. Se a interseção não for o conjuntonulo, um conflito de hardware é identificado na etapa 310.

Um Ioop formado pelas etapas 304, 308, 312 e 314incrementa i de 1 a N até que todos os aplicativos atuaistenham sido analisados, até que um conflito de regras sejadetectado ou até que um conflito de hardware sejaencontrado. Na etapa 312, é determinado se todos osaplicativos atualmente ativos (Ai, i=l a N) foramanalisados. Se i for igual a N, todos os requisitos dehardware de todos os aplicativos atualmente ativos foramcomparados com os requisitos de hardware do novoaplicativo, todos os pares Ax, Ai foram comparados com alista de pares de aplicativos proibidos e o procedimentocontinua na etapa 316. Caso contrário, i é incrementado 'emIeo procedimento volta à etapa 304.

Na etapa 316, é determinado que não existeconflito de regras ou conflito de hardware na execuçãosimultânea do novo aplicativo com os aplicativos atualmenteativos. O qualificador de imagens DSP 204 do mecanismo dearbitragem 200 tenta então identificar a imagem DSPabrangente.

A Figura 4 é um diagrama de blocos da relação 400entre módulos 402 e imagens DSP 404 de acordo com amodalidade exemplar da invenção. Os módulos de DSP 402incluem qualquer número (Y) de módulos e as imagens incluemqualquer número (Z) de imagens DSP 404. As setas na Figura4 identificam imagens DSP 404 e módulos de DSP 402 afins.Uma seta entre um modulo e uma imagem indica que o móduloestá dentro dessa imagem. No exemplo mostrado na Figura 4,por conseguinte, a imagem 1, a imagem 2 e a imagem 5incluem, cada uma, o módulo 2. Uma imagem DSP 404 podeincluir qualquer número de módulos e um módulo pode serincluido em qualquer número de imagens. Conforme discutidomais detalhadamente a seguir, uma técnica eficaz paraidentificar uma imagem DSP abrangente inclui identificarimagens que contêm um módulo que é incluído com menosfreqüência em imagens antes de se determinar se outrosmódulos necessários estão contidos na imagem. Em outraspalavras, um módulo incluído freqüentemente forneceinformações sobre se uma imagem DSP satisfará os requisitosda imagem DSP abrangente.

A Figura 5 é um fluxograma de um método paraidentificar uma imagem DSP abrangente de acordo com asmodalidades exemplares da invenção. 0 método pode serefetuado por qualquer combinação de hardware, software e/oufirmware. Na modalidade exemplar, o método é efetuado pelaexecução de um código no processador principal 102. Ométodo descrito com referência à Figura 5 apresenta,portanto, uma implementação exemplar , do qualificador deimagens DSP 204.

Na etapa 502, um módulo (Mj) dentro da imagem DSPatualmente carregada é identificado como um módulo de20 busca. Embora uma variedade critérios e técnicas possam serutilizadas para identificar o módulo de busca (Mj), Mj éselecionado com base na freqüência de inclusão dentro deimagens DSP na modalidade exemplar. Na modalidade exemplar,um subconjunto S dos módulos atualmente utilizados {Mi, M2...Md} é formado utilizando-se {Μχ, M2 . . .MD} - {Mi, Mp...Mq}, onde {Mi, Mp, . . .Mq} é um conjunto dos módulosutilizados mais freqüentemente. O módulo Mj é escolhidoaleatoriamente do conjunto S. Em algumas circunstâncias, Mjpode ser selecionado aleatoriamente a partir do conjunto demódulos atualmente carregados.

Na etapa 504, um conjunto de imagens DSP queinclui Mj é identificado {CONJUNTOi= {I1, i2, í3 ...ix}).Portanto, o módulo Mj é identificado na lista de módulos402 e as imagens correspondentes ao módulo são agrupadas noCONJUNTOi.

Na etapa 506, um contador é fixado em 1.

Na etapa 508, um conjunto de união de módulos quecontém os módulos do novo aplicativo e os módulos dosaplicativos atualmente ativos é identificado (Um = {Ma,Mb...MK} U {Mi, M2...Md}, onde K é o número de módulos donovo aplicativo e D é o número de módulos dos aplicativosatualmente ativos). Portanto, Um inclui todos os módulosnecessários para o novo aplicativo e todos os módulosnecessários para os aplicativos atualmente ativos.

Na etapa 510, é determinado se a imagem DSPinclui o conjunto de união dos módulos, Um. Se a imagem DSPnão inclui pelo menos os módulos necessários para o novoaplicativo e os módulos necessários para o aplicativoatualmente ativo, o procedimento continua na etapa 514. "Sea imagem DSP inclui pelo menos os módulos necessários pa:rao novo aplicativo e os módulos necessários para oaplicativo atualmente ativo, o procedimento continua naetapa 512, onde a imagem DSP atualmente analisada (ic) : équalificada como a imagem DSP abrangente. Portanto, se icinclui Um, ic é qualificada como a imagem DSP abrangente. Aimagem DSP abrangente é carregada no' DSP executado parasuportar o novo aplicativo e os aplicativos atualmenteativos.

Um Ioop formado pelas etapas 510, 514 e 516incrementa C de 1 para X até que todas as imagens DSP noCONJUNTOi tenham sido analisadas ou até que uma imagem DSPabrangente seja identificada. Na etapa 514, é determinadose todas as imagens DSP no CONJUNTOi foram analisadas. Se Cfor igual a X, todas as imagens DSP no CONJUNTOi foramanalisadas e o procedimento continua na etapa 518. Casocontrário, C é incrementado em 1 e o procedimento volta àetapa 510. Por conseguinte, o conjunto de imagens DSP éavaliado para identificar a imagem DSP abrangente.

Na etapa 518, é determinado que nenhuma imagemDSP abrangente está disponível. O avaliador de prioridades202 é chamado para determinar se os aplicativos atualmenteativos devem ser suspensos ou interrompidos de modo a serodar o novo aplicativo.

Na modalidade exemplar, portanto, o mecanismo dearbitragem 200 determina se há conflitos de hardware ou deregras na execução simultânea do novo aplicativo e dosaplicat ivos atualmente ativos. Se não for identificadonenhum conflito, o qualificador de imagens DSP 204 nomecanismo de arbitragem 200 tenta identificar uma imagemDSP abrangente que inclua todos os módulos necessários pararodar o novo aplicativo e o aplicativo atualmente ativo. Senenhuma imagem DSP abrangente for identificada ou se umconflito for detectado, o avaliador de prioridades 206determina se o novo aplicativo deve ser rejeitado ou sedeve ser rodado com base nas prioridades do novo aplicativoe dos aplicativos atualmente ativos.

Evidentemente, outras modalidades e modificaçõesdesta invenção ocorrerão prontamente aos versados 'natécnica em vista destes ensinamentos. A descrição acima éilustrativa e não exemplificativa. Esta invenção deve serlimitada apenas pelas reivindicações seguintes, que incluemtodas as modalidades e modificações que tais, quando vistasem conjunto com o relatório acima e os desenhos anexos. Oalcance da invenção deve ser determinado, portanto, não comreferência à descrição acima, mas, em vez disso, deve serdeterminado com referência aos desenhos anexos juntamentecom seu escopo total de equivalentes.

Claims (21)

1. Método compreendendo:receber uma solicitação, de um novo aplicativo emum dispositivo de comunicação portátil; eidentificar, a partir de uma pluralidade deimagens de processador de sinais digitais (DSP), uma imagemDSP abrangente compreendendo todos módulos necessários parasuportar o novo aplicativo e todos aplicativos atualmenteativos.

2. Método, de acordo com a reivindicação 1, emque identificar compreende:identificar um módulo de busca a partir de umconjunto de módulos atualmente carregados;identificar, a partir da pluralidade de imagensDSP, um conjunto de imagens DSP contendo o módulo de busca;eavaliar o conjunto de imagens DSP paraidentificar a imagem DSP abrangente.

3. Método, de acordo com a reivindicação 2,compreendendo adicionalmente:carregar a imagem DSP abrangente no DSP.

4. Método, de acordo com a reivindicação 2,compreendendo adicionalmente:avaliar, se nenhuma imagem DSP abrangente foridentificada, uma nova prioridade de aplicativo do novoaplicativo com relação a prioridade atual dos aplicativòsatualmente ativos para determinar se o novo aplicativo deveser invocado.

5. Método, de acordo com a reivindicação 4, emque avaliar compreende:invocar o novo aplicativo se a nova prioridade deaplicativo for maior ou igual a uma prioridade máxima doaplicativo atualmente ativo.

6. Método, de acordo com a reivindicação 5,compreendendo adicionalmente:suspender todos aplicativos atualmente ativos sea nova prioridade de aplicativo for maior ou igual a umaprioridade máxima do aplicativo atualmente ativo.

7. Método, de acordo com a reivindicação 5,compreendendo adicionalmente:carregar, no DSP, uma imagem DSP adequada parasuportar o novo aplicativo.

8. Método, de acordo com a reivindicação 1,compreendendo adicionalmente:determinar que não existe conflito de regras paraexecutar simultaneamente o novo aplicativo com aplicativosatualmente ativos; edeterminar que não existe conflito de hardwarepara executar simultaneamente o novo aplicativo e osaplicativos atualmente ativos.

9. Método para gerenciar aplicativos em umdispositivo de comunicação portátil, o métodocompreendendo:determinar se existe um conflito de regras aoexecutar simultaneamente um novo aplicativo e aplicativosativos;determinar se existe um conflito de hardware aoexecutar simultaneamente o novo aplicativo e os aplicativosativos;se não existir conflito de regras e não existirconflito de hardware, avaliar uma pluralidade de imagensDSP para identificar uma imagem DSP abrangentecompreendendo módulos suportando execução simultânea donovo aplicativo e dos aplicativos atualmente ativos; ese uma imagem DSP abrangente for identificada,carregar a imagem DSP abrangente no DSP.

10. Método, de acordo com a reivindicação 9,compreendendo adicionalmente:avaliar, se nenhuma imagem DSP abrangente foridentificada, uma nova prioridade de aplicativo do novoaplicativo com relação a uma prioridade atual dosaplicativos atualmente ativos para determinar se o novoaplicativo deve ser invocado.

11. Método, de acordo com a reivindicação 10, emque avaliar compreende:invocar o novo aplicativo se a nova prioridade ideaplicativo for maior ou igual a uma prioridade máxima doaplicativo atualmente ativo.

12. Método, de acordo com a reivindicação 11,compreendendo adicionalmente:suspender todos aplicativos atualmente ativos sea nova prioridade de aplicativo for maior ou igual a umaprioridade máxima do aplicativo atualmente ativo.

13. Método, de acordo com a reivindicação 11,compreendendo adicionalmente:carregar, no DSP, uma imagem DSP adequada parasuportar o novo aplicativo.

14. Mecanismo de arbitragem para gerencikraplicat ivos rodando em um processador principal em umdispositivo de comunicação portátil, o mecanismo dearbitragem compreendendo:um qualificador de imagens de processador ciesinais digitais (DSP) configurado para identificar, ; apartir de uma pluralidade de imagens DSP, uma imagem DSPabrangente compreendendo módulos de aplicativo necessáriospara suportar um novo aplicativo e todos aplicativosatualmente ativos.

15. Mecanismo de arbitragem, de acordo com areivindicação 14, em que o qualificador de imagens DSP. éadicionalmente configurado para:identificar um módulo de busca a partir de umconjunto de módulos atualmente carregados;identificar, a partir da pluralidade de imagensDSP, um conjunto de imagens DSP contendo o módulo de busca;eavaliar o conjunto de imagens DSP paraidentificar a imagem DSP abrangente.

16. Mecanismo de arbitragem, de acordo com areivindicação 15, compreendendo adicionalmente:um avaliador de prioridades configurado paraavaliar, se nenhuma imagem DSP for identificada, uma novaprioridade de aplicativo do novo aplicativo com relação auma prioridade atual dos aplicativo deve ser invocadodeterminar se o novo aplicativo deve ser invocado.

17. Mecanismo de arbitragem, de acordo com ' areivindicação 16, em que o avaliador de prioridades éadicionalmente configurado para:determinar que o novo aplicativo deve rodar se anova prioridade de aplicativo for maior ou igual a umaprioridade máxima do aplicativo atualmente ativo.

18. Mecanismo de arbitragem, de acordo com areivindicação 14, compreendendo adicionalmente:um detector de conflitos configurado paraidentificar um conflito ao rodar simultaneamente o novoaplicativo e os aplicativos atualmente ativos.

19. Mecanismo de arbitragem, de acordo com areivindicação 18, em que o conflito é um conflito dehardware.

20. Mecanismo de arbitragem, de acordo com areivindicação 18, em que o conflito é um conflito deregras.

21. Mecanismo de arbitragem para gerenciaraplicativos rodando em um processador principal em umdispositivo de comunicação portátil, o mecanismo dearbitragem compreendendo:um detector de conflitos configurado paraidentificar um conflito ao rodar simultaneamente o novoaplicativo e os aplicativos atualmente ativos;um qualificador de imagens de processador desinais digitais (DSP) configurado para identificar, apartir de uma pluralidade de imagens DSP, uma imagem DSPabrangente compreendendo módulos de aplicativo necessáriospara suportar um novo aplicativo e todos aplicativosatualmente ativos; eum avaliador de prioridades configurado paraavaliar, se nenhuma imagem DSP abrangente for identificadaou se um conflito for detectado, uma nova prioridade deaplicativo do novo aplicativo com relação a uma prioridadeatual dos aplicat ivos atualmente ativos para determinar seo novo aplicativo deve ser invocado.