Tester og anmeldelser

Android operativsystem. Hva er Android? De fungerer på Android-plattformen som

Artikler og Lifehacks

I dag er det allerede vanskelig å finne en person som ikke vil omgi seg med "smart" teknologi. Uttrykket "uten telefon er som uten hender" høres oftere og oftere, og det er generelt umulig å forestille seg livet uten en spiller, bærbar PC eller annen populær dings.

Derfor bør alle vite om de nye produktene som dukker opp på det moderne elektronikkmarkedet. For eksempel er det ikke alle som vet hva Android-plattformen er, men vi skal prøve å finne ut av det.

Hva er Android

  • Android er et operativsystem som kan styre en mobilenhet (telefon, nettbrett, smarttelefon). Android-plattformen ble utviklet basert på Linux-kjernen.
  • Det dukket opp på grunn av det faktum at Google i 2005 kjøpte Android Inc, noe som gjorde det til datterselskapet, og begynte å produsere plattformer med samme navn for mobile enheter. Siden den gang har plattformen bare vært i utvikling.
  • Android gir ofte ut nye versjoner av programmet sitt. Bemerkelsesverdig er det faktum at de første bokstavene i navnet på hver ny versjon tilsvarer bokstavene i det latinske alfabetet.
  • I dag rangerer Android-plattformen på andreplass i popularitet i verden, nest etter drift iOS-system, som ble utviklet for iPhone.

Hva er Android for?

  • Som du vet, er operativsystemet "hjernen" til enhver elektronisk enhet, som er nødvendig for at den skal utføre alle menneskelige kommandoer.
  • Følgelig er en android en virtuell robot som sitter inne i en mobilenhet, som er ansvarlig for å utføre alle prosesser som skjer inne i denne enheten.
  • Fordelen med denne plattformen er at Android har et praktisk og veldig intuitivt grensesnitt, samt et fleksibelt og multitasking-system som lar deg kjøre flere applikasjoner samtidig og eksperimentere med innstillinger.
  • Blant annet gir mange applikasjoner laget spesielt for Android-plattformen de glade brukerne av dette systemet virkelig ubegrensede muligheter.
  • Tross alt, ved hjelp av disse applikasjonene kan du betale for kjøp, ta bilder, se filmer eller lese bøker.
  • Etter å ha forstått hva Android er, kan vi konkludere med at denne plattformen er laget for kreative mennesker, fordi to identiske mobile enheter kan se helt forskjellige ut.
  • Android lar deg alltid ha alt med deg - en personlig treningstrener, en lege, et leketøy eller en TV, noe som gjør livet så komfortabelt som mulig.

Har du noen gang lurt på hvordan fastboot eller ADB fungerer? Eller hvorfor en smarttelefon er under Android-kontroll nesten umulig å gjøre om til en murstein? Eller kanskje du lenge har ønsket å vite hvor magien til Xposed-rammeverket ligger og hvorfor oppstartsskriptene /system/etc/init.d trengs? Hva med gjenopprettingskonsollen? Er dette en del av Android eller en ting i seg selv, og hvorfor er vanlig gjenoppretting ikke egnet for å installere tredjeparts fastvare? Du finner svar på alle disse og mange andre spørsmål i denne artikkelen.

Hvordan Android fungerer

Finn ut om skjulte muligheter programvaresystemer du kan ved å forstå prinsippet om deres drift. I noen tilfeller er dette vanskelig å gjøre, siden systemkoden kan være lukket, men for Android kan vi studere hele systemet innvendig og utvendig. I denne artikkelen vil jeg ikke snakke om alle nyansene til Android og vil bare fokusere på hvordan operativsystemet starter og hvilke hendelser som finner sted i intervallet mellom å trykke på strømknappen og utseendet til skrivebordet.

Underveis vil jeg forklare hva vi kan endre i denne hendelseskjeden og hvordan tilpassede fastvareutviklere bruker disse egenskapene til å implementere slike ting som å justere OS-parametere, utvide applikasjonslagringsplass, tilkoblingsbytte, ulike tilpasninger og mye mer. All denne informasjonen kan brukes til å lage din egen firmware og implementere ulike hacks og modifikasjoner.

Trinn én. ABOOT og partisjonstabell

Det hele starter med den primære oppstartslasteren. Etter å ha slått på strømmen, kjører systemet bootloader-koden som er lagret i enhetens permanente minne. Deretter overfører den kontrollen til aboot-bootloaderen med innebygd støtte for fastboot-protokollen, men produsenten av mobilbrikken eller smarttelefonen/nettbrettet har rett til å velge hvilken som helst annen bootloader. For eksempel bruker Rockchip sin egen bootloader som ikke er fastboot-kompatibel og krever proprietære verktøy for å flashe og administrere.

Fastboot-protokollen er på sin side et system for å administrere bootloaderen fra en PC, som lar deg utføre handlinger som å låse opp bootloaderen, blinke en ny kjerne og gjenoppretting, installere fastvare og mange andre. Begrunnelsen for fastboot er å kunne gjenopprette en smarttelefon til sin opprinnelige tilstand i en situasjon der alle andre midler mislykkes. Fastboot vil forbli på plass selv om du som et resultat av eksperimenter sletter alle NAND-minnepartisjoner som inneholder Android og gjenoppretting fra smarttelefonen din.

Etter å ha mottatt kontroll, sjekker aboot partisjonstabellen og overfører kontrollen til kjernen som ble flashet inn i partisjonen som heter boot, hvoretter kjernen trekker ut RAM-bildet fra den samme partisjonen til minnet og begynner å laste enten Android eller gjenopprettingskonsollen. NAND-minne i Android-enheter er delt inn i seks betinget nødvendige seksjoner:

  • boot - inneholder kjernen og RAM-disken, vanligvis rundt 16 MB i størrelse;
  • gjenoppretting - gjenopprettingskonsoll, består av en kjerne, et sett med konsollapplikasjoner og en innstillingsfil, størrelse 16 MB;
  • system - inneholder Android, i moderne enheter er størrelsen minst 1 GB;
  • cache - designet for lagring av hurtigbufrede data, også brukt til å lagre fastvare under en OTA-oppdatering og har derfor en størrelse som ligner størrelsen på systempartisjonen;
  • brukerdata - inneholder innstillinger, applikasjoner og brukerdata, all gjenværende NAND-minneplass er allokert til den;
  • misc - inneholder et flagg som bestemmer hvilken modus systemet skal starte opp i: Android eller gjenoppretting.

I tillegg til dem kan det også være andre seksjoner, men den generelle markeringen bestemmes på designstadiet til smarttelefonen og, i tilfelle avstart, sys inn i oppstartslasterkoden. Dette betyr at: 1) partisjonstabellen ikke kan drepes, siden den alltid kan gjenopprettes med kommandoen fastboot oem format; 2) for å endre partisjonstabellen, må du låse opp og laste opp bootloaderen på nytt med nye parametere. Det finnes imidlertid unntak fra denne regelen. For eksempel lagrer oppstartslasteren til samme Rockchip informasjon om partisjoner i den første blokken med NAND-minne, så det er ikke nødvendig å blinke oppstartslasteren for å endre den.

Den diverse delen er spesielt interessant. Det er en antagelse om at det opprinnelig ble opprettet for å lagre ulike innstillinger uavhengig av hovedsystemet, men i for øyeblikket brukes kun til ett formål: å indikere til oppstartslasteren fra hvilken partisjon systemet skal lastes - oppstart eller gjenoppretting. Spesielt denne funksjonen brukes av ROM Manager-applikasjonen for automatisk å starte systemet på nytt til gjenoppretting med automatisk installasjon av fastvaren. På grunnlag av det er Ubuntu Touch dual boot-mekanismen bygget, som flasher Ubuntu bootloader til gjenoppretting og lar deg kontrollere hvilket system som skal startes opp neste gang. Slettet misc-partisjonen - Android laster, fylte den med data - gjenopprettingslast... det vil si Ubuntu Touch.

Trinn to. Bootseksjon

Hvis div-delen ikke har et gjenopprettingsoppstartsflagg, overfører aboot kontrollen til koden som ligger i oppstartsdelen. Dette er ikke noe mer enn Linux-kjernen; den er plassert i begynnelsen av delen, og umiddelbart etterfulgt av et RAM-diskbilde pakket ved hjelp av cpio- og gzip-arkiver, som inneholder katalogene som er nødvendige for at Android skal fungere, initialiseringssystemet for init og andre verktøy. Det er ikke noe filsystem på oppstartspartisjonen; kjernen og RAM-disken følger ganske enkelt hverandre. Innholdet på RAM-disken er:

  • data - katalog for montering av partisjonen med samme navn;
  • dev - enhetsfiler;
  • proc - procfs er montert her;
  • res - et sett med bilder for laderen (se nedenfor);
  • sbin - et sett med verktøy og demoner (adbd, for eksempel);
  • sys - sysfs er montert her;
  • system - katalog for montering av systempartisjonen;
  • lader - applikasjon for å vise ladeprosessen;
  • build.prop - systeminnstillinger;
  • init - initialiseringssystem;
  • init.rc -er;
  • ueventd.rc - innstillinger for uventd-demonen inkludert i init.

Dette er så å si skjelettet til systemet: et sett med kataloger for tilkobling av filsystemer fra NAND-minnepartisjoner og et initialiseringssystem som skal håndtere resten av arbeidet med å starte opp systemet. Det sentrale elementet her er init-applikasjonen og dens init.rc-konfigurasjon, som jeg vil snakke om i detalj senere. I mellomtiden vil jeg gjøre deg oppmerksom på laderen og ueventd.rc-filene, samt sbin-, proc- og sys-katalogene.

Ladefilen er en liten applikasjon hvis eneste jobb er å vise batteriikonet på skjermen. Den har ingenting med Android å gjøre og brukes når enheten er koblet til laderen i av-tilstand. I dette tilfellet laster ikke Android, og systemet laster ganske enkelt inn kjernen, kobler til RAM-disken og starter laderen. Sistnevnte viser et batteriikon, hvis bilde i alle mulige tilstander er lagret i vanlige PNG-filer inne i res-katalogen.

Filen ueventd.rc er en konfigurasjon som bestemmer hvilke enhetsfiler i sys-katalogen som skal opprettes under systemoppstart. I kjernebasert Linux-systemer Tilgang til maskinvaren utføres gjennom spesielle filer inne i dev-katalogen, og ueventd-demonen, som er en del av init, er ansvarlig for opprettelsen av dem i Android. I en normal situasjon fungerer det automatisk modus, aksepterer kommandoer for å lage filer fra kjernen, men noen filer må opprettes uavhengig. De er oppført i ueventd.rc.

sbin-katalogen på lager Android inneholder vanligvis ingenting bortsett fra adbd, det vil si ADB-daemonen, som er ansvarlig for å feilsøke systemet fra PC-en. Den kjører tidlig i OS-oppstarten og lar deg oppdage mulige problemer på OS-initieringsstadiet. I tilpasset fastvare i denne katalogen kan du finne en haug med andre filer, for eksempel mke2fs, som kan være nødvendig hvis partisjonene må formateres til ext3/4. Moddere plasserer også ofte en BusyBox der, som du kan ringe hundrevis av Linux-kommandoer med.

Proc-katalogen er standard for Linux i de neste oppstartsfasene, init vil koble til den procfs, et virtuelt filsystem som gir tilgang til informasjon om alle prosesser på systemet. Systemet vil koble sysfs til sys-katalogen, som åpner tilgang til informasjon om maskinvaren og dens innstillinger. Ved å bruke sysfs kan du for eksempel sette enheten i dvale eller endre strømsparingsalgoritmen som brukes.

build.prop-filen er laget for å lagre Android-innstillinger på lavt nivå. Senere vil systemet tilbakestille disse innstillingene og overskrive dem med verdier fra den for øyeblikket utilgjengelige system/build.prop-filen.


Takeaways fra teksten

  • Fastboot vil forbli på plass selv om du, som et resultat av eksperimenter, sletter innholdet i alle NAND-minneseksjoner fra smarttelefonen din
  • Gjenopprettingsdelen er helt selvforsynt og inneholder et miniatyroperativsystem som på ingen måte er relatert til Android
  • Ved å modifisere fstab-filen litt, kan vi tvinge init til å starte opp systemet fra minnekortet

Trinn to, alternativ. Gjenopprettingsdelen

Hvis gjenopprettingsoppstartsflagget i div-delen er satt eller brukeren slår på smarttelefonen med volum ned-tasten holdt nede, vil aboot overføre kontrollen til koden som ligger i begynnelsen av gjenopprettingsdelen. I likhet med oppstartspartisjonen inneholder den kjernen og en RAM-disk, som pakkes ut i minnet og blir roten til filsystemet. Imidlertid er innholdet på RAM-disken noe annerledes her.

I motsetning til oppstartspartisjonen, som fungerer som en overgangskobling mellom ulike stadier av lasting av OS, er gjenopprettingspartisjonen helt selvforsynt og inneholder et miniatyroperativsystem som på ingen måte er forbundet med Android. Recovery har sin egen kjerne, sitt eget sett med applikasjoner (kommandoer) og sitt eget grensesnitt som lar brukeren aktivere tjenestefunksjoner.

I en standard (lager) gjenoppretting er det vanligvis bare tre slike funksjoner: installasjon av fastvare signert med nøkkelen til smarttelefonprodusenten, tørk og start på nytt. Modifiserte tredjepartsgjenopprettinger, som ClockworkMod og TWRP, har mye flere funksjoner. De kan formatere filsystemer, installere fastvare signert med alle nøkler (les: tilpasset), montere filsystemer på andre partisjoner (for OS-feilsøkingsformål) og inkludere skriptstøtte, som lar deg automatisere fastvareprosessen og mange andre funksjoner.

Ved å bruke skript, for eksempel, kan du sørge for at gjenoppretting etter oppstart automatisk finner den nødvendige fastvaren på minnekortet, installerer dem og starter på nytt i Android. Denne funksjonen brukes av ROM Manager, auto-flasher og automatisk oppdatering CyanogenMod og annen fastvare.

Tilpasset gjenoppretting støtter også sikkerhetskopieringsskript som ligger i katalogen /system/addon.d/. Før flashing, ser gjenoppretting etter skript og kjører dem før fastvaren flashes. Takket være slike skript forsvinner ikke gapps etter installasjon av en ny fastvareversjon.

fastboot-kommandoer

For å få tilgang til fastboot, må du installere Android SDK, koble smarttelefonen til PC-en med en kabel og slå den på ved å holde begge volumknappene. Etter dette bør du gå til underkatalogen plattformverktøy inne i SDK-en og kjøre kommandoen

Fastboot-enheter

Enhetsnavnet vil vises på skjermen. Andre tilgjengelige kommandoer:

  • fatsboot oem låse opp- låse opp bootloader på nexuses;
  • oppdater file.zip- installasjon av fastvare;
  • flash boot boot.img- blinker oppstartspartisjonsbildet;
  • flash recovery recovery.img- blinker gjenopprettingspartisjonsbildet;
  • flash system system.img- blinke systembildet;
  • oem-format- restaurering av en ødelagt partisjonstabell;

Trinn tre. Initialisering

Så, etter å ha mottatt kontroll, kobler kjernen RAM-disken og, etter initialisering av alle undersystemene og driverne, starter init-prosessen, som starter initialiseringen av Android. Som jeg allerede har sagt, har init en konfigurasjonsfil init.rc, hvorfra prosessen lærer nøyaktig hva den må gjøre for å få systemet opp. I moderne smarttelefoner har denne konfigurasjonen en imponerende lengde på flere hundre linjer og er også utstyrt med en tilhenger av flere barnekonfigurasjoner som er koblet til hovedkonfigurasjonen ved hjelp av importdirektivet. Imidlertid er formatet ganske enkelt og er egentlig et sett med kommandoer delt inn i blokker.

Hver blokk definerer et lastestadium eller, på Android-utviklerspråk, en handling. Blokker er atskilt fra hverandre med et on-direktiv etterfulgt av handlingsnavnet, for eksempel på early-init eller på post-fs. Blokken med kommandoer vil bare bli utført hvis utløseren med samme navn utløses. Når den starter, vil init aktivere early-init, init, early-fs, fs, post-fs, early-boot og boot-utløsere etter tur, og dermed starte de tilsvarende kommandoblokkene.


Hvis konfigurasjonsfilen trekker sammen flere konfigurasjoner som er oppført i begynnelsen (og dette er nesten alltid tilfellet), vil kommandoblokkene med samme navn i dem bli kombinert med hovedkonfigurasjonen, slik at når utløseren utløses, vil init utfør kommandoer fra de tilsvarende blokkene i alle filene. Dette gjøres for å gjøre det enklere å lage konfigurasjonsfiler for flere enheter, når hovedkonfigurasjonen inneholder kommandoer som er felles for alle enheter, og de spesifikke for hver enhet er skrevet i separate filer.

Den mest bemerkelsesverdige av de ekstra konfigurasjonene heter initrc.device_name.rc, der enhetsnavnet bestemmes automatisk basert på innholdet i ro.hardware-systemvariabelen. Dette er en plattformspesifikk konfigurasjonsfil som inneholder kommandoblokker som er spesifikke for bestemt enhet. I tillegg til kommandoene som er ansvarlige for å justere kjernen, inneholder den også noe som dette:

Mount_all ./fstab.device_name

Det betyr at init nå skal montere alle filsystemer som er oppført i filen ./fstab.device_name, som har følgende struktur:

Device_name (partisjon) mount_point file_system fs_options andre alternativer

Den inneholder vanligvis instruksjoner for montering av filsystemer fra interne NAND-partisjoner til katalogene /system (OS), /data (applikasjonsinnstillinger) og /cache (bufrede data). Ved å endre denne filen litt, kan vi imidlertid tvinge init til å starte opp systemet fra minnekortet. For å gjøre dette, del bare minnekortet i tre 4 seksjoner: 1 GB / ext4, 2 GB / ext4, 1 GB / ext4 og den gjenværende fat32-plassen. Deretter må du bestemme navnene på minnekortpartisjonene i /dev-katalogen (for forskjellige enheter de er forskjellige) og erstatte dem med de originale enhetsnavnene i fstab-filen.


På slutten av boot init-blokken vil den mest sannsynlig møte standardkommandoen class_start, som vil informere deg om at du da bør starte alle tjenestene som er oppført i konfigurasjonen som er relatert til standardklassen. Beskrivelsen av tjenester begynner med tjenestedirektivet, etterfulgt av navnet på tjenesten og kommandoen som må utføres for å starte den. I motsetning til kommandoene som er oppført i blokkene, må tjenester kjøres hele tiden, så gjennom hele smarttelefonens levetid vil init henge i bakgrunnen og overvåke dette.

Moderne Android inkluderer dusinvis av tjenester, men to av dem har en spesiell status og definerer helheten livssyklus systemer.

init.rc-kommandoer

Init-prosessen har et innebygd sett med kommandoer, hvorav mange er standard Linux-kommandoer. Den mest bemerkelsesverdige av dem:

  • exec /path/to/command- kjør en ekstern kommando;
  • ifup-grensesnitt- heve nettverksgrensesnittet;
  • klasse_start klassenavn- start tjenester som tilhører den angitte klassen;
  • klasse_stopp klassenavn- stopptjenester;
  • insmod /bane/til/modul- last inn kjernemodulen;
  • montere FS-enhetskatalog- koble til filsystemet;
  • setprop navn verdi- angi en systemvariabel;
  • start tjenestenavn- start den angitte tjenesten;
  • utløsernavn- aktiver triggeren (utfør den angitte blokken med kommandoer);
  • skriv /bane/til/fillinje- skrive en linje til en fil.

Trinn fire. Zygote og app_process

På et visst stadium av lasting vil init møte på slutten av konfigurasjonen noe sånt som denne blokken:

Tjeneste zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server class standard socket zygote stream 660 rotsystem onrestart skriv /sys/android_power/request_state våkne ved restart skriv /sys/power/state on onrestart restart media onrestart restart netd

Dette er en beskrivelse av Zygote-tjenesten, en nøkkelkomponent i ethvert Android-system som er ansvarlig for initialisering, start systemtjenester, starte og stoppe brukerapplikasjoner og mange andre oppgaver. Zygote lanseres ved hjelp av en liten applikasjon /system/bin/app_process, som er veldig tydelig synlig i ovenstående del av konfigurasjonen. App_proccess-oppgaven er å starte den virtuelle Dalvik-maskinen, hvis kode er plassert i det delte biblioteket /system/lib/libandroid_runtime.so, og deretter kjøre Zygote på toppen av den.

Når alt dette er gjort og Zygote har kontroll, begynner den å bygge Java-applikasjonens kjøretid ved å laste inn alle rammeverkets Java-klasser (for tiden over 2000 av dem). Deretter starter den system_server, som inkluderer de fleste av systemtjenestene på høyt nivå (skrevet i Java), inkludert Window Manager, Statuslinje, Pakkeansvarlig og viktigst av alt Activity Manager, som i fremtiden skal ha ansvar for å motta signaler om start og slutt på søknader.

Etter dette åpner Zygote socket /dev/socket/zygote og går i dvale og venter på data. På dette tidspunktet sender den tidligere lanserte Activity Manager en kringkastingsintensjon Intent.CATEGORY_HOME for å finne applikasjonen som er ansvarlig for å lage skrivebordet og gir navnet sitt til Zygote via kontakten. Sistnevnte på sin side gafler og kjører applikasjonen på toppen av den virtuelle maskinen. Voila, vi har et skrivebord på skjermen vår, funnet av Activity Manager og lansert av Zygote, og en statuslinje lansert av system_server som en del av Status Bar-tjenesten. Etter å ha trykket på ikonet, vil skrivebordet sende en hensikt med navnet på denne applikasjonen, Activity Manager vil motta den og sende kommandoen for å starte applikasjonen til Zygote-demonen

INFO

I Linux-terminologi er en RAM-disk en slags virtuell harddisk, eksisterer bare i RAM. Tidlig i oppstartsprosessen trekker kjernen ut diskinnholdet fra bildet og monterer det som rotfilsystemet (rootfs).

Under oppstartsprosessen viser Android tre forskjellige oppstartsskjermer: den første vises umiddelbart etter at du har trykket på strømknappen og blinket inn i Linux-kjernen, den andre vises under de tidlige stadiene av initialisering og registreres i filen /initlogo.rle (neppe brukes i dag), lanseres den siste ved hjelp av bootanimation-applikasjonen og finnes i filen /system/media/bootanimation.zip.

I tillegg til standardutløsere lar init deg definere dine egne utløsere, som kan utløses av en rekke hendelser: koble en enhet til USB, endre tilstanden til en smarttelefon eller endre tilstanden til systemvariabler.

Blant annet dreper Activity Manager også bakgrunnsapplikasjoner når det ikke er nok minne. Gratis minneterskelverdier er inneholdt i filen /sys/module/lowmemorykiller/parameters/minfree.

Alt dette kan se litt forvirrende ut, men det viktigste er å huske tre enkle ting:

På mange måter er Android veldig forskjellig fra andre operativsystemer, og det er vanskelig å finne ut av det med en gang. Men hvis du forstår hvordan alt fungerer, er mulighetene rett og slett uendelige. I motsetning til iOS og Windows Phone, har Googles operativsystem en veldig fleksibel arkitektur som lar deg endre atferden seriøst uten å måtte skrive kode. I de fleste tilfeller er det nok å korrigere de nødvendige konfigurasjonene og skriptene.

Android operativsystem fra Google

Historie om Android-utvikling, Android-oppdateringer, Android Market

Del 1. Kjennetegn ved Android-operativsystemet.

Android er bærbart (nettverk) operativsystem for kommunikatorer, nettbrett, elektroniske bøker, digitale spillere, klokker, netbooks og smartbooks, basert på Linux-kjernen.

Android er et relativt ungt operativsystem som brukes på et bredt spekter av mobile enheter.

Kjennetegn på Android-operativsystemet

Den ble opprinnelig utviklet av Android Inc., som senere ble kjøpt av Google. Deretter startet Google opprettelsen av Open Handset Alliance (OHA), som nå er engasjert i å støtte og videreutvikle plattformen. Android lar deg lage Java-applikasjoner som styrer enheten gjennom Google-utviklede biblioteker. Android Native Development Kit lager programmer skrevet på C og andre språk.

75 % av smarttelefonene solgt i tredje kvartal 2012 hadde OS installert Android-system.

Ved hjelp av Android kan du finne både kommunikatorer (den vanligste klassen) og nettbrett (nettbrett), netbook eller smartbook. Også produsenter slutter ikke å eksperimentere, og integrerer operativsystemet i forskjellig utstyr. En Android-klokke eller TV-set-top-boks vil ikke overraske noen lenger.

Operativsystemet ble utviklet av Android Inc., som deretter ble kjøpt opp av Google og overført til OHA - Open Handset Alliance, en forening dedikert til utvikling og implementering av åpne mobilstandarder. I tillegg til Google inkluderer OHA giganter som HTC, Intel, Motorola, Qualcomm, Samsung, LG, T-Mobile og Nvidia.

Video:

Selv om operativsystemet er basert på Linux-kjernen, bruker det ikke alle funksjonene til dette operativsystemet. Grunnen til dette er bruken av den virtuelle Dalvik-maskinen, der alt fungerer programvare. Men med utgivelsen av Native Development Kit har utviklere muligheten til å lage native applikasjoner i C og andre programmeringsspråk.


Oppdater historikkAndroid

Den første versjonen av Android ble presentert tilbake i september 2008 og kun for T-Mobile G1 (HTC Dream)-kommunikatoren. Den mottok også en oppdatering til versjon 1.1, kunngjort seks måneder senere.

Den raske utviklingen av operativsystemet begynte med versjonene av Cupcake (1.5) og Donut (1.6). Versjon 2.0 Eclair ble en mellomversjon, og versjon 2.1 bar nøyaktig samme navn. Det var under kontroll av sistnevnte at noen av de mest populære enhetene ble presentert - Nexus One og dens "bror" HTC Desire.

Deretter ble Android 2.2 Froyo utgitt, og ga brukere støtte for HTML5 og Flash 10.1 webteknologier, noe som gjorde at de kunne oppnå en betydelig fordel i forhold til sine konkurrenter.

Deretter introduserte selskapet Android 2.3 Gingerbread med et oppdatert brukergrensesnitt, støtte for NFC-standarden, flere kameraer og høyoppløselige skjermer.


Men vi ser de mest globale endringene i Android 3.0 Honeycomb, en spesialversjon for nettbrett. Den har et helt annet brukergrensesnitt, 3D-effekter, en brukervennlig nettleser og mange andre forbedringer.

Android 3.0 Honeycomb vil dessverre kun være tilgjengelig for nettbrett. På kommunikatorer vil vi bare kunne se porterte versjoner eller...

For øyeblikket er versjon Android 2.4 bare kjent fra rykter. Men kanskje blir det en analog av nettbrettversjonen tilpasset smarttelefoner og kommunikatører.

Video:

Siden utgivelsen av den første versjonen i september 2008 har det skjedd flere systemoppdateringer. Disse oppdateringene gjelder vanligvis å fikse oppdagede feil og legge til ny funksjonalitet til systemet. Hver versjon av systemet får sitt eget kodenavn med desserttema. Kodenavn tildeles i alfabetisk rekkefølge.


I november 2012 hadde 14 versjoner av systemet blitt utgitt. Siste versjon- 4.2 Jelly Bean ("Lollipop med tyggefyll").

Det er et fellesskap av entusiaster som utvikler helt åpne versjoner av Android-fastvare (som CyanogenMod, MIUI, Virtuous Quattro, VillainROM, Open Kang Project, Replicant).

Modifiserte versjoner av Android (også kalt "fastvare" eller "tilpasset fastvare") er laget for:

fjerning av Google-tjenester fra Android-enheten (for eksempel datasynkronisering) - for å sikre lokalisering av brukerdata kun på Android-enheten - eliminerer muligheten for å overføre identifikasjonsinformasjon (IMEI, telefonnummer, GPS-koordinater, etc.) til servere Google;

mer rask og hyppig (sammenlignet med produsentene av enhetene selv) levering av nye versjoner av Android OS. Det er ikke uvanlig at en produsent slutter å støtte en modell som de fant utdatert eller ulønnsom, og brukere som ønsker å se nye funksjoner må henvende seg til arbeidet til entusiaster, selv om mange systemisk utdaterte telefoner har muligheten til å oppdateres ytterligere (Nexus One er et godt eksempel).

Video:

tillegg til Android-fastvare med nye innstillinger og funksjoner. Som for eksempel støtte for FLAC Lossless Audio, muligheten til å lagre nedlastede applikasjoner på et MicroSD-kort (for Android opp til versjon 2.2), etc.


For å flashe en Android-enhet kreves root-tilgang (dette kalles rooting), noe som gir større kontroll over systemet og applikasjonene som er installert som standard. For rottilgang er det ikke nødvendig å låse opp bootloader (en ulåst bootloader lar deg starte opp to eller flere operativsystemer på enheten). Modifisert fastvare lar brukere av eldre telefoner bruke applikasjoner som kun er tilgjengelige for nyere utgivelser, øker stabiliteten, hastigheten og blir ofte kvitt produsentens feil.

Alle produsenter av Android-enheter blokkerer i utgangspunktet root-tilgang (og muligheten for å blinke) med maskinvare, motivert av ønsket om å beskytte brukeren mot å installere skadelig programvare og beskytte enheten mot skade. Men på grunn av den utbredte bruken av komplekse hackerteknikker for å omgå denne beskyttelsen, ble produsentene tvunget til å møtes halvveis og skape muligheten for offisielt å låse opp telefoner (Sony Ericsson – Unlocking the boot loader service, HTC – Unlocking Your Bootloader service). Risikoen forbundet med mulig havari av telefonen under opplåsingsprosessen overføres til brukeren, som ved opplåsing av bootloaderen godtar betingelsene som indikerer tidlig tap av telefonens garanti. Og noen produsenter gikk enda lenger og gjorde alt for at en avansert bruker ikke bare kunne installere annen fastvare, men også lage sin egen (detaljerte instruksjoner for å erstatte fastvare, programvare, dokumentasjon om arkitekturen til programvareplattformen, original firmwarekode, etc. leveres ) og støtter utviklingen av alternativ fastvare (Sony Ericsson sponser CyanogenMod). I tillegg eliminerer dette (et Sony Ericsson-initiativ) behovet for å bruke uprøvde hackingverktøy for blinkingsprosessen (for eksempel for HTC).

I interessekonflikter mellom de to partene (produsentene av telefonene selv sammen med Google og brukere) kan følgende motivasjon spores:

produsenter ønsker å installere "reklame"-applikasjoner på telefoner som ikke kan fjernes uten rooting;

Video:

Google ønsker å samle inn så mye informasjon som mulig om brukeren: ikke bare personlige data som adresser e-post eller historien til besøk på nettsteder, men også informasjon om brukerens bevegelser (GPS-koordinater eller, når GPS-mottakeren er slått av, plasseringen av enheten basert på mobiltårnsignaler) i sanntid, noe som førte til rettslige prosesser.

Produsenter streber ikke etter å raskt oppdatere operativsystemet, og etter omtrent seks måneder slutter de å støtte produktet, og tvinger dermed kjøpere til å bytte til nye telefonmodeller.

Den 24. september 2009 henvendte Google seg til CyanogenMod-utviklerne med et brev som krevde fjerning av deler av systemet og lukkede kilder (som Market, GPS-navigasjon, Maps, etc.) fra den alternative fastvaren. Som et resultat ble "lukkede" applikasjoner fjernet fra Android-versjonen av CyanogenMod, og under installasjonsprosessen av CyanogenMod har brukeren muligheten til å i tillegg installere en programvarepakke fra Google eller i tillegg installere alternative versjoner av "lukkede" programmer (en alternativ versjon av «Maps» osv.), som tillot tvister og ga brukerne muligheten til å være eller ikke være fri fra Google-applikasjoner.


Historien om Android-utvikling

juli – Google kjøpte Android Inc.

5. september - Opprettelsen av Open Handset Alliance (OHA)-gruppen av selskaper ble offisielt kunngjort, hvis formål er å utvikle åpne standarder for mobile enheter. For tiden forener OHA 34 selskaper, inkludert de største mobiloperatørene T-Mobile, mobiltelefonprodusenter HTC-enheter, Intel, Sprint Nextel, KDDI, NTT DoCoMo, China Mobile, chiputviklerne Broadcom, Marvell, NVIDIA, Qualcomm, SiRF, Texas Instruments, LG, Motorola, Samsung Electronics, samt en global IT-industrigigant og en av hovedinspiratorene av alliansen, Google-selskapet. Samtidig med introduksjonen av OHA ble den åpne mobilplattformen Android, basert på Linux-kjernen, annonsert.

12. november - den første versjonen av Android-utviklerpakken "Early Look" SDK ble presentert og tilbudt for nedlasting.


23. september - Google-selskap sammen med mobiloperatør T-Mobile og den taiwanske produsenten HTC annonserte den første enheten basert på Android 1.0-plattformen – T-Mobile G1-smarttelefonen (HTC Dream).

Den første fullverdige SDK 1.0, versjon 1, har blitt utgitt.

12. januar – Android 2.1 utgitt. Noen kilder kaller denne versjonen "Flan", men den er en del av "Eclair"-utgivelsen.

mai – Android 2.2 (FroYo) utgitt

Desember – Android 2.3 (Gingerbread) utgitt

15. august – Google nådde en avtale med styret i Motorola Mobility om å kjøpe telekommunikasjonsselskapet for 12,5 milliarder dollar.

Fontfamiliene Droid og Roboto ble laget spesielt for Android-plattformen.

Navnet på hver versjon, fra og med 1.5, av Android OS er navnet på en dessert. De første bokstavene i navnene i versjonsrekkefølge tilsvarer bokstavene i det latinske alfabetet: 1,5 Cupcake, 1,6 Donut, 2,0/2,1 Eclair, 2,2 Froyo (forkortelse for frossen yoghurt) , 2,3 Pepperkaker, 3,0 Honeycomb, 4,0 Ice Cream Sandwich, 4.1/4.2 Jelly Bean, 5.0 Key Lime Pie ("key lime pie"), Lollipop ("lollipop"), Melasse ("melasse") og Nougat ("nougat") (kursiv indikerer fremtidige og/eller ubekreftede versjoner).

De to første var navnene på kjente roboter: 1.0 Astro ("Astro Boy") og 1.1 Bender ("Futurama"), men de ble endret til desserter på grunn av opphavsrett.

Fra februar 2011 ledet enheter med Android OS selvsikkert listen over de mest populære smarttelefonene i Storbritannia, og etterlot iPhone 4 med iOS. Ifølge eksperter er dette det første steget til Android OS mot global lederskap på mobilmarkedet operativsystemer.

De offisielle Android-nettstedene angir fortsatt ikke minimumskravene til maskinvare for å kjøre operativsystemet (det er bare maskinvarekrav for Android-utviklingssettet).

På den offisielle Android-nettsiden nederst til venstre, hvis du holder musepekeren over roboten, utfører den forskjellige bevegelser, og når den klikkes, vifter den med hånden.

I versjon Android 1.6 la utviklerne til Native Development Kit, som lar deg skrive dine egne lavnivåmoduler for systemet i C/C++, basert på standard Linux-biblioteker. Selv om for eksempel standard C-biblioteket på Android-plattformen, kjent som Bionic, ikke er standard og er fullstendig kompatibelt med libc.

Video:

For å få tilgang Google Play og andre tjenester fra Google må bruke proprietære applikasjoner som telefonprodusenten har rett til å installere på telefonen først etter å ha inngått en kontrakt med Google.

Androids konkurrenter har kritisert plattformen, og anklaget den for å være altfor fragmentert og hemme utviklere. Google benektet alle påstander og sa at det ikke var slike problemer, men ga likevel ut et verktøy for å overvinne fragmenteringsproblemer.

Googles beslutning om ikke å offentliggjøre Android 3.0 Honeycomb-koden, som kun er tilgjengelig for medlemmer av Open Handset Alliance eller på individuell forespørsel etter at avtalen er signert, har blitt kritisert. Google motiverer dette med utilgjengelighet av plattformen og et tiltak for å forhindre uforsiktig implementering av den.

Richard Stallman uttalte at "det er klart og enkelt: med unntak av Linux-kjernen, er Android 3 proprietær programvare" og "mens Android-telefoner i dag ikke er like ille som Apple- eller Windows-smarttelefoner, kan de ikke sies å respektere din frihet. " Ifølge Google er den lukkede koden til Android 3.0 et midlertidig tiltak, men selv etter utgivelsen av versjon 4 var ikke kildene til 3.0 åpne.

Ifølge Lookout Security Mobile, i 2011 alene, ble omtrent en million amerikanske dollar stjålet fra Android-smarttelefonbrukere.

Den 21. oktober 2008 publiserte OHA Alliance kildekoden til Android-plattformen. Utgivelsen inkluderte hele Android-stabelen: operativsystemet, mellomvaren og hovedapplikasjonene skrevet i Java. Den totale størrelsen på Android-kildekoden var 2,1 GB. "Foretrukket lisens" for Android-kildekoden er Apache License 2.0. Etter utgivelsen av Android 3.0 Honeycomb kunngjorde presidenten for Googles mobilavdeling, Andy Rubin, at den åpne kildekoden til den nye versjonen av systemet ville bli forsinket på grunn av det faktum at systemet var dårlig forberedt til å kjøre på kommunikatorer og kreves betydelige optimaliseringer. Denne avgjørelsen trakk kritikk fra analytikere: for eksempel kalte ZDNet-spaltist Christopher Dawson Googles trekk skuffende. Men ifølge løftene fra selskapet, åpnet Google kildekodene til neste versjon av systemet - Android 4.0 Ice Cream Sandwich - høsten 2011.


Android-enheter

Den første enheten som kjører Android var HTC Dream-smarttelefonen utviklet av HTC (offisielt utgitt mobiloperatør T-Mobile kalt T-Mobile G1), presentasjonen fant sted 23. september 2008. Snart fulgt av en rekke uttalelser fra andre smarttelefonprodusenter om deres intensjon om å gi ut enheter basert på Android. Med utgivelsen av den tredje versjonen av Android (Honeycomb), rettet mot nettbrett, begynte flere og flere produsenter å kunngjøre utgivelsen av nettbrett på denne plattformen. Google produserer også, i samarbeid med ulike giganter i mobilindustrien, sine egne enheter i «Google Nexus»-serien. Disse enhetene er de første som mottar oppdateringer til nye versjoner.

I tillegg til smarttelefoner og nettbrett er Android-operativsystemet også installert på andre enheter. På slutten av 2009 ble den første fotorammen som kjører på Android, i salg. I juni 2011 kunngjorde det italienske selskapet Blue Sky utgivelsen av i'mWatch smart armbåndsur som kjører Android OS. I august 2012 introduserte Nikon verdens første kamera som også kjører på Googles plattform. Den allerede nevnte "Google Nexus"-serien inkluderer ikke bare smarttelefoner og nettbrett, men også Nexus Q mediespiller som kjører på Android.


I tillegg har entusiaster portert Android til en rekke kjente enheter, inkludert for eksempel Windows Mobile-smarttelefonene HTC Touch Dual og HTC TyTN II, som Android ble kjørt på i emuleringsmodus. Full portering ble også utført på enheter som Internett-nettbrett som kjører på Maemo - Nokia N810 og Nokia N900 (en port kalt Nitdroid) - og på smarttelefoner Nokia N9 som kjører på MeeGo-plattformen og HTC HD2 kjører på operativsystemet Windows-system Mobil, der Android OS kan kjøres både fra et microSD-kort og fra internt NAND-minne. Samtidig installert system har full, ubegrenset funksjonalitet. I tillegg er det en vellykket opplevelse av å installere Android på noen Apple-enheter - iPhone, iPod Touch og iPad bruker spesialprogram kalt Openiboot, som er designet for å kjøre en rekke operativsystemer på disse enhetene, inkludert Android. Forhåndsfastvare med begrenset funksjonalitet vises på enheter som kjører Bada-operativsystemet. Koolu begynte ikke bare å portere Android til Neo FreeRunner, men bygget også sin virksomhet på å selge disse smarttelefonene med Googles mobilplattform forhåndsinstallert. Den første offisielle og offentlige betaversjonen av en Android-port av Koolus Neo FreeRunner fant sted i desember 2008. Android har også blitt overført til x86-arkitektur.


Kilder

Wikipedia – The Free Encyclopedia, WikiPedia

android.com – Android-nettsted

proandroid.net – Android-applikasjoner

youhtc.ru – Alt for NTS-telefoner

Har du noen gang lurt på hvordan fastboot eller ADB fungerer? Eller hvorfor er det nesten umulig å gjøre en smarttelefon som kjører Android til en murstein? Eller kanskje du lenge har ønsket å vite hvor magien til Xposed-rammeverket ligger og hvorfor oppstartsskriptene /system/etc/init.d trengs? Hva med gjenopprettingskonsollen? Er dette en del av Android eller en ting i seg selv, og hvorfor er vanlig gjenoppretting ikke egnet for å installere tredjeparts fastvare? Du finner svar på alle disse og mange andre spørsmål i denne artikkelen.

Hvordan Android fungerer

Du kan lære om de skjulte egenskapene til programvaresystemer ved å forstå prinsippet for deres drift. I noen tilfeller er dette vanskelig å gjøre, siden systemkoden kan være lukket, men for Android kan vi studere hele systemet innvendig og utvendig. I denne artikkelen vil jeg ikke snakke om alle nyansene til Android og vil bare fokusere på hvordan operativsystemet starter og hvilke hendelser som finner sted i intervallet mellom å trykke på strømknappen og utseendet til skrivebordet.

Underveis vil jeg forklare hva vi kan endre i denne hendelseskjeden og hvordan tilpassede fastvareutviklere bruker disse egenskapene til å implementere slike ting som å justere OS-parametere, utvide applikasjonslagringsplass, tilkoblingsbytte, ulike tilpasninger og mye mer. All denne informasjonen kan brukes til å lage din egen firmware og implementere ulike hacks og modifikasjoner.

Trinn én. ABOOT og partisjonstabell

Det hele starter med den primære oppstartslasteren. Etter å ha slått på strømmen, kjører systemet bootloader-koden som er lagret i enhetens permanente minne. Deretter overfører den kontrollen til aboot-bootloaderen med innebygd støtte for fastboot-protokollen, men produsenten av mobilbrikken eller smarttelefonen/nettbrettet har rett til å velge hvilken som helst annen bootloader. For eksempel bruker Rockchip sin egen bootloader som ikke er fastboot-kompatibel og krever proprietære verktøy for å flashe og administrere.

Fastboot-protokollen er på sin side et system for å administrere bootloaderen fra en PC, som lar deg utføre handlinger som å låse opp bootloaderen, blinke en ny kjerne og gjenoppretting, installere fastvare og mange andre. Begrunnelsen for fastboot er å kunne gjenopprette en smarttelefon til sin opprinnelige tilstand i en situasjon der alle andre midler mislykkes. Fastboot vil forbli på plass selv om du som et resultat av eksperimenter sletter alle NAND-minnepartisjoner som inneholder Android og gjenoppretting fra smarttelefonen din.

Etter å ha mottatt kontroll, sjekker aboot partisjonstabellen og overfører kontrollen til kjernen som ble flashet inn i partisjonen som heter boot, hvoretter kjernen trekker ut RAM-bildet fra den samme partisjonen til minnet og begynner å laste enten Android eller gjenopprettingskonsollen. NAND-minne i Android-enheter er delt inn i seks betinget nødvendige seksjoner:

  • boot - inneholder kjernen og RAM-disken, vanligvis rundt 16 MB i størrelse;
  • gjenoppretting - gjenopprettingskonsoll, består av en kjerne, et sett med konsollapplikasjoner og en innstillingsfil, størrelse 16 MB;
  • system - inneholder Android, i moderne enheter er størrelsen minst 1 GB;
  • cache - designet for lagring av hurtigbufrede data, også brukt til å lagre fastvare under en OTA-oppdatering og har derfor en størrelse som ligner størrelsen på systempartisjonen;
  • brukerdata - inneholder innstillinger, applikasjoner og brukerdata, all gjenværende NAND-minneplass er allokert til den;
  • misc - inneholder et flagg som bestemmer hvilken modus systemet skal starte opp i: Android eller gjenoppretting.
I tillegg til dem kan det også være andre seksjoner, men den generelle markeringen bestemmes på designstadiet til smarttelefonen og, i tilfelle avstart, sys inn i oppstartslasterkoden. Dette betyr at: 1) partisjonstabellen ikke kan drepes, siden den alltid kan gjenopprettes med kommandoen fastboot oem format; 2) for å endre partisjonstabellen, må du låse opp og laste opp bootloaderen på nytt med nye parametere. Det finnes imidlertid unntak fra denne regelen. For eksempel lagrer oppstartslasteren til samme Rockchip informasjon om partisjoner i den første blokken med NAND-minne, så det er ikke nødvendig å blinke oppstartslasteren for å endre den.

En del av oppstartslasterkoden som definerer partisjonstabellen


Den diverse delen er spesielt interessant. Det er en antagelse om at det opprinnelig ble opprettet for å lagre ulike innstillinger uavhengig av hovedsystemet, men for øyeblikket brukes det bare til ett formål: å indikere til oppstartslasteren fra hvilken partisjon systemet skal lastes - oppstart eller gjenoppretting. Spesielt denne funksjonen brukes av ROM Manager-applikasjonen for automatisk å starte systemet på nytt til gjenoppretting med automatisk installasjon av fastvaren. På grunnlag av det er Ubuntu Touch dual boot-mekanismen bygget, som flasher Ubuntu bootloader til gjenoppretting og lar deg kontrollere hvilket system som skal startes opp neste gang. Slettet misc-partisjonen - Android laster, fylte den med data - gjenopprettingslast... det vil si Ubuntu Touch.

Trinn to. Bootseksjon

Hvis div-delen ikke har et gjenopprettingsoppstartsflagg, overfører aboot kontrollen til koden som ligger i oppstartsdelen. Dette er ikke noe mer enn Linux-kjernen; den er plassert i begynnelsen av delen, og umiddelbart etterfulgt av et RAM-diskbilde pakket ved hjelp av cpio- og gzip-arkiver, som inneholder katalogene som er nødvendige for at Android skal fungere, initialiseringssystemet for init og andre verktøy. Det er ikke noe filsystem på oppstartspartisjonen; kjernen og RAM-disken følger ganske enkelt hverandre. Innholdet på RAM-disken er:

  • data - katalog for montering av partisjonen med samme navn;
  • dev - enhetsfiler;
  • proc - procfs er montert her;
  • res - et sett med bilder for laderen (se nedenfor);
  • sbin - et sett med verktøy og demoner (adbd, for eksempel);
  • sys - sysfs er montert her;
  • system - katalog for montering av systempartisjonen;
  • lader - applikasjon for å vise ladeprosessen;
  • build.prop - systeminnstillinger;
  • init - initialiseringssystem;
  • init.rc -er;
  • ueventd.rc - innstillinger for uventd-demonen inkludert i init.
Dette er så å si skjelettet til systemet: et sett med kataloger for tilkobling av filsystemer fra NAND-minnepartisjoner og et initialiseringssystem som skal håndtere resten av arbeidet med å starte opp systemet. Det sentrale elementet her er init-applikasjonen og dens init.rc-konfigurasjon, som jeg vil snakke om i detalj senere. I mellomtiden vil jeg gjøre deg oppmerksom på laderen og ueventd.rc-filene, samt sbin-, proc- og sys-katalogene.

Ladefilen er en liten applikasjon hvis eneste jobb er å vise batteriikonet på skjermen. Den har ingenting med Android å gjøre og brukes når enheten er koblet til laderen i av-tilstand. I dette tilfellet laster ikke Android, og systemet laster ganske enkelt inn kjernen, kobler til RAM-disken og starter laderen. Sistnevnte viser et batteriikon, hvis bilde i alle mulige tilstander er lagret i vanlige PNG-filer inne i res-katalogen.

Filen ueventd.rc er en konfigurasjon som bestemmer hvilke enhetsfiler i sys-katalogen som skal opprettes under systemoppstart. I systemer basert på Linux-kjernen utføres tilgang til maskinvare gjennom spesielle filer inne i dev-katalogen, og ueventd-demonen, som er en del av init, er ansvarlig for opprettelsen av dem i Android. I en normal situasjon fungerer den i automatisk modus, og aksepterer kommandoer for å lage filer fra kjernen, men noen filer må opprettes uavhengig. De er oppført i ueventd.rc.

sbin-katalogen på lager Android inneholder vanligvis ingenting bortsett fra adbd, det vil si ADB-daemonen, som er ansvarlig for å feilsøke systemet fra PC-en. Den kjører på et tidlig stadium av OS-oppstart og lar deg identifisere mulige problemer under OS-initialiseringsstadiet. I tilpassede firmwares kan du finne en haug med andre filer i denne katalogen, for eksempel mke2fs, som kan være nødvendig hvis partisjoner må omformateres til ext3/4. Moddere plasserer også ofte en BusyBox der, som du kan ringe hundrevis av Linux-kommandoer med.

Proc-katalogen er standard for Linux i de neste oppstartsfasene, init vil koble til den procfs, et virtuelt filsystem som gir tilgang til informasjon om alle prosesser på systemet. Systemet vil koble sysfs til sys-katalogen, som åpner tilgang til informasjon om maskinvaren og dens innstillinger. Ved å bruke sysfs kan du for eksempel sette enheten i dvale eller endre strømsparingsalgoritmen som brukes.

build.prop-filen er laget for å lagre Android-innstillinger på lavt nivå. Senere vil systemet tilbakestille disse innstillingene og overskrive dem med verdier fra den for øyeblikket utilgjengelige system/build.prop-filen.


Rotseksjon av OUYA TV set-top-boks


Trinn to, alternativ. Gjenopprettingsdelen

Hvis gjenopprettingsoppstartsflagget i div-delen er satt eller brukeren slår på smarttelefonen med volum ned-tasten holdt nede, vil aboot overføre kontrollen til koden som ligger i begynnelsen av gjenopprettingsdelen. I likhet med oppstartspartisjonen inneholder den kjernen og en RAM-disk, som pakkes ut i minnet og blir roten til filsystemet. Imidlertid er innholdet på RAM-disken noe annerledes her.

I motsetning til oppstartspartisjonen, som fungerer som en overgangskobling mellom ulike stadier av lasting av OS, er gjenopprettingspartisjonen helt selvforsynt og inneholder et miniatyroperativsystem som på ingen måte er forbundet med Android. Recovery har sin egen kjerne, sitt eget sett med applikasjoner (kommandoer) og sitt eget grensesnitt som lar brukeren aktivere tjenestefunksjoner.

I en standard (lager) gjenoppretting er det vanligvis bare tre slike funksjoner: installasjon av fastvare signert med nøkkelen til smarttelefonprodusenten, tørk og start på nytt. Modifiserte tredjepartsgjenopprettinger, som ClockworkMod og TWRP, har mye flere funksjoner. De kan formatere filsystemer, installere fastvare signert med alle nøkler (les: tilpasset), montere filsystemer på andre partisjoner (for OS-feilsøkingsformål) og inkludere skriptstøtte, som lar deg automatisere fastvareprosessen og mange andre funksjoner.

Ved å bruke skript, for eksempel, kan du sørge for at gjenoppretting etter oppstart automatisk finner den nødvendige fastvaren på minnekortet, installerer dem og starter på nytt i Android. Denne funksjonen brukes av ROM Manager, auto-flasher-verktøy, samt den automatiske oppdateringsmekanismen for CyanogenMod og annen fastvare.

Tilpasset gjenoppretting støtter også sikkerhetskopieringsskript som ligger i katalogen /system/addon.d/. Før flashing, ser gjenoppretting etter skript og kjører dem før fastvaren flashes. Takket være slike skript forsvinner ikke gapps etter installasjon av en ny fastvareversjon.

Trinn tre. Initialisering

Så, etter å ha mottatt kontroll, kobler kjernen RAM-disken og, etter initialisering av alle undersystemene og driverne, starter init-prosessen, som starter initialiseringen av Android. Som jeg allerede har sagt, har init en konfigurasjonsfil init.rc, hvorfra prosessen lærer nøyaktig hva den må gjøre for å få systemet opp. I moderne smarttelefoner har denne konfigurasjonen en imponerende lengde på flere hundre linjer og er også utstyrt med en tilhenger av flere barnekonfigurasjoner som er koblet til hovedkonfigurasjonen ved hjelp av importdirektivet. Imidlertid er formatet ganske enkelt og er egentlig et sett med kommandoer delt inn i blokker.

Hver blokk definerer et lastestadium eller, på Android-utviklerspråk, en handling. Blokker er atskilt fra hverandre med et on-direktiv etterfulgt av handlingsnavnet, for eksempel på early-init eller på post-fs. Blokken med kommandoer vil bare bli utført hvis utløseren med samme navn utløses. Når den starter, vil init aktivere early-init, init, early-fs, fs, post-fs, early-boot og boot-utløsere etter tur, og dermed starte de tilsvarende kommandoblokkene.


En del av init.rc-konfigurasjonen fra CyanogenMod


Hvis konfigurasjonsfilen trekker sammen flere konfigurasjoner som er oppført i begynnelsen (og dette er nesten alltid tilfellet), vil kommandoblokkene med samme navn i dem bli kombinert med hovedkonfigurasjonen, slik at når utløseren utløses, vil init utfør kommandoer fra de tilsvarende blokkene i alle filene. Dette gjøres for å gjøre det enklere å lage konfigurasjonsfiler for flere enheter, når hovedkonfigurasjonen inneholder kommandoer som er felles for alle enheter, og de spesifikke for hver enhet er skrevet i separate filer.

Den mest bemerkelsesverdige av de ekstra konfigurasjonene heter initrc.device_name.rc, der enhetsnavnet bestemmes automatisk basert på innholdet i ro.hardware-systemvariabelen. Dette er en plattformspesifikk konfigurasjonsfil som inneholder enhetsspesifikke kommandoblokker. I tillegg til kommandoene som er ansvarlige for å justere kjernen, inneholder den også noe som dette:

Kode:

Mount_all ./fstab.device_name

Det betyr at init nå skal montere alle filsystemer som er oppført i filen ./fstab.device_name, som har følgende struktur:

Kode:

Device_name (partisjon) mount_point file_system fs_options andre alternativer

Den inneholder vanligvis instruksjoner for montering av filsystemer fra interne NAND-partisjoner til katalogene /system (OS), /data (applikasjonsinnstillinger) og /cache (bufrede data). Ved å endre denne filen litt, kan vi imidlertid tvinge init til å starte opp systemet fra minnekortet. For å gjøre dette, del bare minnekortet i tre 4 seksjoner: 1 GB / ext4, 2 GB / ext4, 1 GB / ext4 og den gjenværende fat32-plassen. Deretter må du bestemme navnene på minnekortpartisjonene i /dev-katalogen (de er forskjellige for forskjellige enheter) og erstatte dem med de originale enhetsnavnene i fstab-filen.


Typisk fstab-filinnhold


På slutten av boot init-blokken vil den mest sannsynlig møte standardkommandoen class_start, som vil informere deg om at du da bør starte alle tjenestene som er oppført i konfigurasjonen som er relatert til standardklassen. Beskrivelsen av tjenester begynner med tjenestedirektivet, etterfulgt av navnet på tjenesten og kommandoen som må utføres for å starte den. I motsetning til kommandoene som er oppført i blokkene, må tjenester kjøres hele tiden, så gjennom hele smarttelefonens levetid vil init henge i bakgrunnen og overvåke dette.

Moderne Android inkluderer dusinvis av tjenester, men to av dem har en spesiell status og bestemmer hele livssyklusen til systemet.

Trinn fire. Zygote og app_process

På et visst stadium av lasting vil init møte på slutten av konfigurasjonen noe sånt som denne blokken:

Kode:

Tjeneste zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server class standard socket zygote stream 660 rotsystem onrestart skriv /sys/android_power/request_state våkne ved restart skriv /sys/power/state on onrestart restart media onrestart restart netd

Dette er en beskrivelse av Zygote-tjenesten, en nøkkelkomponent i ethvert Android-system som er ansvarlig for initialisering, start av systemtjenester, start og stopp av brukerapplikasjoner og mange andre oppgaver. Zygote lanseres ved hjelp av en liten applikasjon /system/bin/app_process, som er veldig tydelig synlig i ovenstående del av konfigurasjonen. App_proccess-oppgaven er å starte den virtuelle Dalvik-maskinen, hvis kode er plassert i det delte biblioteket /system/lib/libandroid_runtime.so, og deretter kjøre Zygote på toppen av den.

Når alt dette er gjort og Zygote har kontroll, begynner den å bygge Java-applikasjonens kjøretid ved å laste inn alle rammeverkets Java-klasser (for tiden over 2000 av dem). Deretter starter den system_server, som inkluderer de fleste av systemtjenestene på høyt nivå (skrevet i Java), inkludert Window Manager, Status Bar, Package Manager og, viktigst av alt, Activity Manager, som i fremtiden vil være ansvarlig for å motta start og slutt signalapplikasjoner.

Etter dette åpner Zygote socket /dev/socket/zygote og går i dvale og venter på data. På dette tidspunktet sender den tidligere lanserte Activity Manager en kringkastingsintensjon Intent.CATEGORY_HOME for å finne applikasjonen som er ansvarlig for å lage skrivebordet og gir navnet sitt til Zygote via kontakten. Sistnevnte på sin side gafler og kjører applikasjonen på toppen av den virtuelle maskinen. Voila, vi har et skrivebord på skjermen vår, funnet av Activity Manager og lansert av Zygote, og en statuslinje lansert av system_server som en del av Status Bar-tjenesten. Etter å ha trykket på ikonet, vil skrivebordet sende en hensikt med navnet på denne applikasjonen, Activity Manager vil motta den og sende kommandoen for å starte applikasjonen til Zygote-demonen

Alt dette kan se litt forvirrende ut, men det viktigste er å huske tre enkle ting:

  • Android-oppstartsprosessen er delt inn i to viktige stadier: før Zygote og etter. Før du starter Zygote, initialiserer systemet OS-komponenter på lavt nivå. Dette er operasjoner som å koble til (montere) filsystemer, lansere lavnivåtjenester (for eksempel rild, som er ansvarlig for å jobbe med et GSM-modem, SurfaceFlinger, som styrer hva som vises på skjermen, vold, som styrer tilkoblet filsystemer). Når Zygote er lansert, begynner initialisering utelukkende på Java-komponenter, som utgjør 80 % av operativsystemet. Dette brukes spesielt av det velkjente Xposed-rammeverket, som, når det er installert, erstatter app_process med sin egen modifiserte versjon, som er i stand til å avskjære anrop fra alle Java-klasser og erstatte dem med andre. Dette er grunnen til at Xposed-moduler har så brede modifikasjonsmuligheter utseende og Android-adferd. Faktisk endrer de ikke noe i systemet, men tvinger det rett og slett til å bruke tredjepartskomponenter i stedet for sine egne.
  • Java-applikasjoner startes aldri fra bunnen av. Når Zygote mottar en forespørsel om å starte en applikasjon fra Activity Manager, starter den ikke en ny virtuell maskin, men bare gafler, det vil si kopierer seg selv og starter den på toppen av den mottatte kopien av den virtuelle maskinen riktig applikasjon. Dette operasjonsprinsippet gjør det for det første mulig å redusere minneforbruket til et minimum, siden Linux kopierer minne i kopi-på-skriv-modus under en gaffel (den nye prosessen refererer til minnet til den gamle), og for det andre for å øke hastigheten betydelig. opp lanseringen av applikasjonen: Fordeling av prosessen er mye raskere enn å starte en ny virtuell maskin og laste inn Java-klassene som applikasjonen trenger.
  • Android bruker intensjoner overalt. Android-komponenter bruker aldri direkte anrop til prosedyrer og klasser for å kommunisere med hverandre. I stedet brukes et meldingssystem (intents), som i tillegg til et høyt sikkerhetsnivå også gir mange andre godbiter, som for eksempel muligheten til å ringe en applikasjon uten å vite noe om den. Jeg skrev allerede ovenfor at for å starte skrivebordet, trenger systemet bare å sende intensjonen Intent.CATEGORY_HOME, som enhver applikasjon som er i stand til å utføre startfunksjonen vil svare på. "Del"-knappen fungerer på samme måte, som mange andre komponenter i systemet.

Hva er Android, og hvorfor trengs det? Mange nybegynnere, når de kjøper en moderne gadget, enten det er et nettbrett eller en smarttelefon, stiller et lignende spørsmål. Det er verdt å avklare situasjonen og fremheve noen av fordelene med denne plattformen.

Utseendehistorie

I dag er det mange enheter som kjører på Android-plattformen. Dette operativsystemet er designet for smarttelefoner og nettbrett, klokker og e-lesere, spillkonsoller og til og med Google-briller. Kanskje dukker det opp TV-er og biler med Android-støtte snart.

Historien om opprettelsen av OS begynte tilbake i 2003. På den tiden ble en liten organisasjon kalt Android inc grunnlagt. Grunnleggerne var Rich Miner, Chris White, Andy Rubin og Nick Sears. Allerede da var det noen utviklinger i gang som var planlagt implementert i det nye operativsystemet. Selskapet utførte sin virksomhet i strengeste hemmelighold.

Organisasjonen gikk snart tom for penger, og det var ingen betydelige prestasjoner innen OS-utvikling. På grunn av mangel på resultater kunne investorer ikke tiltrekkes. Etter en stund ble Google interessert i utviklingen. I 2005 ble selskapet eiendommen til søkegiganten.

Etter dette ble Open Handset Alliance Corporation grunnlagt. Det inkluderer ledende produsenter av mobile enheter. Android-plattformen ble først introdusert i 2007. Som du vet er den basert på Linux-kjernen. Den første versjonen av dette operativsystemet ble utgitt i 2008.

Hva er det

Android er operativsystemet som driver smarttelefoner, nettbrett og mange andre enheter. Takket være dette operativsystemet vil selv den rimeligste telefonen kunne få nye funksjoner. Systemet lar deg installere ulike nyttige programmer, som vil hjelpe deg å utnytte alle funksjonene til enheten fullt ut.

All nødvendig programvare kan lastes ned fra Play Market. Denne siden inneholder mer enn 700 tusen programmer. Et bredt utvalg lar deg finne alle applikasjoner du trenger. Ved å bruke operativsystemet kan du enkelt få tilgang til Internett, se videofiler, kommunisere via sosiale nettverk, lytt til musikk, ta bilder og legg dem umiddelbart ut på kontoen din, eller les e-bøker.

Det er verdt å merke seg at operativsystemet er helt gratis. Dessuten er den veldig enkel å bruke. Det vil ikke ta mye tid å forstå grensesnittet. Takket være alle fordelene har den blitt den mest utbredte i verden. I 2014 ble mer enn 86 % av enhetene som opererer på denne plattformen solgt.

Video: Android-telefon

OS-applikasjon

Siden Android-operativsystemet kom frem til i dag, har ikke utviklerne sittet stille. Plattformen blir stadig forbedret. Samtidig utvides funksjonaliteten ved å introdusere nye funksjoner.

Foto: Android 4.0 er siste mobilversjon

Plattformen har blitt så populær og behagelig å bruke at mange selskaper som utvikler moderne gadgets har bestemt seg for å gi ut enhetene sine basert på dette OS.

Å bruke Android er ikke så vanskelig som det ser ut til. Med dens hjelp kan du utføre nesten de samme handlingene på enheten som på datamaskinen.

Systemet gir flere standardapplikasjoner. Blant dem er:

  • nettleser;
  • e-post;
  • kalender;
  • stemmesøk;
  • sosiale nettverk;
  • navigator;
  • vær;
  • nyheter.

Alle applikasjoner fra Google.

Et annet fint pluss er muligheten til å tilpasse skrivebordet selv. Du kan legge til en ekstra skjerm på enheten din der du kan plassere snarveier eller widgets. Du kan også installere hvilket som helst tema eller bakgrunnsbilde du liker, og dermed endre grensesnittet.

Hvorfor er det bra

Dette operativsystemet har en rekke fordeler. De viktigste er:


Stadier av Android-utvikling

Etter presentasjonen av den første versjonen av plattformen ble den foredlet i løpet av det neste året, som et resultat av at noen systemfeil ble rettet.

Fem oppdaterte versjoner ble introdusert i 2009:


2010 ble preget av utgivelsen av ytterligere to versjoner. De ble:


Den neste utviklingen av produsentene var plattform 3.0, som ble presentert i 2011. Det nye operativsystemet ble spesielt utviklet for nettbrett.


Dette systemet skiller seg fra de forrige:
  • forbedret grensesnitt;
  • muligheten til å synkronisere koblinger med Google Chrome;
  • ekstern tastaturstøtte;
  • det er nå mulig å endre størrelsen på widgets på skjermen;
  • arbeid på en flerkjerneprosessor.

Utviklerne stoppet ikke der og laget Android 4.0, som ble kalt "Ice Cream Sandwich". Denne plattformen har blitt mer universell. Den kan brukes på både telefon og nettbrett.

Bilde: Android 4.0 «Ice Cream Sandwich»

OS har mange nye funksjoner og forbedringer:

  • Varslingspanelet er endret;
  • en måte å kontrollere Internett-trafikken på er lagt til;
  • en stemmedikteringsfunksjon har dukket opp;
  • stavekontrollsystem;
  • Kameraapplikasjonen er forbedret - en panoramamodus, ulike effekter og en bildestabilisator har dukket opp;
  • nettleseren har blitt oppdatert;
  • støtte for skjermbilder;
  • oppdatert sikkerhets- og gadgetbeskyttelsessystem.

Gjennom 2012 og 2013 jobbet produsentene med å utvikle Jelly Bean OS..

De neste versjonene var 4.1, 4.2, 4.3. De nye endringene påvirket hovedsakelig hastigheten på grensesnittet. Takket være ny utvikling har produktiviteten økt. Nå fungerer GPU og sentralprosessor parallelt.

Den oppdaterte versjonen av plattformen har:


På slutten av 2013 ble det kunngjort en ny Android-versjon 4.4 "Kitkat". Den nye plattformen er optimalisert for å kjøre på billigere enheter som har VÆR 512 MB.

Det er også noen endringer her:

  • Nå i smarttelefoner er kontakter som brukeren kommuniserer oftere med øverst på listen;
  • taleassistenten er alltid aktiv;
  • automatisk oppringer-ID;
  • undertekster vises nå i videospilleren;
  • filnedlasteren har et oppdatert design;
  • støtte for skrittellerapplikasjoner;
  • Mange feil og mangler er rettet.

Selskapets siste utvikling er versjon 5. Det nye operativsystemet heter «Lollipop». Hovedhøydepunktet var Materialdesignet, som utmerker seg ved sin allsidighet.

Konkurrenter

De viktigste konkurrentene som Android-plattformen må kjempe om håndflaten med er:

  • Apple iPhoneOS;
  • Microsoft Windows Mobile;
  • RIM BlackBerry OS;
  • Maemo/MeeGo;
  • Samsung Bada OS;
  • Palm webOS;
  • Symbian OS.

I dag har Android blitt den mest utbredte mobilplattformen i verden enn iOS. En presentasjon av det nye Ubuntu Phone OS er imidlertid planlagt snart. Kanskje det vil bli en annen seriøs konkurrent til Android.

Android-enheter

I 2008 ble den første enheten utgitt som kjørte på Android. Enheten ble utviklet av HTC. Det var en smarttelefon kalt HTC Dream. Etter dette uttrykte flere telefonprodusenter ønske om å produsere mobile enheter med støtte for dette operativsystemet.

Snart ble et nettbrett basert på Android-plattformen annonsert. I 2009 dukket det opp en fotoramme som kjører på dette operativsystemet på markedet. I tillegg, etter 2 år, utviklet Blue Sky-organisasjonen et nytt armbåndsur, som ble kalt i’m Watch. De støtter også dette systemet.

Kameraprodusenter bestemte seg også for å følge med og introduserte verdens første kamera som kjører på Android.

Det nye produktet ble utgitt av Nikon. I tillegg opererer spillkonsoller, e-bøker og mediespillere på denne plattformen. Det forventes at noen flere enheter vil dukke opp snart.

Med denne utviklingstakten vil Android-plattformen bli den absolutte lederen blant andre operativsystemer, og etterlate alle konkurrenter bak seg.