Firefox OS - Relatório sobre o sistema operacional Firefox OS padrão TCC.

Prévia do material em texto

UNIVERSIDADE FEDERAL DO ACRE 
CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS 
CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO 
 
 
 
 
 
 
 
 
 
 
SISTEMA OPERACIONAL FIREFOX OS 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
RIO BRANCO 
MAIO DE 2016
 
 
Alberto Ottaviano Flangini Neto 
Augustinho Rodrigues Ferreira 
Cláudio Angelim Hall 
Lucas da Silva Cruz 
Robledo Gomes Bezerra Filho 
Thalita Raquel Maia da Silva 
 
 
 
 
 
 
SISTEMA OPERACIONAL FIREFOX OS 
 
 
 
 
 
 
 
Relatório de pesquisa apresentado como 
exigência parcial para aprovação na 
disciplina Sistemas Operacionais do 
Curso de Bacharelado em Sistemas de 
Informação do Centro de Ciências Exatas 
e Tecnológicas da Universidade Federal 
do Acre. 
 
Professor: Macilon Araújo Costa Neto 
 
 
 
 
 
 
RIO BRANCO 
MAIO DE 2016
 
 
RESUMO 
O Firefox OS foi um sistema operacional desenvolvido pela Mozilla para 
smartphones de baixo custo. Foi desenvolvido inteiramente utilizando-se de 
tecnologias Web como HTML5, CSS e JavaScript. Sua principal finalidade era ser 
utilizado em smartphones de baixo custo, com hardware básico, atingindo os 
consumidores que preferem simplicidade, segurança e eficiência, mas que não 
querem ou possuem como pagar por isso. O trabalho aborda conceitos técnicos 
sobre o sistema operacional em questão, como o gerenciamento de processos, de 
memória, sistema de arquivos etc. 
 
Palavras-chave: Firefox os, processos, memória, sistema operacional 
 
 
 
ABSTRACT 
Firefox OS is an operating system developed by Mozilla for low-cost 
smartphones. It was entirely developed using Web technologies like HTML5, CSS 
and JavaScript. Its main purpose was to be used in low-end smartphones, with basic 
hardware, reaching consumers who prefer simplicity, safety and efficiency, but do not 
want or have to pay for it. The work deals with technical concepts on the operating 
system in question, such as process management, memory, file system, etc. 
Key-words: Firefox OS, process, memory, operational system 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
SUMÁRIO 
LISTAS DE FIGURAS ................................................................................................ 5 
LISTAS DE QUADROS .............................................................................................. 6 
1 INTRODUÇÃO ......................................................................................................... 7 
2 GERENCIAMENTO DE PROCESSOS .................................................................. 10 
3 GERENCIAMENTO DE MEMÓRIA ....................................................................... 12 
3.1 LOW MEMORY KILLER ............................................................................. 13 
3.2 LOW MEMORY NOTIFICATIONS .............................................................. 15 
3.3 COMO O LMK E LMN TRABALHAM JUNTOS ......................................... 16 
4 ENTRADA E SAÍDA .............................................................................................. 17 
5 SISTEMA DE ARQUIVOS ..................................................................................... 19 
5.1 ESTRUTURA E MÉTODO DE ORGANIZAÇÃO ........................................ 20 
5.2 OBJETOS E DIRETÓRIOS ......................................................................... 22 
6 SEGURANÇA ........................................................................................................ 24 
6.1 SEGURANÇA DOS APLICATIVOS ........................................................... 25 
6.2 APLICATIVOS HOSPEDADOS E EMPACOTADOS ................................. 27 
6.3 EXECUÇÃO NA SANDBOX ....................................................................... 28 
7 CONSIDERAÇÕES FINAIS ................................................................................... 29 
REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................... 31 
 
 
LISTAS DE FIGURAS
FIGURA 1 – ARQUITETURA DO FIREFOX OS. ........................................................ 9 
FIGURA 2 – ARQUITETURA DE PROCESSOS DO ESPAÇO DO USUÁRIO. ....... 17 
FIGURA 3 – CATEGORIAS DOS APLICATIVOS NO FIREFOX OS. ...................... 26 
FIGURA 4 – APLICATIVO EXECUTANDO NA SANDBOX. .................................... 29 
 
 
LISTAS DE QUADROS
QUADRO 1 – NÍVEIS DE PRIORIDADE DOS PROCESSOS. ................................. 11 
QUADRO 2 - NOMES DOS PROCESSOS E FUNÇÕES ......................................... 18 
QUADRO 3 - VERSÕES DO FIREFOX OS ..............................................................30 
 
 
1 INTRODUÇÃO 
O Firefox OS foi um sistema operacional de software livre desenvolvido pela 
Mozilla, sendo baseado no navegador da web, Mozilla Firefox. De acordo com a 
Mozilla1, é a primeira plataforma móvel inteiramente aberta, construída com 
tecnologias Web, como HTML e CSS. 
Um dos principais destaques do sistema é a busca inteligente, que consiste 
em aprender os gostos do usuário de acordo com as pesquisas que eles realizam, e 
a partir disso, oferecer recomendações de conteúdos similares. Foi anunciado 
oficialmente em 2013 e era voltado principalmente para aparelhos econômicos, para 
aqueles usuários que não tem condições de pagar por altos preços em um 
smartphone. Apesar de ser voltado a esse mercado, o sistema era bastante 
completo, com sistemas de mapas, reprodutor de mídias, aplicativos de fotografia, 
redes sociais e muito mais (BARROS, 2014). 
A principal visão da Mozilla era de criar o mais poderoso sistema aberto com 
tecnologias Web, e de incentivar a utilização dessa tecnologia aberta para criar 
softwares poderosos como o Firefox, Firefox OS e até mesmo Firefox para Android, 
oferecendo ao mesmo tempo excepcional segurança, privacidade, personalização e 
controle de usuário, coisas que um usuário espera de um navegador Web (FIREFOX 
OS, 2013). 
 
 
1 Disponível em: https://www.mozilla.org/pt-BR/firefox/os/ 
 
 
8 
Por ser construído totalmente utilizando HTML5 e com outras tecnologias 
Web abertas, o Firefox OS é livre de regras e restrições de plataformas proprietárias, 
dando aos desenvolvedores e fabricantes de telefones a flexibilidade para 
incrementar e inovar o sistema sem limites, com objetivo de sempre trazer novas e 
melhores experiências aos usuários (FIREFOX OS, 2013). 
O Firefox OS era anteriormente ao lançamento chamado de Boot to Gecko, 
ou pela abreviação B2G (MDN, 2014). Este termo ainda pode ser usado hoje em dia 
por desenvolvedores que estejam interessados na infraestrutura geral e usos que 
não estejam associados com a agenda ou prioridades do Firefox OS. 
A arquitetura do sistema está definida em três partes distintas (MDN, 2014): 
1) Gaia: É a camada de interface visual do Firefox OS, apresentada ao usuário. 
Contém várias aplicações nativas como Tela de Bloqueio e Tela Inicial, além 
de várias aplicações esperadas em um smartphone. De acordo com o site de 
desenvolvedores da Mozilla, a camada Gaia é implementada totalmente 
utilizando padrões web como HTML5, CSS, JavaScript, entre outros. Além 
disso essa camada oferece assistência para a instalação de aplicativos 
desenvolvidos por terceiros. 
2) Gecko: O Gecko oferece a infraestrutura de padrões web como HTML5, CSS, 
SVG, WebGL, JavaScript, entre outros necessários para que as aplicações 
possam ser executadas pelo sistema. Também fornece acesso às APIs do 
dispositivo, permitindo assim que os aplicativos acessemrecursos de 
hardware como GPS e a câmera. Nessa camada também estão 
implementadas várias funcionalidades básicas que são necessárias às 
aplicações, como a camada de rede e segurança, a máquina virtual do 
JavaScript, o motor de layout, entre outros. 
3) Gonk: Consiste na camada de mais baixo nível do Firefox OS e é baseada no 
kernel Linux por meio do Android Open Source Project (AOSP). Várias 
bibliotecas e o próprio kernel estão ligados a outros projetos de código 
abertos, tais como: Linux, libusb, bluez, etc. O Gonk pode ser considerada 
uma distribuição do Linux de maneira simplificada. De acordo com a 
Wikipedia (2016), o uso de parte do projeto AOSP permite ao Firefox OS usar 
algumas ferramentas comuns aos desenvolvedores Android, como o ADB e o 
 
 
9 
fastboot. Um outro benefício citado é a utilização de drivers que suportam a 
ampla variedade de dispositivos Android disponíveis no mercado. 
 
A Figura 1 abaixo permite a visualização da arquitetura do Firefox OS, 
baseada nas três camadas mencionadas anteriormente: 
Figura 1 – Arquitetura do Firefox OS. 
 
 
O Firefox OS é um sistema bastante simplificado, e para facilitar ainda mais 
a sua execução em hardwares bem limitados, é necessário que haja o 
 
 
10 
gerenciamento de processos e suas respectivas threads de maneira eficiente. A 
próxima seção abordará sobre este assunto. 
2 GERENCIAMENTO DE PROCESSOS 
De acordo com a documentação oficial do Firefox OS2, o sistema faz o uso 
de threads chamadas POSIX para implementar as threads de aplicações, incluído a 
thread principal de cada aplicação, e também as threads chamadas de Web 
Workers, que são responsáveis por executar scripts em segundo plano, tirando essa 
atividade da responsabilidade da thread UI, responsável pela interface das 
aplicações (MDN, 2014). 
As Web Workers permitem muito mais eficiência e fluidez na interface, pois 
deixam a thread UI livre para tratar apenas das atividades referentes a interface aos 
usuários. Sem elas, muitos scripts poderiam ser executados ao mesmo tempo 
apenas pela thread de UI, o que poderia ocasionar sobrecarga de atividade e 
demora na realização das tarefas, ou até mesmo falta de resposta a determinadas 
solicitações (MACIEL, 2011). 
Para priorizar processos e a execução de threads confiando no agendador 
padrão do kernel do Linux, valores “Nice” são usados e atribuídos para cada 
processo (MDN, 2014). Dependendo do status em que um processo esteja, 
diferentes valores “Nice” são atribuídos a eles, que podem ser entre os valores 
referenciados no Quadro 1 abaixo. 
 
 
2 Disponível em: https://developer.mozilla.org/pt-BR/Firefox_OS/Architecture#Processos_e_threads 
 
 
11 
Quadro 1 – Níveis de prioridade dos processos. 
Níveis de prioridade dos processos 
Prioridade Valor “Nice” Usado para 
MASTER 0 Main bg2 process 
FOREGROUND_HIGH 0 Applications holding a CPU wakelock 
FOREGROUND 1 Foreground applications 
FOREGROUND_KEYBOARD 1 Keyboard applications 
BACKGROUND_PERCEIVABLE 7 Background applications playing áudio 
BACKGROUND_HOMESCREEN 18 Homescreen application 
BACKGROUND 18 All other applications running in the 
background 
 
Alguns níveis de prioridade possuem os mesmos valores para “nice”, isso 
ocorre porque esses níveis são diferentes da maneira como são tratados pelo out of 
memory killer, a ser estudado mais adiante na seção de gerenciamento de memória 
do Firefox OS. Dentro de um processo em execução a thread principal herda o valor 
de “nice” deste processo, enquanto às threads Web Workers são dados valores 
“nice” com um ponto a mais que a thread principal, fazendo assim a thread de UI 
executar com menor prioridade (MDN, 2014). 
Esta técnica é realizada para evitar que processos que consomem muito 
processamento de CPU causem problemas a performance da thread principal. 
Apesar dos níveis de prioridades definidos, os processos podem receber alterações 
nas prioridades quando ocorrer um evento considerado grande, como quando uma 
aplicação começa a executar em segundo plano, o início de uma nova aplicação, ou 
quando um processo existente começa a executar uma wakelock da CPU. Se um 
processo recebe ajuste na sua prioridade, é fundamental que suas threads também 
recebam os devidos ajustes (MDN, 2014). 
O wakelock é um recurso que assegura que aplicativos tenham o rápido 
acesso a informações e recursos do sistema, de forma que o usuário não tenha 
conhecimento de tais solicitações. Em smartphones, podem causar um consumo 
acelerado de bateria caso se comportem de maneira errada ao esperado 
(GUGELMIN, 2014). 
Devido ao alto índice de requisições à internet e recursos do sistema que um 
wakelock mal comportado possa solicitar, isso faz com que a CPU nunca entre em 
um estado de repouso ou diminuição de suas atividades, algo que nem sempre é 
 
 
12 
aparente ao usuário. No Firefox OS, os processos podem solicitar wakelocks de alta 
prioridade, e quando isso ocorre, eles serão os últimos a serem encerrados caso 
haja uma falta de memória no sistema (MDN, 2014). 
Os valores “nice” dados aos processos e suas respectivas threads são 
utilizados também para identificar possíveis aplicações a serem encerradas caso 
haja uma falta de memória no sistema. Essas particularidades serão mencionadas 
na próxima seção. 
3 GERENCIAMENTO DE MEMÓRIA 
Por ser um sistema simples e voltado aos smartphones de baixo custo, 
geralmente com memórias e recursos de hardware limitados, é possível que vários 
processos executando ao mesmo tempo no Firefox OS esgotem a memória de tais 
dispositivos. E quando esse problema ocorre, o sistema é responsável por fazer o 
gerenciamento da memória, por meio do encerramento de alguns processos 
escolhidos pelo kernel (MDN, 2014). 
O Firefox OS funciona com vários processos relacionados, possuindo um 
processo principal que executa as funções básicas do sistema e potencialmente 
muitos processos filhos, responsáveis por executar as demais funcionalidades do 
sistema e aplicativos. O sistema operacional muita das vezes finaliza os processos 
quando necessário para liberar memória, já que o usuário dificilmente fecha as 
aplicações (MDN, 2014). 
 
 
13 
Para o gerenciamento da memória, dois subsistemas são usados no Firefox 
OS, chamados de: Low memory killer (LMK – Finalizador de memória baixa) e Low 
memory notifications (Notificações de pouca memória). 
3.1 LOW MEMORY KILLER 
 
O Low Memory Killer (LMK) é um subsistema do Android que tem a 
responsabilidade de encerrar automaticamente processos em execução quando há 
a necessidade de executar novas aplicações e o espaço em memória está 
insuficiente. Cada processo recebe um valor de prioridade que será necessário na 
hora de escolher quais processos serão encerrados para liberação de memória 
(MDN, 2014). Essas prioridades são conhecidas como pontuação de ajuste, ou 
oom_adj. Os menores valores correspondem a processos de maior prioridade. 
Com a pontuação de ajuste, o LMK decide quais processos serão 
encerrados quando houver necessidade, e geralmente os que possuem maior 
pontuação, são escolhidos. O LMK disponibiliza diversos níveis, cada um 
correspondendo a um tamanho de memória e a uma pontuação de ajuste mínima 
(MDN, 2014). 
O LMK sempre verifica o nível de memória livre no sistema, e sempre que 
essa quantidade de memória cair de um certo nível, ele verifica os processos que 
estão com pontuação de ajuste maior do que o mínimo especificado para este nível, 
para eleger qual será encerrado (MDN, 2014). A partir disso, ele começa a encerrar 
os processos com maior pontuação, até que haja memóriasuficiente novamente. 
No Firefox OS os processos são encerrados seguindo a política de ordem de 
prioridade, e não necessariamente o processo que causou a falta de memória. 
Como já mencionado, cada processo recebe um nível de prioridade e uma 
pontuação de ajuste. Assim, o LMK decide quais processos encerrar seguindo as 
seguintes prioridades (MDN, 2014): 
 
 
14 
a) Os primeiros aplicativos a serem finalizados são os que executam em 
segundo plano, verificando o menos utilizado recentemente; 
b) Caso ainda haja necessidade de memória livre, o sistema encerra o 
aplicativo homescreen; 
c) Em sequência, os aplicativos em segundo plano que são perceptíveis ao 
usuário são encerrados, como um player de música que esteja 
reproduzindo áudio em background, ou um aplicativo que possua um 
wakelock de alta prioridade; 
d) Se ainda necessitar de memória, o LMK encerra o processo do teclado, 
caso esteja sendo usado; 
e) Aplicações em primeiro plano são encerradas em seguida; 
f) E por último, as aplicações que solicitaram um wakelock de alta 
prioridade ou CPU são encerradas. 
Alguns processos filhos em execução recebem a pontuação de ajuste de 
valor oom_adj 2 enquanto estão em primeiro plano. Se forem executados em 
segundo plano o valor de oom_adj fica entre 3 e 6. Este valor exato depende de 
vários fatores como: se o processo executa um player de música, se é um aplicativo 
da tela inicial, etc (MDN, 2014). 
Para que o sistema execute de maneira consistente, há exceções quanto as 
regras citadas anteriormente (MDN, 2014): 
a) O processo principal responsável pelas funções básicas do sistema nunca 
é encerrado, pois se isso ocorrer, os processos filhos também serão 
encerrados e o sistema operacional reiniciará. Por isso, este processo 
recebe o valor na pontuação de ajuste como oom_adj 0; 
b) Existe um processo que sempre se mantêm ativo, chamado de 
preallocated process, responsável por auxiliar na velocidade de abertura 
de um aplicativo. Este processo consome pouca memória, e a única 
situação em que é encerrado é somente se o processo principal ainda 
 
 
15 
continuar sem memória mesmo depois de todos os outros processos filhos 
tiverem sido finalizados. 
3.2 LOW MEMORY NOTIFICATIONS 
Este segundo mecanismo é o Low Memory Notifications (LMN), ou em 
português, Notificação de Pouca Memória. O LMK fornece um limite especial que 
quando é ultrapassado habilita a notificações de memória para o espaço do usuário 
informando a situação de pouca memória disponível no sistema. Os aplicativos de 
sistema e os regulares são projetados para reagir ao evento memory-pressure por 
meio do serviço observer (MDN, 2014). 
Utilizando o codebase do Gecko, esse evento é utilizado para liberar a maior 
quantidade de memória possível, por meio de limpezas de caches internos 
(imagens, DNS, etc), descartando objetos que possam ser criados novamente e 
executando o serviço de Garbage Collector (MDN, 2014). 
Quando uma situação de pouca memória for encontrada, o evento memory-
pressure será enviado com o parâmetro low-memory e aguardará uma reação do 
sistema. Se após um determinado período de cinco segundos a situação de pouca 
memória persistir, o sistema envia outro evento memory-pressure com o parâmetro 
de low-memory-ongoing. Por meio desse parâmetro, o subsistema avisa que a 
condição de pouca memória persiste e que deve ser feito algo para liberar mais 
espaço, como limpeza de caches e utilizando-se de outras formas consideradas 
mais baratas para liberar essa memória, evitando ao máximo o uso do Garbage 
Collector, mas se houver necessidade ele será utilizado (MDN, 2014). 
 
 
 
16 
3.3 COMO O LMK E LMN TRABALHAM JUNTOS 
Os dois subsistemas citados como LMK e LMN trabalham juntos para 
solucionar o problema de pouca memória. Assim, quando são necessários, seguem 
a sequência de prioridades a seguir: 
a) Os primeiros aplicativos encerrados são os que executam em segundo 
plano em ordem dos menos usados recentemente; 
b) Se ainda houver necessidade de memória, é disparado o evento 
memory-pressure para os aplicativos em execução; 
c) Se condição continuar, o evento é reenviado a cada cinco segundos, 
porém são marcados como em execução para que os processos de 
Garbage Collector não respondam a eles; 
d) O aplicativo da tela inicial é encerrado; 
e) Aplicações em segundo plano novamente são escolhidas, agora as 
perceptíveis ao usuário e de alta prioridade; 
f) Encerra o aplicativo do teclado caso esteja sendo executado. 
g) Encerra aplicativos em primeiro plano; 
h) Encerra os aplicativos em primeiro plano de alta prioridade; 
i) E por último, termina os processos pré-alocados. 
Verifica-se que o Firefox OS por meio desses dois subsistemas de 
gerenciamento de memória evita ao máximo aparentar ao usuário que existe pouca 
memória disponível e tenta resolver a situação internamente. Quando a situação de 
limitação de memória não tem como ser resolvida discretamente, o sistema parte 
para o encerramento de aplicativos que o usuário esteja utilizando, ainda assim 
seguindo uma escala de prioridade entre os processos (MDN, 2014). 
 
 
17 
4 ENTRADA E SAÍDA 
Entrada e saída é algo presente na computação e responsável pela conexão 
entre várias partes de um sistema computacional. Funciona como uma interface 
para conectar a camada física com a lógica. Ao contrário do que se pensa das 
interfaces de entrada e saída, ela não é apenas um conector físico, mas opera para 
possibilitar a comunicação lógica entre barramentos e dispositivos. 
Dentro do contexto do Firefox OS, para possibilitar que vários componentes 
se encaixem e permitam uma interação uns com os outros é necessária a 
identificação de como ocorrem essas ações internas condicionadas na arquitetura 
de processos no espaço do usuário como visto na Figura 2 abaixo. 
Figura 2 – Arquitetura de processos do espaço do usuário. 
 
Fonte: Mozilla Developer Network. 
 
 
18 
O processo B2G (BootToGecko) é primário no conjunto do Firefox OS com 
alto privilégio e comunicação livre com todos os dispositivos de hardware. 
Internamente ele executa a camada Gecko que outrora fora explicado. O 
B2G e passível, por exemplo, de se comunicar com modem, escrever no buffer de 
tela, possuir interações com o GPS interno, acionar a câmera e possibilitar os 
serviços de comunicação de qualquer aparelho telefônico. 
Os processos ao longo do estudo poderão se repetir, então é bom verificar o 
significado de cada um deles no Quadro 2, como também de outras palavras para 
evitar um desvio de contexto. 
Quadro 2. Nomes dos processos e funções. 
Nome do Processo Função 
B2G O processo b2g é responsável por disparar um número de processos de 
baixo privilégio. 
RIL Interage com o hardware modem (telefonia) no telefone. Consiste em 
duas componentes: 
 Rild daemon fala com o firmware do modem; 
 RilProxy proxies mensagens entre rild eo processo B2G. 
MEDIASERVER Controles de reprodução de áudio e vídeo. Gecko se comunica com o 
servidor de mídia através de um mecanismo RPC Android. 
NETD Utilizado para configurar interfaces de rede 
WPA_SUPPLICANT Serviço padrão UNIX que gerencia conectividade com pontos de acesso 
WiFi. 
DBUS-DAEMON Processo de implementa D-BUS, sistema de barramento de mensagens 
utilizado pelo FFXOS para comunicação Bluetooth. 
DOM Convenção multi-plataforma e independente de linguagem para 
representação e interação com objetos e documentos. Os nós de cada 
documento são organizados em “arvore”. 
API São instruções ou padrões que são orientados como interface afim 
possibilitar a interações de elementos que são diferente entre si.19 
OpenGl OpenGL é definida como "um programa de interface para hardware 
gráfico" (MANSSOUR, 2003). 
RPC Chamada de procedimento remoto. É uma tecnologia de comunicação 
entre processos. 
D-BUS É um mecanismo que permite a comunicação entre vários programas 
executando de forma simultânea e atuando como comunicador entre 
processos e como chamada de procedimento remoto. 
 
5 SISTEMA DE ARQUIVOS 
O Firefox OS trabalha com o sistema de arquivos denominado Yet Another 
Filesystem 2 (Mais um sistema de arquivos flash 2), ou abreviado como YAFFS2. O 
YAFFS foi desenvolvido por Charles Manning em 2001, para a empresa Aleph One. 
Sua primeira versão foi nomeada como Yaffs 1 e projetada para chips NAND então 
vigentes na época com 512 bytes de tamanho de página (WIKIPEDIA, 2016). 
Em meados de 2002, o Yaffs estava sendo testado em vários produtos. No 
entanto, ganhou mais notoriedade quando foi anunciado para dispositivos Linux em 
setembro de 2002 (MANNING, 2012). O YAFFS2 é uma atualização da primeira 
versão, permitindo o suporte para dispositivos maiores e diferentes, com diferentes 
restrições. É altamente portátil e tem sido usado em muitos produtos e aplicações 
diferentes, tais como telefones, pontos de venda e em aplicações aeroespaciais 
 
 
20 
(MANNING, 2012). O Yaffs oferece suporte nativo para Linux, Windows CE e Ecos, 
e tem sido usado com diferentes CPUs e compiladores. 
De acordo com Manning (2012), o YAFFS2 foi concebido para atender a 
tamanhos de página maiores ou iguais a 1K. 
5.1 ESTRUTURA E MÉTODO DE ORGANIZAÇÃO 
No sistema de arquivos Yaffs, utilizado pelo Firefox OS, um objeto é 
considerado com sendo qualquer coisa no sistema de arquivos. Podem ser: arquivos 
regulares (dados do usuário), diretórios, links simbólicos, e objetos especiais (tubos, 
dispositivos etc), e são identificados por um ID único e inteiro (MANNING, 2012). 
No modelo padrão POSIX do Linux, existem i-nodes e entradas de diretórios, 
onde um i-node pode ser um arquivo regular, diretório ou arquivo especial de 
sistema. As entradas de diretórios fornecem os mecanismos para nomeação usados 
para localizar os i-nodes. Ainda sob o POSIX, de acordo com Manning (2012), cada 
i-node pode ter zero, um ou muitas entradas de diretórios, porém o mais comumente 
entendido é que haja apenas uma entrada por i-node. 
Como a maioria dos sistemas de arquivos flash, o YAFFS2 é um sistema de 
arquivos estruturado por logs, o que permite a escrita sequencialmente e o 
armazenamento. As entradas no registro podem ser dados ou pedaços de 
cabeçalho. Cada pedaço tem seus atributos com os seguintes valores: identificação 
do objeto, id do pedaço, número do sequenciador e contagem de bytes (SIROTKIN, 
2010). 
 Identificação do objeto: identifica a que objeto, ou seja, i-node ou 
entrada de diretório o bloco pertence; 
 Id do pedaço contém a localização o pedaço de bloco dentro do objeto; 
 Número do sequenciador é usado para indicar pedaços não mais 
usados, tendo em vista que o YAFFS2 não pode modificar um já 
existente – cada bloco tem que ser escrito apenas uma vez. Esse 
número é incrementado quando um novo bloco é alocado para o uso 
permitindo assim classificar os pedaços em ordem cronológica. 
 
 
21 
Quando há modificações no arquivo, em vez de alterar as informações 
diretamente onde estão no armazenamento, como outros sistemas de arquivos 
fazem, o YAFFS2 escreve um novo bloco para o registro log. Dado um pouco de 
tempo, alguns desses blocos terão um certo número de dados considerados 
obsoletos, e que precisam ser coletados para descarte (SIROTKIN, 2010). 
Quando um bloco é constituído somente de pedaços excluídos de 
informações, este bloco pode ser apagado e reutilizado. No entanto é importante 
considerar que se houver muitos blocos que possuam alguns pedaços de dados 
atuais neles, é evidente que não podem ser apagados para reutilização pois assim 
haverá perda de dados (MANNING, 2012). O necessário a realizar é uma cópia 
desses pedaços de dados úteis em um novo bloco, excluindo assim os originais e 
permitindo que o bloco antigo possa ser apagado e reutilizado em sua totalidade. 
Desta forma, o processo de coleta de lixo entra em ação para manter a 
integridade dos dados e do sistema de arquivos, por buscar blocos que contenham 
pedaços obsoletos de informações ou quase não utilizados em sua totalidade. Esse 
trabalho é baseado por duas heurísticas que determinam o modo de recolhimento 
que a coleta de lixo funciona (MANNING, 2012): 
a) Se houver muitos blocos apagados disponíveis, então o coletor de lixo 
não realiza um trabalho duro, apenas faz uma tentativa para coletar lixo 
de blocos com poucos pedaços em uso, sendo denominado tal maneira 
como coleta de lixo “passiva”. 
b) No entanto, caso haja poucos blocos apagados disponíveis, o coletor de 
lixo trabalha no modo “agressivo”, realizando uma busca mais 
aprofundada no sistema de arquivos para procurar blocos com poucos 
pedaços em uso e dados obsoletos, para eliminá-los e reorganizar tais 
dados em novos blocos. 
Se o coletor de lixo trabalha no modo agressivo, o bloco inteiro é recolhido 
em um único ciclo de coleta. Se a coleta de lixo estiver trabalhando passivamente, 
seu esforço será reduzido e espalhado por vários ciclos para reduzir a carga do 
coletor de lixo (MANNING, 2012). 
A lógica por trás das heurísticas, de acordo com Manning (2012) é atrasar a 
coleta de lixo quando possível para aumentar o desempenho do sistema de 
arquivos, já que essa atividade é considerada dispendiosa. Porém, todo os sistemas 
 
 
22 
de arquivos necessitam de algum tipo de coleta de lixo para recuperar espaço, e o 
coletor se torna um fator determinante para o desempenho do sistema (MANNING, 
2012). Este algoritmo está sendo aprimorado com o intuito de aumentar o seu 
rendimento. 
5.2 OBJETOS E DIRETÓRIOS 
 
Cada objeto no sistema é representado por um yaffs_obj. Sua principal 
função é armazenar metadados sobre o arquivo, o que significa que quase todas as 
informações sobre o objeto podem ser acessadas sem a necessidade de uma leitura 
flash. Tais metadados incluem (MANNING, 2012): 
 ObjectId: o número de identificação do objeto; 
 Parent: um ponteiro para o objeto pai. Nem todos os objetos 
necessariamente precisam ter um pai, como por exemplo, o diretor de 
raiz e diretórios especiais, sendo este metadado preenchido como 
NULL, neste caso. 
 Nome curto: Se o nome do arquivo for curto e couber na matriz de 
tamanho fixo (padrão 16 caracteres), então ele pode ser armazenado 
aqui. Caso contrário, será necessária uma leitura flash para obtê-lo. 
 Tipo: o tipo do objeto. 
 Permissões: tempo, propriedade e outros atributos. 
Os objetos são organizados em diretórios, que também são considerados 
objetos do sistema. A estrutura de diretório tem a finalidade de permitir o rápido 
acesso ao objeto pelo nome, necessário para executar operações com o arquivo, 
como abrir, renomear, editar etc (MANNING, 2012). 
A estrutura de diretórios Yaffs é formada por uma árvore de objetos do tipo 
YAFFS_OBJECT_TYPE_DIRECTORY. Cada partição do Yaffs tem um diretório raiz, 
bem como alguns diretórios chamados “falsos”, que são criados para duas situações 
(MANNING, 2012): 
 
 
23 
 Lost + found: Usado para armazenar todas as partes de arquivos 
perdidos que não podem ser colocados na árvore de diretórios normal. 
 Desvinculada e excluídos: Estes são pseudo-diretórios que não estão 
na árvore. Colocar objetos nestes diretórios faz com que recebam o 
status de desvinculados ou excluídos. 
 
Cada objeto tem um nome que é usado para encontra-lo na arvore do 
diretório. Por esse motivo, os nomesdos objetos não podem ser repetidos, devem 
ser exclusivos. Contudo, essa regra não se aplica ao pseudo-diretório dos arquivos 
desvinculados ou excluídos uma vez que podem existir vários arquivos deletados 
com o mesmo nome (MANNING, 2012). 
 
 
6 SEGURANÇA 
O Firefox OS possui uma plataforma de segurança baseada em multi-
camadas, definida para suavizar os riscos de exploração de falhas em todos os 
níveis. Por meio dos seguintes níveis, o sistema conecta as aplicações web ao 
hardware subjacente: 
a) Gaia: A camada de interface ao usuário com as aplicações web. 
b) Gecko: A camada de aplicação que fornece o framework para executar 
os aplicativos e implementar as APIs web necessárias para acessar os recursos de 
hardware do telefone. 
c) Gonk: A camada onde se encontra o kernel do Linux, bibliotecas do 
sistema e os drivers necessários para acesso ao hardware. 
d) O dispositivo móvel: o celular executando o Firefox OS. 
A camada Gecko é considerada a guardiã da plataforma, pois ela aplica as 
políticas de segurança definidas para o sistema com o intuito de proteger o 
dispositivo de uso indevido. Ela ainda atua como uma camada intermediária entre a 
interface do usuário (Gaia) e o telefone (MDN, 2014). 
A camada Gonk fornece os recursos de hardware para a camada Gecko. Os 
aplicativos web acessam os recursos de hardware do telefone apenas se a camada 
 
 
25 
Gecko permitir, pois não há acesso direto, muito menos a ação conhecida como 
“back door” no telefone (MDN, 2014), pois o Gecko exige as permissões de acesso e 
impede o uso dos recursos caso as solicitações não tenham sido autorizadas. 
O Firefox OS vem instalado no smartphone de fábrica e sua imagem é 
criada por uma fonte confiável e conhecida, normalmente uma fabricante de 
telefones, responsável pela montagem, compilação, teste e assinatura digital do 
pacote de distribuição (MDN, 2014). 
Os privilégios de acesso ao sistema de arquivos são aplicados por listas de 
controle de acessos do Linux. Além disso, os aplicativos do sistema são instalados 
em uma área de memória com privilégios de apenas leitura, a não ser quando ocorre 
uma atualização, onde é permitido temporariamente a gravação (MDN, 2014). No 
geral, somente o volume com o conteúdo do usuário pode ter privilégio de escrita. 
Vários componentes de hardware do telefone possuem proteções implementadas 
internamente com práticas padrão da indústria. 
6.1 SEGURANÇA DOS APLICATIVOS 
O Firefox OS possui uma estratégia de defesa nomeada como defense-in-
depth responsável por proteger o dispositivo de aplicações maliciosas e intrusivas. 
Por meio dessa estratégia, são empregados vários mecanismos com vistas a 
oferecer a maior segurança possível para o sistema e o dispositivo, como níveis de 
permissionamento para as aplicações, execução em sandbox, acesso ao hardware 
somente via APIs, etc (MDN, 2014). 
Devido a todos os aplicativos do Firefox OS serem construídos utilizando-se 
de tecnologias web (HTML5, CSS, JavaScript), e assim não possuir binários 
(nativos) instalados no sistema, o acesso ao sistema é intermediado por meio de 
Web APIs, incluindo até mesmo o acesso ao sistema de arquivos e o banco de 
dados SQLite. Não há acesso direto pelos aplicativos aos arquivos armazenados em 
um cartão SD (MDN, 2014). 
 
 
26 
Os aplicativos possuem categorias e certificações que os diferenciam dentro 
do sistema, tais categorias podem ser visualizadas na Figura 2. 
Figura 3 – Categorias dos aplicativos no Firefox OS. 
 
Fonte: Portal da Mozilla Developer Network. 
Por meio da Figura 2 verifica-se que existem três categorias de aplicativos e 
suas respectivas certificações. A primeira delas são os aplicativos categorizados 
como Certificados e com altíssimo nível de confiança. Esses aplicativos são aqueles 
próprios do sistema desenvolvidos pela Mozilla ou por Operadoras ou fabricantes de 
OEM (Original Equipment Manufacturer). Se reserva a apenas um número limitado 
de aplicações, como por exemplo: SMS, Bluetooth, relógio, telefone, etc (MDN, 
2014). 
A segunda categoria corresponde aos aplicativos Privilegiados e com nível 
de confiança marcado como “Confiável”. Essa categoria diz respeito aos aplicativos 
desenvolvidos por terceiros. Contudo, antes de serem publicados para distribuição 
na loja de aplicações do Firefox OS (conhecida como Marketplace), necessitam 
 
 
27 
passar por séries de revisões, para serem aprovados e digitalmente assinados para 
serem certificados e distribuídos (MDN, 2014). 
A última categoria é definida para os conteúdos Web e recebe o nível de 
confiança de “Não Confiável”. Essa categoria condiz com todo o conteúdo da web, 
incluindo os aplicativos instalados no telefone bem como os hospedados (MDN, 
2014). O nível de confiança de cada aplicativo define a sua permissão de acesso 
aos recursos do telefone: 
- Aplicativos certificados possuem todas as permissões para a maioria das 
operações das Web APIs. 
- Aplicativos privilegiados tem permissões para um subconjunto das Web 
APIs acessadas pelos aplicativos certificados. 
- Aplicativos não confiáveis possuem permissões para um subconjunto das 
Web APIs acessadas pelos aplicativos privilegiados. 
6.2 APLICATIVOS HOSPEDADOS E EMPACOTADOS 
No Firefox OS os aplicativos podem ser empacotados ou hospedados. Um 
aplicativo empacotado possui um arquivo ZIP com todos os seus recursos (códigos, 
imagens, etc), e também um arquivo de manifesto onde possui suas permissões e 
restrições. Os aplicativos certificados e privilegiados devem ser empacotados para 
que o seu arquivo de manifesto seja digitalmente assinado. Quando o usuário obtém 
um aplicativo empacotado, seu arquivo ZIP é baixado e instalado no dispositivo, e 
durante o processo de instalação, os arquivos são verificados e permanecem 
inalterados dentro do pacote (MDN, 2014). 
Os aplicativos hospedados possuem outro comportamento. São 
armazenados em um servidor web e carregados via requisição HTTP. O único 
arquivo que fica armazenado no dispositivo é seu arquivo de manifesto. Todo o 
 
 
28 
restante continua armazenado remotamente. De acordo com o portal MDN (2014), 
algumas APIs do sistema estão disponíveis somente para aplicativos certificados, 
onde há a necessidade de serem empacotados para receber a assinatura digital. 
Devido a isso, aplicativos hospedados não possuem acesso a nenhuma operação 
de API que exija a certificação ou privilégio de tal aplicação. 
Um aplicativo hospedado funciona da seguinte maneira: Ele é carregado por 
meio de uma chamada de URL, que está descrita diretamente no código que aponta 
para uma página de início, encontrada no diretório raiz do aplicativo armazenado em 
um servidor web. Quando o aplicativo é carregado, o dispositivo conecta às páginas 
usando as mesmas URLs utilizadas para acesso ao website (MDN, 2014). 
6.3 EXECUÇÃO NA SANDBOX 
O sistema utiliza a técnica de sandboxing como uma estratégia de defesa 
para proteção do dispositivo. Consiste na execução de um aplicativo em um espaço 
próprio a ele e com as devidas permissões de acesso às Web APIs, gerenciadas 
pela camada Gecko. Isolando o aplicativo desta maneira, ele passa a trabalhar 
somente dentro do seu espaço e suas tarefas não podem interferir em nada fora 
dele (como em outros aplicativos e dados) (MDN, 2014). 
Como já mencionado anteriormente, o Gecko executa um processo principal 
que tem alto privilégio de acesso aos recursos de hardware no dispositivo, e dentro 
deste, os processos filhos podem ser executados. Os processos filhos tem um 
pequeno conjunto de privilégios. Assim, o acesso às Web APIs são mediados pelo 
processo pai, controlando assim a permissão necessáriapara executar determinada 
ação (MDN, 2014). 
A Figura 3 fornece uma representação do modelo de segurança fornecido 
pela sandbox. 
 
 
29 
Figura 4 – Aplicativo executando na Sandbox. 
 
Fonte: Portal da Mozilla Developer Network. 
Os aplicativos se comunicam somente com o processo principal, chamado 
de B2G, não podem ser executados independentes deste nem podem abrir outros 
aplicativos. O acesso ao hardware também é limitado, permitido somente por meio 
das Web APIs do Firefox OS, implementadas na camada Gecko (MDN, 2014). Não 
existe uma maneira alternativa, nem “back-doors” que acessem o hardware ou 
penetre na camada de baixo nível do software. 
7 CONSIDERAÇÕES FINAIS 
O Firefox OS foi uma tentativa da Mozilla para entrar no mercado 
competitivo de smartphones, já dominado pelo Android e iOS em sua grande 
maioria. Várias versões do sistema foram lançadas para corrigir erros e trazer 
 
 
30 
novidades à plataforma. Apesar de pouco assunto ter sido encontrado sobre tais 
versões, no Quadro 2 é possível visualizar a data de compilação e de lançamento 
delas. 
Quadro 2 – Versões do Firefox OS 
Versão Primeira build Lançamento 
1.0 14 de agosto de 2012 21 de Fevereiro de 2013 
1.0.1 25 de Janeiro de 2013 06 de Setembro de 2013 
1.1.0 20 de Fevereiro de 2013 09 de Outubro de 2013 
1.1.1 24 de Agosto de 2013 
 
1.2.0 21 de Junho de 2013 09 de Dezembro de 2013 
1.2.1 04 de Dezembro de 2013 
 
1.3.0 17 de Setembro de 2013 17 de Março de 2014 
1.4.0 10 de Dezembro de 2013 8 de Agosto de 2014 
1.5.0 17 de Março de 2014 
 
2.0.0 21 de Fevereiro de 2014 
 
2.1.0 09 de Junho de 2014 
 
2.2.0 02 de Setembro de 2014 20 de Agosto de 2015 
2.5.0 12 de Janeiro de 2015 
 
2.6.0 30 de Outubro de 2015 Fevereiro de 2016 
Fonte: Adaptado de Wikipedia (2016) 
Contudo, mesmo após o lançamento das versões referidas no Quadro 2, a 
Mozilla encerrou as atividades do seu sistema operacional móvel em smartphones, 
por não alcançar o objetivo de despertar a atenção tanto do público quanto de 
fabricantes, desenvolvedores e investidores, e isso pode ser verificado pelo pouco 
número de aplicativos disponíveis para a plataforma e os telefones lançados com o 
sistema operacional embarcado de fábrica (GARRETT, 2016). 
Apesar de a Mozilla ter encerrado a distribuição do Firefox OS para 
smartphones, a tecnologia desenvolvida para o sistema deve ser aproveitada para a 
Internet das Coisas (loT), área de mercado que já está na mira de muitas empresas 
e a Mozilla não quer ficar para trás dessa vez (VIEIRA, 2015). 
 
 
REFERÊNCIAS BIBLIOGRÁFICAS 
 BARROS, Thiago. Firefox OS é o sistema operacional móvel da Mozilla. 
Disponível em: <http://www.techtudo.com.br/tudo-sobre/firefox-os.html> 
Acesso em: 30 Abril 2016. 
 FIREFOX OS. Firefox OS Features Guide. Disponível em: < 
https://blog.mozilla.org/press/files/2013/08/FIREFOX_OS_FEATURES_GUID
E_2013_EN.pdf> Acesso em: 24 Abril 2016. 
 MACIEL, Murilo. Web Workers: seu processador trabalhando para o 
HTML5. Disponível em: 
<http://imasters.com.br/artigo/22612/desenvolvimento/web-workers-seu-
processador-trabalhando-para-o-html5/> Acesso em: 30 Abril 2016. 
 MANNING, Charles. How Yaffs Works. Disponível em 
<http://www.yaffs.net/documents/how-yaffs-works> Acesso em: 10 Maio 2016. 
 MDN. Mozilla Developer Network. Firefox OS: Arquitetura do Firefox OS. 
Disponível em: <https://developer.mozilla.org/pt-
BR/Firefox_OS/Architecture#Processos_e_threads> Acesso em: 30 Abril 
2016. 
 GARRETT, Filipe. Firefox OS: versão do Firefox para celular chega ao fim. 
Disponível em: <http://www.techtudo.com.br/noticias/noticia/2016/02/firefox-
os-versao-do-firefox-para-celular-chega-ao-fim.html> Acesso em: 11 Maio 
2016. 
 GUGELMIN, Felipe. Descubra o que são wakelocks e como eles afetam a 
bateria de seu Android. Disponível em: < 
http://www.tecmundo.com.br/android/59782-descubra-wakelocks-eles-afetam-
bateria-android.htm> Acesso em: 30 Abril 2016. 
 
 
 MANSSOUR, Isabel. Introdução à OpenGL. Disponível em: 
<http://www.inf.pucrs.br/~manssour/OpenGL/Introducao.html> Acesso em: 14 
Maio 2016. 
 SIROTKIN, Sarah. YAFFS2: Yet another flash file system. Disponível em: 
<http://www.drdobbs.com/embedded-systems/yaffs2-yet-another-flash-file-
system/226400083?> Acesso em: 10 Maio 2016. 
 VIEIRA, Douglas. Mozilla encerra o desenvolvimento do Firefox OS para 
smartphones. Disponível em: <http://www.tecmundo.com.br/firefox-os/91516-
mozilla-encerra-desenvolvimento-firefox-smartphones.htm> Acesso em: 11 
Maio 2016. 
 WIKIPEDIA. YAFFS. Disponível em: < https://en.wikipedia.org/wiki/YAFFS> 
Acesso em: 10 Maio 2016.