Hur man ändrar systemfilen till Android. Vilka mappar som inte kan raderas på Android, och vilka kan

Android innehåller ett stort antal kataloger, men frågan uppstår - vilka mappar kan raderas och vilka kan inte röras?

Läs artikeln innan du raderar mappar.

Den här artikeln är lämplig för alla märken som producerar Android 9/8/7/6-telefoner: Samsung, HTC, Lenovo, LG, Sony, ZTE, Huawei, Meizu, Fly, Alcatel, Xiaomi, Nokia och andra. Vi ansvarar inte för dina handlingar.

Vi ansvarar inte för dina handlingar.

Mappar Android

Listan över mappar kan variera beroende på Android-versionen. Vissa applikationer kan skapa sina egna kataloger i minnet - till exempel snabbmeddelanden. Men i allmänhet är listan över mappar i alla versioner av Android densamma, så du behöver bara veta vad som finns lagrat i dem.

• Cache - en mapp med tillfälliga uppdateringsfiler. Om du inte kommer att uppdatera systemet kan du ta bort det.
• data / app - installationsfiler för alla tredjepartsapplikationer. Om du inte använder dem kan du ta bort.
• data / data - inställningar, sparingar och annan serviceinformation som krävs för att applikationer ska fungera. Om du inte använder installerade program tar du bort katalogen.
• data / Urklipp - dataklippbord med de senaste skärmdumparna. Det rekommenderas inte att ta bort.
• data / dalvik-cache - cacheområde för en virtuell java-maskin som gör att telefonen kan köra APK-filer. Det är nödvändigt att rengöra filer regelbundet, men kan inte raderas. (Se)

En mängd dokument lagras i mappen Dokument. Om innehållet inte är av intresse, ta bort katalogen lugnt. Detsamma gäller Bluetooth-katalogen där filerna som tas emot med den här trådlösa tekniken finns.

Klicka för att förstora

DCIM-mappen lagrar foton som tagits med kameran. Om det inte finns några nödvändiga foton kan du säkert radera katalogen. Att ta bort mappar för bilder, bilder, Musi, Audio osv. Påverkar inte Android-funktionen.

Mappar som inte kan raderas

Det finns mappar i Android som inte kan raderas kategoriskt, eftersom utan dem kommer systemet inte att fungera korrekt. Kom ihåg dessa namn:

• efs - information om IMEI, Mac, Bluetooth och Wi-Fi.
• etc - konfigurationsfiler som används för att starta upp systemet och processerna för olika firmware.
• bibliotek som är nödvändiga för drift av program och moduler.
• mnt - bilder av monterade system.
• pro - nyckelinformation om det installerade systemet.
• sbin - körbara filer för alla program som är involverade i systemhantering.
• sys - systemkonfigurationen för tillfället.

Du kan inte i något fall ta bort systemmappen med alla kataloger som finns med i den. System är ryggraden i systemet, så om du tar bort data härifrån kommer du att blinka telefonen igen.

Borttagningsmetoder

För att radera systemmappar behöver du superanvändarrättigheter - root. Om du inte har dem kan du verkligen inte bryta Android. Om du måste, måste du vara extremt försiktig - att radera viktiga systemfiler leder till att du måste blixtar igen.

Om du räknat ut vilka mappar du säkert kan ta bort, fortsätt med att rengöra minnet med hjälp av standardfunktioner:

1. Öppna Android-huvudmenyn och starta filbläsaren (filhanteraren).
2.   som kan raderas. Klicka på den och håll fingret.
3. När menyn visas väljer du "Radera".

  Klicka för att förstora

Alternativet för en chef med flervalsstöd presenteras. Radera-knappen är i detta fall uppe till höger i form av en korgikon.

I standardfilhanteraren visas inte alla Android-filer och -mappar. Om du vill rengöra enhetens minne väl använder du ES Explorer eller en annan tredjepartsfilhanterare.

1. Starta ES Explorer.
2. Välj om du vill rengöra - Intern lagring eller ett minneskort.
3. Håll fingret i mappen du vill ta bort. När det är markerat börjar du välja andra filer och mappar.
4. När du har valt alla objekt som ska raderas klickar du på knappen "Radera" i den nedre menyn.

  Klicka för att förstora

Du kan inte använda filhanteraren på Android, utan bara ansluta telefonen till datorn genom att välja läge för mediaenhet, där du kan visa och ändra minnets innehåll.

Ibland passar vissa Android-applikationer inte användaren med något. Ett exempel är irriterande reklam. Och det händer på så sätt - alla är nöjda med programmet, men bara översättningen i det är antingen en kurva eller inte alls. Eller till exempel är programmet rättegång, men det finns inget sätt att få den fullständiga versionen. Hur gör man en skillnad?

införandet

I den här artikeln kommer vi att prata om hur man parser APK-paketet med applikationen, överväger dess interna struktur, demonterar och dekompilerar byte-koden och försöker också göra flera ändringar i applikationerna som kan ge oss den här eller den fördelen.

För att göra allt detta själv behöver du åtminstone grundläggande kunskaper om Java-språket, som används för att skriva Android-applikationer, och XML-språket, som används överallt i Android - från beskrivningen av själva applikationen och dess åtkomsträttigheter till lagring av raderna som kommer att visas på skärmen. Du behöver också förmågan att hantera specialiserad konsolprogramvara.

Så, vad är APK-paketet, där absolut all mjukvara för Android distribueras?

Dekompilera applikationer

I artikeln arbetade vi bara med demonterad applikationskod, men om du gör mer allvarliga ändringar av stora applikationer kommer det att vara mycket svårare att förstå smali-koden. Lyckligtvis kan vi dekompilera dexkoden till Java-kod, som, även om den inte är original och inte kompilerad tillbaka, är mycket lättare att läsa och förstå applikationslogiken. För att göra detta behöver vi två verktyg:

• dex2jar - översättare av Dalvik bytecode till JVM bytecode, baserad på vilken vi kan få Java-kod;
• jd-gui - själva dekompilatorn, så att du kan få läsbar Java-kod från JVM-bytekoden. Alternativt kan du använda Jad (www.varaneckas.com/jad); även om den är ganska gammal, genererar den i vissa fall mer läsbar kod än Jd-gui.

Använd dem enligt följande. Kör först dex2jar och ange sökvägen till apk-paketet som ett argument:

   % dex2jar.sh mail.apk

Som ett resultat kommer mail.jar Java-paketet att visas i den aktuella katalogen, som redan kan öppnas i jd-gui för att visa Java-kod.

Enhets APK-paket och deras kvitto

Android-applikationspaketet är faktiskt en vanlig ZIP-fil, som inte kräver några specialverktyg för att se och packa upp innehållet. Det räcker med att ha en arkivering - 7zip för Windows eller konsolpacka upp på Linux. Men detta är för omslaget. Vad är inuti? Inuti, i det allmänna fallet, har vi följande struktur:

• META-INF /  - innehåller ett digitalt certifikat för applikationen, certifierar dess skapare och kontrollsumma för paketfilerna;
• res / - olika resurser som applikationen använder i sitt arbete, till exempel bilder, deklarativ beskrivning av gränssnittet samt andra data;
• AndroidManifest.xml  - beskrivning av ansökan. Detta inkluderar till exempel en lista med nödvändiga behörigheter, den nödvändiga versionen av Android och den nödvändiga skärmupplösningen;
• classes.dex  - sammanställd applikationskod för den virtuella Dalvik-maskinen;
• resources.arsc - också resurser, men av en annan typ - i synnerhet strängar (ja, den här filen kan användas för Russification!).

De listade filer och kataloger är, om inte alla, kanske i de allra flesta APK: er. Det är dock värt att nämna några fler inte så vanliga filer / kataloger:

• tillgångar  - en analog resurs. Huvudskillnaden är att för att få tillgång till en resurs måste du känna till dess identifierare, men tillgångslistan kan erhållas dynamiskt med metoden AssetManager.list () i applikationskoden;
• lib  - Native Linux-bibliotek skrivna med NDK (Native Development Kit).

Den här katalogen används av speltillverkare och placerar spelmotorn skriven i C / C ++ där, såväl som skapare av högpresterande applikationer (till exempel Google Chrome). Vi räknade ut enheten. Men hur får man paketfilen för den intressanta ansökan? Eftersom det inte är möjligt att ta APK-filer från enheten utan root (de finns i katalogen / data / app), och rooting är inte alltid tillrådligt, finns det minst tre sätt att få applikationsfilen till datorn:

• aPK Downloader-förlängning för Chrome;
• real APK Leecher-app;
• olika filhosting och warezniki.

Vilken som ska användas är en fråga om smak; vi föredrar att använda separata applikationer, därför kommer vi att beskriva användningen av Real APK Leecher, särskilt eftersom det är skrivet i Java och följaktligen kommer att fungera även i Windows, även i nixer.

När du har startat programmet måste du fylla i tre fält: E-post, lösenord och enhets-ID - och välja ett språk. De två första är e-postmeddelandet och lösenordet för ditt Google-konto, som du använder på enheten. Den tredje är enhetsidentifieraren, och den kan erhållas genom att slå koden på uppringaren # #8255##   och sedan hitta raden Enhets-ID. När du fyller i måste du bara ange ID utan android-prefixet.

Efter att ha fyllt och sparat visas meddelandet "Fel vid anslutning till server" ofta. Det är inte relaterat till Google Play, så känn dig fri att ignorera det och leta efter paket som intresserar dig.

Visa och modifiera

Anta att du hittade ett paket du är intresserad av, laddade ner, packade ... och när du försöker visa en XML-fil är du förvånad över att filen inte är text. Hur dekompilera det och hur man arbetar med paket i allmänhet? Är det verkligen nödvändigt att installera SDK? Nej, SDK är inte nödvändigt alls. Faktum är att alla steg för att packa upp, ändra och packa APK-paket kräver följande verktyg:

• zIP arkiverare  för packning och packning;
• smali - Dalvik virtuell maskinbytekodmonterare / demonterare (code.google.com/p/smali);
• aapt  - ett verktyg för att packa resurser (som standard lagras resurser i binär form för att optimera applikationsprestanda). Det är en del av Android SDK, men kan erhållas separat;
• signer  - Ett verktyg för digital signering av ett modifierat paket (bit.ly/Rmrv4M).

Du kan använda alla dessa verktyg separat, men det är obekvämt, så det är bättre att använda en högre programvara baserad på deras grund. Om du arbetar på Linux eller Mac OS X finns det ett verktyg som heter apktool. Det låter dig packa upp resurser i sin ursprungliga form (inklusive binära XML- och arsc-filer), bygga om ett paket med modifierade resurser, men kan inte signera paket, så du måste köra signaturverktyget manuellt. Trots att verktyget är skriven i Java är installationen ganska icke-standard. Hämta först jarfilen själv:

   $ cd / tmp $ wget http://bit.ly/WC3OCz $ tar -xjf apktool1.5.1.tar.bz2

   $ wget http://bit.ly/WRjEc7 $ tar -xjf apktool-install-linux-r05-ibot.tar.bz2

   $ mv apktool.jar ~ / bin $ mv apktool-install-linux-r05-ibot / * ~ / bin $ export PATH \u003d ~ / bin: $ PATH

Om du arbetar i Windows så finns det för henne ett utmärkt verktyg som heter Virtual Ten Studio, som också samlar alla dessa verktyg (inklusive apktool själv), men istället för CLI-gränssnittet ger användaren ett intuitivt grafiskt gränssnitt som du kan utföra operationer med packa upp, demontera och dekompilera med några få klick. Detta verktyg är Donation-ware, det vill säga ibland visas fönster med ett erbjudande om att få en licens, men detta kan i slutändan tolereras. Det är meningsfullt att beskriva det, eftersom du kan räkna ut gränssnittet på några minuter. Men apktool, på grund av dess konsolart, bör diskuteras mer detaljerat.

Överväg alternativet apktool. Kort sagt, det finns tre huvudkommandon: d (avkoda), b (build) och if (installera ramverk). Om allt är klart med de två första kommandona, vad gör då den tredje villkorade operatören? Den packar upp det angivna UI-ramverket, vilket är nödvändigt i de fall när du förbereder något systempaket.

Tänk på de mest intressanta alternativen för det första kommandot:

• -s  - demontera inte dex-filer;
• -r  - packa inte upp resurser;
• -b  - inte infoga felsökningsinformation i resultaten av demontering av dex-filen;
• -frame-path - använd det angivna UI-ramverket istället för den inbyggda apktolen. Överväg nu ett par alternativ för kommando b:
• -f  - tvingad montering utan att kontrollera förändringar;
• -a  - ange sökvägen till aapt (ett verktyg för montering av APK-arkivet), om du av någon anledning vill använda den från en annan källa.

Att använda apktool är mycket enkelt, ange bara en av kommandona och sökvägen till APK, till exempel:

   $ apktool d mail.apk

Efter det kommer alla extraherade och demonterade paketfiler att visas i e-postkatalogen.

Dissection. Inaktivera annonser

Teorin är naturligtvis bra, men varför behövs den om vi inte vet vad vi ska göra med paketet? Låt oss försöka tillämpa teorin till förmån för oss själva, nämligen att vi modifierar viss mjukvara så att den inte visar oss reklam. Låt det till exempel vara Virtual Torch - en virtuell fackla. För oss är den här programvaran idealisk eftersom den är full av irriterande annonser och också tillräckligt enkel för att inte gå vilse i koden.

Så ladda ner applikationen med hjälp av någon av ovanstående metoder. Om du bestämmer dig för att använda Virtuous Ten Studio, öppnar du bara APK-filen i applikationen och packar upp den, för vilken du skapar ett projekt (File -\u003e New project) och väljer sedan Import File i projektets sammanhangsmeny. Om ditt val föll på apktool, kör bara ett kommando:

   $ apktool d com.kauf.particle.virtualtorch.apk

Därefter visas ett filträd i katalogen com.kauf.particle.virtualtorch, liknande det som beskrivs i föregående avsnitt, men med en ytterligare smali-katalog istället för dex-filer och apktool.yml-filen. Den första innehåller den demonterade koden för programmets körbara dex-fil, den andra innehåller den serviceinformation som behövs av apktool för att bygga tillbaka paketet.

Det första vi borde se är naturligtvis AndroidManifest.xml. Och här möter vi omedelbart följande rad:

Det är lätt att gissa att hon är ansvarig för att tillhandahålla applikationen behörighet att använda Internet-anslutningen. I själva verket, om vi bara vill bli av med reklam, är det troligt nog att vi kommer att förbjuda internetapplikationen. Försök göra det. Ta bort den angivna raden och försök att bygga programvaran med apktool:

   $ apktool b com.kauf.particle.virtualtorch

Den resulterande APK-filen visas i com.kauf.particle.virtualtorch / build / katalogen. Men det kan inte installeras eftersom det inte har en digital signatur och kontrollsumma för filer (den har helt enkelt inte en META-INF / katalog). Vi måste skriva under paketet med hjälp av apk-signer-verktyget. Lanseras. Gränssnittet består av två flikar - på den första (Key Generator) skapar vi nycklar, på den andra (APK Signer) vi signerar. Fyll i följande fält för att skapa vår privata nyckel:

• Målfil  - Utdatafilen för keystore; det lagrar vanligtvis ett nyckelpar;
• lösenord  och Bekräfta  - lösenord för valvet;
• alias  - namnet på nyckeln i förvaret;
• Alias \u200b\u200blösenord  och Bekräfta  - lösenord för hemligt nyckel;
• giltighet  - giltighetstid (i år). Standardvärdet är optimalt.

De återstående fälten är i allmänhet valfria - men du måste fylla i minst ett.

VARNING

För att signera applikationen med apk-signer måste du installera Android SDK och ange hela sökvägen till den i applikationsinställningarna.

All information tillhandahålls endast för informationsändamål. Varken redaktörerna eller författaren är ansvariga för eventuella skador orsakade av materialen i denna artikel.

Nu kan du signera APK med den här knappen. På fliken APK Signer, välj den just genererade filen, ange lösenordet, nyckelaliaset och lösenordet för den, leta sedan efter APK-filen och klicka med fet stil på knappen "Sign". Om allt går bra kommer paketet att undertecknas.

INFO

Eftersom vi signerade paketet med vår egen nyckel kommer det att komma i konflikt med den ursprungliga applikationen, vilket innebär att när vi försöker uppdatera programvaran genom marknaden kommer vi att få ett fel.

Digital signatur är bara nödvändig för tredjepartsprogramvara, så om du är involverad i att ändra systemapplikationer som installeras genom att kopiera till / system / app / katalogen, behöver du inte underteckna dem.

Efter det släpper vi paketet på smarttelefonen, installerar och startar. Voila, annonsen är borta! Istället dök dock upp ett meddelande om att vi inte hade Internet eller att det inte fanns motsvarande behörigheter. I teorin kan detta vara tillräckligt, men meddelandet ser irriterande ut och för att vara ärlig hade vi bara tur med en dum ansökan. En normalt skriven programvara kommer sannolikt att klargöra sina referenser eller kontrollera tillgängligheten för en Internet-anslutning och annars vägrar den helt enkelt att starta. Vad ska man göra i det här fallet? Naturligtvis redigera koden.

Vanligtvis skapar applikationsförfattare specialklasser för att visa annonser och samtalsmetoder för dessa klasser under applikationsstart eller en av dess ”aktiviteter” (med andra ord applikationsskärmar). Låt oss försöka hitta dessa klasser. Vi går till smali-katalogen, sedan com (i org finns det bara det öppna grafiska biblioteket cocos2d), sedan kauf (där, för det här är namnet på utvecklaren och all hans kod finns där) - och här är det marknadsföringskatalogen. Inuti hittar vi ett gäng filer med smali-förlängningen. Dessa är klasser, och den mest anmärkningsvärda av dem är klassen Ad.smali, med namnet som det är lätt att gissa vad exakt den visar annonser.

Vi kan ändra logiken i dess arbete, men det skulle vara mycket enklare att dumt ta bort samtal från någon av dess metoder från själva applikationen. Därför lämnar vi marknadsföringskatalogen och går till den angränsande partikelkatalogen och sedan till virtualtorch. Speciellt här är filen MainActivity.smali. Detta är standardklassen Android som skapas av Android SDK och ställs in som startpunkt för applikationen (en analog av huvudfunktionen i C). Öppna filen för redigering.

Inuti är smali-koden (lokal montering). Det är ganska förvirrande och svårt att läsa på grund av dess låga nivå, så vi kommer inte att studera det, utan helt enkelt hitta alla referenser till annonsklassen i koden och kommentera dem. Vi kör i strängen "Annons" i sökningen och kommer till rad 25:

Fält privat annons: Lcom / kauf / marknadsföring / Annons;

Detta skapar ett annonsfält för att lagra ett objekt i klassannonsen. Vi kommenterar genom att sätta # -tecknet framför linjen. Vi fortsätter sökningen. Linje 423:

Nyinstans v3, Lcom / kauf / marketing / Ad;

Det är här skapandet av objektet äger rum. Kommentar. Vi fortsätter sökningen och hittar i raderna 433, 435, 466, 468, 738, 740, 800 och 802 samtal till metoder i annonsklassen. Kommentar. Gillar allt. Spara. Nu måste paketet monteras tillbaka och kontrolleras för dess funktionalitet och tillgängligheten för reklam. För experimentets renhet returnerar vi raden som tas bort från AndroidManifest.xml, samlar paketet, signerar och installerar.

  Vår experimentella kanin. Annonser synliga

Op-pa! Annonsering försvann bara medan applikationen kördes men förblev i huvudmenyn, som vi ser när vi startar programvaran. Så vänta, men posten är MainActivity-klassen, och annonsen försvann medan applikationen kördes, men stannade kvar i huvudmenyn, så posten är annorlunda? Öppna filen AndroidManifest.xml igen för att identifiera den riktiga posten. Och ja, det har följande rader:

De berättar för oss (och, ännu viktigare, android) att en aktivitet med namnet Start bör startas som svar på generering av avsikt (händelse) android.intent.action.MAIN från kategorin android.intent.category.LAUNCHER. Den här händelsen genereras när du trycker på applikationsikonen i startern, därför definierar den startpunkten, nämligen Start-klassen. Troligtvis skrev programmeraren först applikationen utan huvudmenyn, vars startpunkt var standardklassen MainActivity, och lägger sedan till ett nytt fönster (aktivitet) som innehåller menyn och beskrivs i Start-klassen och manuellt gjorde det till startpunkten.

Öppna filen Start.smali och leta igen efter raden "Annons". Vi hittar i raden 153 och 155 om FirstAd-klassen. Det finns också i källan och, med utgångspunkt i namnet, är det bara ansvaret för att visa annonser på huvudskärmen. Vi tittar vidare, vi skapar en instans av FirstAd-klassen och avsikten, som i sammanhang är relaterad till den här instansen, och sedan etiketten cond_10, den villkorliga övergången som görs exakt innan klassinstansen skapas:

If-ne p1, v0,: cond_10 .line 74 nyinstans v0, Landroid / content / Intent; ...: cond_10

Troligtvis beräknar programmet på något sätt slumpmässigt om det ska visas annonser på huvudskärmen och, om inte, hoppar det omedelbart till cond_10. Okej, vi förenklar uppgiften för henne och ersätter den villkorliga övergången med den ovillkorliga:

   # if-ne p1, v0,: cond_10 goto: cond_10

Det finns inga fler omnämnanden av FirstAd i koden, så stäng filen och sätt ihop vår virtuella fackla med apktool. Vi kopierar till smarttelefonen, installerar, startar. Voila, all reklam har försvunnit, och grattis till oss alla.

resultat

Den här artikeln är bara en kort introduktion till metoderna för att öppna och ändra Android-applikationer. Många frågor stannade kvar bakom kulisserna, såsom borttagning av skydd, analys av dold kod, översättning och utbyte av applikationsresurser och ändring av applikationer skrivna med Android NDK. Att ha grundläggande kunskap är att förstå allt detta bara en fråga om tid.

En av de mest intressanta säkerhetsmetoderna för Android-operativsystemet är tillståndssystemet ( behörigheter) som används av applikationer. När OS ANDROID just dök upp, kom dess utvecklare med - för att markera alla möjliga funktioner som applikationen behöver åtkomst till, och låta användaren kontrollera dem. Det genomfördes ganska intressant. Listan över möjliga behörigheter skapades av Google-utvecklare och registrerades i dokumentationen. Den är mycket flexibel, den har allt du behöver för att tillhandahålla alla typer av komplexa funktioner. Det är emellertid korrekt avgränsat.

Om programmet till exempel fungerar med SMS kan du ge det rättigheter bara att läsa meddelanden, eller bara att skicka dem, eller bara till en avisering om en händelse som är associerad med SMS. Denna distinktion undviker mycket väl missbruk av privilegier av applikationer. Till och med under skapandet av programmet väljer utvecklaren alla funktioner som hans program kommer att behöva. Den här listan är skriven i filen AndroidManifest.xml, som placeras i APK-filen vid programmontage. När användaren av Android-enheten installerar nästa applikation visas listan ovan som skapats av hans skapare på skärmen. Och först efter att användaren samtycker till att ge alla dessa rättigheter till den installerade applikationen kommer den att installeras. Det antas att det är i detta skede som de flesta användare kommer att undvika virus genom att misstänka programmet för dåligt beteende och avvisa installationen.

Från en teknisk synvinkel kan du förbi den befintliga mekanismen för applikationsåtkomsträttigheter till systemfunktionalitet android  mycket svårt. Eftersom behörigheter hanteras på den lägsta nivån av Linux-kärnan, behöver programmet definitivt roträttigheter för att påverka detta. Ett välformiserat tillståndssystem underlättar implementeringen av säkerhetsverktyg av tredje parts utvecklare. Ett lovande område är skapandet av program som gör det möjligt för användare att finjustera åtkomsträttigheterna för varje enskild applikation, vilket förhindrar informationsläckage från enheten.

Behörigheter för mappar och filer i Android

Åtkomsträttigheter  De är indelade i två grupper:
1.Rättigheter för åtkomst till filer
2. Rätten till mappen (katalog)

Åtkomsträttigheter  filer kan ha följande attribut:
r  - Rätten att läsa data. (Read)
w  - Rätten att ändra innehåll eller spela in, men inte radera. (Write)
x  - rätten att köra filen. (XXXXXX)

Åtkomsträttigheter  till mapp (katalog):
r  - rätten att läsa en mapp (katalog).
w  - Rätten att ändra innehållet i en katalog kan skapa och ta bort objekt i den här katalogen.
x - Rätten som låter dig gå in i katalogen.

Tillgångsrättigheterna är indelade i tre kategorier:
« användaren» - u  filägare.
« grupp» - g  En medlem i samma grupp som ägaren tillhör.
« värld» - o  alla andra.

Ordern för inspelning av åtkomsträttigheter:
första rättigheter för ägaren - " u»
sedan för gruppen - “ g»
och i slutet av lagen för alla andra - “ o»

Till exempel: antag att du har en dator på jobbet, du äger den, den finns i det lokala nätverket (grupp), och det finns användare som vill göra något på din dator. För alla dessa kategorier ställs rättigheter till filer och mappar i form av RWX som ger rättigheter att utföra något, om “-” -tecknet finns i RWX: s inställda rättigheter, betyder det att det inte finns någon rättighet.
Till exempel: rwx r-- r-- betyder att ägaren till filen har alla rättigheter: rätten att läsa, skriva till och köra, och att alla andra användare bara har rätt att läsa.

Förutom bokstavliga uttryck finns det numeriska uttryck:
r  - (läs) detta 4
w  (post) detta 2
x  (körning) är 1
« - "Gör ingenting, dvs. en bindestreck, 0
Och deras summa betyder slutliga rättigheter
7 (rwx) \u003d 4 + 2 +1 (fullständiga rättigheter)
5 (r-x) \u003d 4 + 0 + 1 (läs och kör)
6 (rw-) \u003d 4 + 2 + 0 (läs och skriv)
4 (r--) \u003d 4 + 0 + 0 (skrivskyddad)

Vanliga alternativ:
400   (-r --------) - ägaren har rätt att läsa, ingen utom honom har rätt att utföra några åtgärder.
644   (-rw-r - r--) - alla användare har läsbehörighet och ägaren kan redigera.
660   (-rw-rw ----) - ägaren och gruppen kan läsa och redigera, alla andra har inga rättigheter.
664   (-rw-rw-r--) - alla användare har läsbehörighet, och ägaren och gruppen kan redigera.
666   (-rw-rw-rw-) - alla användare kan läsa och redigera.
700   (-rwx ------) - ägaren kan läsa, skriva och köra för körning, andra har inte rätt att utföra några åtgärder.
744   (-rwxr - r--) - alla användare kan läsa, och ägaren har rätt att redigera och köra den.
755   (-rwxr-xr-x) - varje användare kan läsa och köra, ägaren kan redigera.
777   (-rwxrwxrwx) - varje användare kan läsa, redigera och köra.
sudo passwd root - root superuser lösenord.

Har du någonsin undrat hur fastboot eller ADB fungerar? Eller varför är det nästan omöjligt att förvandla en smartphone som kör Android till en tegel? Eller kanske har du länge velat veta var magin i Xposed-ramverket ligger och varför bootskript / system/etc/init.d behövs? Vad sägs om återställningskonsolen? Är den här delen av Android eller en sak i sig själv, och varför är normal återhämtning inte lämplig för att installera tredjeparts firmware? Du hittar svar på alla dessa och många andra frågor i den här artikeln.

Hur Android fungerar

Du kan lära dig om de dolda funktionerna i programvarusystem genom att förstå hur de fungerar. I vissa fall är det svårt att göra detta eftersom systemkoden kan vara stängd, men i fallet med Android kan vi undersöka hela systemet upp och ner. I den här artikeln kommer jag inte att prata om alla nyanser i Android och kommer bara att fokusera på hur OS startar och vilka händelser som sker mellan tryck på strömbrytaren och skrivbordets utseende.

Längs vägen kommer jag att förklara vad vi kan ändra i denna händelsekedja och hur utvecklare av anpassad firmware använder dessa funktioner för att implementera saker som att ställa in OS-parametrar, utöka lagringsutrymme för applikationer, ansluta byte, olika anpassningar och mycket mer. All denna information kan användas för att skapa din egen firmware och implementera olika hacks och modifieringar.

Första steget. ABOOT och partitionstabell

Allt börjar med bootloader. Efter att ha slagit på strömmen kör systemet startkodkoden som är inspelad i enhetens permanenta minne. Han överför sedan kontrollen till den starta startlasteren med inbyggt stöd för fastboot-protokollet, men tillverkaren av mobilchipet eller smarttelefonen / surfplattan har rätt att välja vilken annan bootloader som helst efter hans smak. Rockchip använder till exempel sin egen fastboot-inkompatibla bootloader, för vilken du måste använda proprietära verktyg för att omprogrammera och hantera.

Fastboot-protokollet är i sin tur ett bootloader-kontrollsystem från en dator som låter dig utföra åtgärder som att låsa upp bootloader, blinka en ny kärna och återställa, installera firmware och många andra. Betydelsen av förekomsten av fastboot är att kunna återställa smarttelefonen till sitt ursprungliga tillstånd i en situation där alla andra medel inte fungerar. Fastboot kommer att förbli på plats, även om du som ett resultat av experiment raderar från smarttelefonen alla delar av NAND-minne som innehåller Android och återhämtning.

Efter att ha fått kontrollen, kontrollerar abot partitionstabellen och överför kontrollen till kärnan som blinkade i den partition som heter boot, varefter kärnan extraherar RAM-bilden från samma partition i minnet och börjar ladda antingen Android eller återställningskonsolen. NAND-minne i Android-enheter är indelat i sex villkorliga obligatoriska avsnitt:

• start - innehåller kärnan och RAM-skivan, har vanligtvis en storlek i området 16 MB;
• återhämtning - återställningskonsol, består av en kärna, en uppsättning konsolapplikationer och en inställningsfil, storlek 16 MB;
• system - innehåller Android, i moderna enheter har en storlek på minst 1 GB;
• cache - utformad för att lagra cachad data, den används också för att spara firmware under OTA-uppdateringen och har därför en storlek som liknar storleken på systempartitionen;
• userdata - innehåller inställningar, applikationer och användardata, allt återstående NAND-minnesutrymme tilldelas det;
• misc - innehåller en flagga som avgör i vilket läge systemet ska starta: Android eller återhämtning.

Förutom dem kan andra avsnitt också existera, men den allmänna markeringen bestäms även i smarttelefonens designstadium och, om det är på gång, sys det in i startloader-koden. Detta innebär att: 1) partitionstabellen inte kan dödas, eftersom den alltid kan återställas med kommandot fastboot oem-format; 2) Om du vill ändra partitionstabellen måste du låsa upp och stänga om startladdaren med nya parametrar. Det finns dock undantag från denna regel. Till exempel lagrar bootloader för samma Rockchip partitionsinformationen i det första blocket av NAND-minne, så bootloadern behöver inte blinkas för att ändra den.

Särskilda avsnitt är särskilt intressant. Det finns ett antagande om att det ursprungligen skapades för att lagra olika inställningar oavsett huvudsystem, men för tillfället används det endast för ett syfte: att indikera för startlasteren från vilken partition systemet ska laddas - start eller återställning. Denna funktion används särskilt av ROM Manager-applikationen för att automatiskt starta om systemet till återhämtning med den automatiska installationen av firmware. På grundval av detta är Ubuntu Touch dual-boot-mekanismen byggd, som blinkar Ubuntu-startladdaren i återhämtning och gör att du kan kontrollera vilket system du vill ladda nästa gång. Raderade sektionen misc - den laddar Android, fyllde den med data - den laddar återhämtning ... det vill säga Ubuntu Touch.

Steg två Startsektion

Om startflaggan under återställning inte är inställd i misc-avsnittet, överförer man från kontrollen till koden som finns i startsektionen. Detta är ingenting annat än Linux-kärnan; den är placerad i början av avsnittet, och omedelbart efter det är en RAM-diskbild fullpackad med cpio- och gzip-arkiver som innehåller de kataloger som krävs för att Android ska fungera, initinitieringssystemet och andra verktyg. Det finns inget filsystem på startpartitionen, kärnan och RAM-skivan följer bara varandra. Innehållet på RAM-disken är:

• data - katalog för montering av partitionen med samma namn;
• dev - enhetsfiler;
• proc - procfs är monterad här;
• res - en uppsättning bilder för laddare (se nedan);
• sbin - en uppsättning verktygsverktyg och daemoner (till exempel adbd);
• sys - sysfs är monterad här;
• system - katalog för montering av systempartitionen;
• laddare - applikation för att visa laddningsprocessen;
• build.prop - systeminställningar;
• init - initieringssystem;
• init.rc - systeminställningar för initialisering;
• ueventd.rc - inställningar för uventd daemon, som är en del av init.

Detta är så att säga systemets skelett: en uppsättning kataloger för anslutning av filsystem från NAND-minnespartitioner och ett initieringssystem som gör allt resten av arbetet med att ladda systemet. Det centrala elementet här är init-applikationen och dess init.rc-konfigurering, som jag kommer att diskutera mer i detalj senare. Under tiden vill jag uppmärksamma laddnings- och ueventd.rc-filer, samt sbin-, proc- och sys-katalogerna.

Laddningsfilen är en liten applikation vars enda uppgift är att visa batteriikonen. Det har inget med Android att göra och används när enheten är ansluten till laddaren i off-läge. I det här fallet startar inte Android, och systemet laddar bara kärnan, ansluter RAM-skivan och startar laddaren. Den senare visar batteriikonen, vars bild lagras i vanliga PNG-filer i reskatalogen i alla möjliga tillstånd.

Ueventd.rc-filen är en konfigurering som definierar vilka enhetsfiler i sys-katalogen som ska skapas i systemstartsteget. I system baserade på Linux-kärnan är åtkomst till hårdvaran via specialfiler i dev-katalogen, och ueventd-demonen, som är en del av init, ansvarar för att skapa dem i Android. I en normal situation fungerar det i automatiskt läge och accepterar kommandon för att skapa filer från kärnan, men vissa filer måste skapas oberoende. De är listade i ueventd.rc.

Sbin-katalogen på lager Android innehåller vanligtvis inte annat än adbd, det vill säga ADB-demonen, som är ansvarig för felsökning av systemet från en PC. Det börjar i ett tidigt skede när du laddar OS och låter dig identifiera möjliga problem vid initieringsstadiet av operativsystemet. I anpassad firmware i den här katalogen kan du hitta ett gäng andra filer, till exempel mke2fs, som kan behövas om partitioner behöver omformateras till ext3 / 4. Modders lägger också ofta BusyBox, med vilken du kan ringa hundratals Linux-kommandon.

Linux proc-katalogen är standard, och i nästa startsteg kommer den att ansluta procfs till den, ett virtuellt filsystem som ger tillgång till information om alla systemprocesser. Systemet ansluter sysfs till sys-katalogen, som ger tillgång till information om hårdvaran och dess inställningar. Med hjälp av sysfs kan du till exempel skicka en enhet i vila eller ändra den energisparande algoritmen som används.

Filen build.prop är utformad för att lagra Android-inställningar på låg nivå. Senare återställer systemet dessa inställningar och skriver över dem med värden från systemet / build.prop-filen som ännu inte är tillgänglig.

Hämtningar från texten

• Fastboot förblir på plats även om du som ett resultat av experiment raderar innehållet i alla delar av NAND-minnet från din smartphone
• Återställningssektionen är helt fristående och innehåller ett miniatyroperativsystem som inte är anslutet till Android
• Genom att ändra fstab-filen något, kan vi tvinga init att starta upp systemet från minneskortet.

Steg två, alternativ. Återställningssektion

I händelse av att återställningsstartflaggan i misc-avsnittet är inställd eller användaren slår på smarttelefonen med volymknappen nedtryckt, kommer aboot att överföra kontrollen till koden som finns i början av återställningssektionen. Liksom startpartitionen innehåller den en kärna och en RAM-skiva som packas upp i minnet och blir roten till filsystemet. Men innehållet på RAM-disken är något annorlunda här.

Till skillnad från startsektionen, som fungerar som en övergångslänk mellan de olika stadierna för att ladda OS, är återvinningsavsnittet helt fristående och innehåller ett miniatyroperativsystem som inte är ansluten till Android på något sätt. Återställning har sin egen kärna, sin egen uppsättning applikationer (kommandon) och sitt eget gränssnitt, vilket gör att användaren kan aktivera verktygsfunktioner.

I standardåterhämtningen (lager) finns det vanligtvis bara tre sådana funktioner: installera firmware signerad av smartphonstillverkarens nyckel, torka och starta om. I modifierad återhämtning från tredje part, såsom ClockworkMod och TWRP, finns det mycket fler funktioner. De kan formatera filsystem, installera firmware signerad med valfria nycklar (läs: anpassad), montera filsystem på andra avsnitt (för felsökning av operativsystemet) och inkludera skriptstöd som låter dig automatisera firmwareprocessen och många andra funktioner.

Med exempelvis skript är det möjligt att göra återhämtning automatiskt ladda ner den nödvändiga firmware på minneskortet efter att ha laddats, installera dem och starta om till Android. Denna funktion används av ROM Manager, auto-flasher-verktyg samt den automatiska uppdateringsmekanismen för CyanogenMod och annan firmware.

Anpassad återställning stöder också säkerhetskopior som finns i katalogen /system/addon.d/. Innan du blinkar kontrollerar återställningen efter skript och körs innan du blinkar. Tack vare sådana skript försvinner inte gapp efter installation av en ny firmwareversion.

Fastboot-kommandon

För att komma åt fastboot måste du installera Android SDK, ansluta smarttelefonen till PC: n med en kabel och slå på den genom att hålla båda volymknapparna. Gå sedan till underkatalogen plattformverktyg i SDK och kör kommandot

Fastboot-enheter

Enhetsnamnet visas. Andra tillgängliga kommandon:

• fatsboot oem låser upp  - låsa upp bootloader i nexus;
• uppdatera file.zip  - installation av firmware;
• flash boot boot.img  - firmware image boot-partition;
• flash återhämtning.img  - firmware-bildåtervinningspartition;
• flash system system.img  - firmwarebild av systemet;
• oem-format  - återställande av det förstörda partitionstabellen;

Steg tre initiering

Så efter att ha fått kontrollen ansluter kärnan RAM-skivan och efter att initialiseringen av alla dess delsystem och drivrutiner har slutförts startar initprocessen, från vilken Android-initieringen börjar. Som jag sa, init har en init.rc-konfigurationsfil från vilken processen hittar exakt vad den behöver göra för att höja systemet. I moderna smartphones har denna konfiguration en imponerande längd på flera hundra rader och är också utrustad med en släpvagn från flera barnkonfigurer, som är anslutna till den viktigaste med importdirektivet. Ändå är dess format ganska enkelt och är i själva verket en uppsättning kommandon uppdelade i block.

Varje block bestämmer scenen för laddning eller, på Android-utvecklarens språk, en åtgärd. Block separeras av on-direktivet, följt av namnet på åtgärden, till exempel på early-init eller på post-fs. Kommandoblocket kommer att köras endast om utlösaren med samma namn fungerar. När det laddas kommer init att aktivera early-init, init, early-fs, fs, post-fs, early-boot och boot triggers i tur och ordning och därmed starta motsvarande kommandoblock.

Om konfigurationsfilen drar några fler konfigureringar som listas i början (och detta är nästan alltid fallet), kommer kommandoblocken med samma namn inuti dem att kombineras med huvudkonfigurationen, så att när utlösaren startar kommer init att utföra kommandon från motsvarande block för alla filer. Detta görs för att underlätta att generera konfigurationsfiler för flera enheter, när huvudkonfigurationen innehåller kommandon som är gemensamma för alla enheter och specifika enheter skrivs till separata filer.

Den mest anmärkningsvärda ytterligare konfigurationen heter initrc.device_name.rc, där enhetsnamnet bestäms automatiskt baserat på innehållet i systemvariabeln ro.hardware. Detta är en plattformsspecifik konfigurationsfil som innehåller enhetsspecifika instruktionsblock. Förutom de kommandon som är ansvariga för att ställa in kärnan, innehåller den också något liknande det här kommandot:

Mount_all ./fstab.device_name

Det betyder att nu bör den ansluta alla filsystem som finns i filen ./fstab.device_name, som har följande struktur:

Enhetsnamn (avsnitt) mount_point file_system options_fs andra alternativ

Vanligtvis innehåller instruktioner för anslutning av filsystem från interna NAND-partitioner till / system (OS), / data (applikationsinställningar) och / cache (cache-data). Genom att ändra den här filen kan vi dock tvinga init att starta upp systemet från minneskortet. För att göra detta, dela bara minneskortet i tre fyra sektioner: 1 GB / ext4, 2 GB / ext4, 1 GB / ext4 och det återstående utrymmet fat32. Därefter måste du bestämma partitionsnamnen på minneskortet i / dev-katalogen (de skiljer sig åt för olika enheter) och ersätta de ursprungliga enhetsnamnen i fstab-filen med dem.

I slutet av startinit-blocket är det troligt att det kommer att stöta på standardkommandot class_start, vilket kommer att informera dig om att alla tjänster som listas i konfigurationsfilen relaterade till standardklassen senare bör startas. Beskrivningen av tjänster börjar med servicedirektivet, följt av namnet på tjänsten och kommandot som måste utföras för att starta den. Till skillnad från de kommandon som anges i blocken, bör tjänsterna fungera hela tiden, så hela smarttelefonens liv kommer att hänga i bakgrunden och övervaka detta.

Modern Android innehåller dussintals tjänster, men två av dem har en speciell status och bestämmer hela livscykeln för systemet.

Init.rc-kommandon

Init-processen har en inbyggd kommandouppsättning, av vilka många upprepar standard Linux-kommandoset. Den mest anmärkningsvärda av dem:

• exec / path / to / kommandon  - köra ett externt kommando;
• ifup-gränssnitt  - höja nätverksgränssnittet;
• class_start class_name  - starta tjänster relaterade till den angivna klassen;
• klass_stopp klassnamn  - stoppa tjänsten;
• insmod / path / to / module  - ladda kärnmodulen;
• montera FS-enhetskatalog  - anslut filsystemet;
• setprop namnvärde  - ställa in systemvariabeln;
• starta servicenamn  - starta den angivna tjänsten;
• trigger name  - aktivera avtryckaren (kör det specificerade kommandoblocket);
• skriv / sökväg / till / filsträng  - skriv en sträng till en fil.

Steg fyra Zygote och app_process

I ett visst skede av lastning kommer init att möta i slutet av konfigurationen något liknande:

Service zygote / system / bin / app_process -Xzygote / system / bin --zygote --start-system-server klass standard socket zygote stream 660 root system onrestart skriva / sys / android_power / request_state wake onrestart skriva / sys / power / state on onrestart starta om media onrestart starta om netd

Detta är en beskrivning av Zygote-tjänsten, en nyckelkomponent i alla Android-system som ansvarar för initialisering, start av systemtjänster, start och stopp av användarapplikationer och många andra uppgifter. Zygote startas med hjälp av den lilla applikationen / systemet / bin / app_process, som är mycket tydligt synligt i ovanstående stycke i config. Uppgiften med app_proccess är att starta den virtuella Dalvik-maskinen, vars kod finns i det delade biblioteket / systemet/lib/libandroid_runtime.so, och sedan köra Zygote ovanpå den.

När allt detta är gjort och Zygote får kontroll börjar det skapa en runtime-miljö för Java-applikationer genom att ladda alla Java-klasser i ramverket (det finns nu mer än 2000). Sedan startar han system_server, som innehåller de flesta av de höga (skrivna i Java) systemtjänsterna, inklusive Window Manager, Status Bar, Package Manager och, viktigast av allt, Activity Manager, som kommer att ansvara för att ta emot start- och slutsignaler i framtiden tillämpningar.

Därefter öppnar Zygote / dev / socket / zygote-uttaget och går i sömn och väntar på data. För närvarande skickar den tidigare lanserade Aktivitetshanteraren en sändningsintention. CATEGORY_HOME för att hitta applikationen som är ansvarig för att skapa skrivbordet och ger sitt namn till Zygote genom uttaget. Den senare gafflar i sin tur och lanserar applikationen ovanpå den virtuella maskinen. Voila, på vår skärm visas skrivbordet som hittades av Activity Manager och lanseras av Zygote, och statusfältet som system_server lanserade som en del av statusfältet. Efter ett tryck på ikonen kommer skrivbordet att skicka en avsikt med namnet på denna applikation, det accepteras av Activity Manager och skickar kommandot att starta applikationen till Zygote-demonen

INFO

I Linux-terminologi är en RAM-skiva en sorts virtuell hårddisk som endast finns i RAM. I den tidiga startfasen extraherar kärnan innehållet på disken från bilden och monteras som rotfilsystemet (rootfs).

Under startprocessen visar Android tre olika startskärmar: den första visas omedelbart efter att du har tryckt på strömknappen och blinkat in i Linux-kärnan, den andra visas i de tidiga stadierna av initialisering och skrivs till filen /initlogo.rle (nästan aldrig används idag), den senare startas med hjälp av bootanimation-applikationen och finns i filen /system/media/bootanimation.zip.

Förutom standardutlösare ger init dig möjlighet att definiera dina egna triggers som kan utlösa från olika händelser: ansluta enheten till USB, ändra tillståndet för en smartphone eller ändra tillståndet för systemvariabler.

Activity Manager är bland annat involverat i att döda bakgrundsapplikationer utan minne. De fria minnesgränsvärdena finns i filen / sys / module / lowmemorykiller / parameters / minfree.

Allt detta kan se något obegripligt ut, men det viktigaste är att komma ihåg tre enkla saker:

På många sätt skiljer Android sig mycket från andra operativsystem, och du kan inte räkna ut det direkt. Men om du förstår hur allt fungerar öppnas helt enkelt obegränsade möjligheter. Till skillnad från iOS och Windows Phone har operativsystemet från Google en mycket flexibel arkitektur, som gör att du på allvar kan ändra dess beteende utan att behöva skriva kod. I de flesta fall räcker det med att korrigera nödvändiga konfigurationer och skript.

Ett av de populära operativsystemen i dag är Android. Det har installerats på miljoner mobila enheter. Systemet är en uppsättning mappar och filer som säkerställer att det fungerar. Men har du någonsin undrat vad som finns i varje mapp? Vissa har en ganska stor vikt, så handen och räcker ut för att ta bort dem. Innan du gör detta bör du definitivt bekanta dig med vad varje mapp är ansvarig för och hur viktigt det är för operativsystemet. Vi kommer också att berätta vad som är sätten att ta bort en onödig mapp.

De viktigaste nyckelkatalogerna i Android-operativsystemet

Den första uppgiften innan du tar bort är att ta reda på vad katalogen innehåller, eftersom det beror på detta om du kan ta bort den eller inte. Om du raderar viktiga filer av misstag kan du inte bara störa driften av alla applikationer utan också leda till hela operativsystemets fullständiga driftskompatibilitet.

  Det är värt att notera att listan över mappar kan variera beroende på enheten och versionen av Android-systemet. Specifika applikationer kan också skapa sina egna mappar i telefonminnet på Android. Låt oss överväga vilka kataloger som finns tillgängliga i Android.

Cache är en mapp för lagring av tillfälliga filer. Det kan innehålla en systemuppdatering. Om du inte ska uppgradera till en nyare version av Android behöver du inte en uppdateringsfil. Du kan ta bort den här mappen och i vissa fall till och med behöva.

Data är ett av de största katalogerna, som, som du kanske gissar från namnet, innehåller en mängd data. Detta inkluderar kontoinformation, information om sparade lösenord, Wi-Fi-åtkomstpunkter, etc. Eftersom den här mappen innehåller mycket information bör du tänka på dess underkataloger:

1. App - en katalog som innehåller installationsfilerna för olika applikationer. Det kan raderas om du inte behöver alla program nedladdade till din telefon;
2. Data - inkluderar inställningar, sparande och annan serviceinformation som är nödvändig för drift av specifika applikationer. Om det inte finns några data som är viktiga för dig i applikationer kan du också ta bort dem;
3. Urklipp är en speciell urklipp som också innehåller de senaste skärmdumparna. Du kan ta bort den här mappen, men den rekommenderas inte;
4. Dalvik-cache är cacheområdet för ett program som heter Davlink. Den här applikationen är en virtuell Java-maskin som gör att telefonen kan köra apk-filer för applikationer. För att påskynda denna process så mycket som möjligt skapas filer i cachen. Det rekommenderas att du regelbundet rengör innehållet, men du bör inte ta bort dalvik-cache.

Efs-mappen innehåller information om telefonens serienummer (IMEI), MAC-adress, Bluetooth och Wi-Fi. Den här katalogen kan inte raderas. Dessutom rekommenderas det att säkerhetskopiera den här mappen, eftersom att radera den leder till att ett unikt nummer förloras på din smartphone.

Katalog etc - innehåller konfigurationsfiler som huvudsakligen används under OS-laddning, processer för olika program, till exempel för att bestämma GPS-placering. Detta är ett av systemkatalogerna som inte kan raderas.

Lib-katalog - den innehåller olika bibliotek som är nödvändiga för att funktionerna av programfunktioner och moduler ska fungera korrekt. Dessutom innehåller den här mappen filer som innehåller drivrutiner. Du kan inte ta bort det.

Mnt-katalog - innehåller bilder av monterade system. Detta kan innehålla delar av det installerade minneskortet, internminnet eller andra virtuella enheter. Naturligtvis är det också omöjligt att ta bort den här katalogen.

Proc-mappen - den innehåller all nyckelinformation om det installerade Android OS: information om kärnan, konfigurationsparametrar och hårdvara. Alla tillgängliga filer och mappar är virtuella medan de väger noll byte. Systemet skapar dem automatiskt när användaren kommer åt dem. Den här mappen med normala användarrättigheter kan inte raderas.

Sbin-katalogen är en av de nyckelmappar som krävs för att telefonen ska fungera. Den innehåller körbara filer av alla program som är utformade för att styra systemet. Den kan inte raderas.

Sys-katalogen innehåller den nuvarande systemkonfigurationen. Detta är en dynamisk katalog. Informationen i den förändras ständigt. Du kan inte radera den här mappen.

Systemavsnittet är ryggraden i hela operativsystemet, eftersom det finns i det alla filer finns utan vilka Android inte kan fungera. Systemkatalogen (som alla andra interna kataloger) kan inte raderas. För granskning, överväga innehållet i denna katalog mer detaljerat:

1. App - systembakgrunder, standardapplikationer (kalender, anteckningsbok, SMS) finns i den här mappen.
2. Bin innehåller körbara filer och länkar;
3. Build.prop innehåller ett stort antal inställningar över telefonen, till exempel hur mycket sensorn försenas efter tryckning, vad är skärmdensiteten och mer;
4. Teckensnitt - information om alla aktieteckensnitt som stöds på telefonen.
5. Ramverk - allt som är nödvändigt för gränssnittet, särskilt ikoner, gardiner och andra grafiska element;
6. Lib - applikationsbibliotek;
7. Media - alla vanliga melodier och ljud (väckarklocka, SMS-varningar, samtalsmelodier);
8. Tts innehåller språkpaket.

Dokument - en mapp där olika dokument kan finnas, särskilt .doc- och .pdf-filer. Om innehållet i mappen inte intresserar dig kan du ta bort den.

Bluetooth - innehåller alla filer som har tagits emot av enheten via Bluetooth. Om det inte finns några viktiga data i den raderas de utan problem. Det kan placeras inte bara i det interna minnet utan också på SD-kortet.

DCIM är en speciell katalog för att spara foton skapade med kameran på din smartphone. Som regel innehåller det kamerasektionen, där alla foton finns. Om det inte finns några foton som behövs för dig i telefonen kan de raderas. Avsnitt som Bilder, Bilder, Ljud, Musik (i avsaknad av viktiga filer inuti) kan också raderas.

Borttagningsmetoder

Hur kan jag ta bort en specifik mapp? Det första sättet är att använda standardfunktionerna. För att göra detta måste du: