Desigur totul<теги>trebuie sa fie sau cam asa ceva, sau așa,<напрямую/>.

Uneori, unele aplicații de pe Android nu se potrivesc într-un fel utilizatorului. Un exemplu este publicitatea intruzivă. Și se întâmplă, de asemenea, că programul este bun pentru toată lumea, dar traducerea din el este fie strâmbă, fie complet absentă. Sau, de exemplu, programul este o versiune de încercare, dar nu există nicio modalitate de a obține versiunea completă. Cum să schimbi situația?

Introducere

În acest articol vom vorbi despre cum să dezasamblam un pachet APK cu o aplicație, să ne uităm la structura sa internă, să dezasamblam și să decompilăm bytecode și, de asemenea, vom încerca să facem mai multe modificări aplicațiilor care ne pot aduce un beneficiu sau altul.

Pentru a face toate acestea singur, veți avea nevoie de cel puțin cunoștințe de bază despre limbajul Java, în care sunt scrise aplicațiile Android, și limbajul XML, care este folosit peste tot în Android - de la descrierea aplicației în sine și drepturile sale de acces până la stocarea șirurilor care va fi afișat pe ecran. De asemenea, veți avea nevoie de capacitatea de a utiliza software specializat pentru consolă.

Deci, ce este un pachet APK în care este distribuit absolut tot software-ul Android?

Decompilarea aplicației

În acest articol, am lucrat doar cu codul de aplicație dezasamblat, dar dacă se fac modificări mai serioase aplicațiilor mari, înțelegerea codului smali va fi mult mai dificilă. Din fericire, putem decompila codul dex în cod Java, care, deși nu este original și nu este compilat înapoi, este mult mai ușor de citit și de înțeles logica aplicației. Pentru a face acest lucru, vom avea nevoie de două instrumente:

• dex2jar este un traducător al bytecode Dalvik în bytecode JVM, pe baza căruia putem obține cod în limbajul Java;
• jd-gui este un decompilator în sine care vă permite să obțineți cod Java lizibil din bytecode JVM. Ca alternativă, puteți utiliza Jad (www.varaneckas.com/jad); Deși este destul de vechi, în unele cazuri generează cod mai ușor de citit decât Jd-gui.

Așa ar trebui să fie folosite. Mai întâi, lansăm dex2jar, specificând calea către pachetul apk ca argument:

% dex2jar.sh mail.apk

Ca rezultat, pachetul Java mail.jar va apărea în directorul curent, care poate fi deja deschis în jd-gui pentru a vizualiza codul Java.

Aranjarea pachetelor APK și primirea acestora

Pachetul de aplicație Android este în esență un fișier ZIP obișnuit, nu este nevoie să vizualizați conținutul sau să îl dezarhivați. unelte speciale nu este necesar. Este suficient să aveți un arhivator - 7zip pentru Windows sau consola dezarhivare pe Linux. Dar asta e vorba de ambalaj. Ce e inauntru? În general, avem următoarea structură în interior:

• META-INF/- conține un certificat digital al aplicației, care identifică creatorul acesteia și sume de control ale fișierelor pachetului;
• res/ - diverse resurse, pe care aplicația le folosește în activitatea sa, de exemplu, imagini, descrierea declarativă a interfeței, precum și alte date;
• AndroidManifest.xml- descrierea aplicatiei. Aceasta include, de exemplu, o listă a permisiunilor necesare, versiunea Android necesară și rezoluția necesară a ecranului;
• clase.dex- codul octet al aplicației compilat pentru mașina virtuală Dalvik;
• resurse.arsc- de asemenea resurse, dar de alt fel - în special, șiruri (da, acest fișier poate fi folosit pentru rusificare!).

Fișierele și directoarele enumerate sunt, dacă nu în toate, atunci, poate, în marea majoritate a APK-urilor. Cu toate acestea, mai există câteva fișiere/directoare care nu sunt atât de comune care merită menționate:

• active- analog de resurse. Principala diferență este că pentru a accesa o resursă trebuie să cunoști identificatorul acesteia, dar lista de active poate fi obținută dinamic folosind metoda AssetManager.list() din codul aplicației;
• lib- biblioteci native Linux scrise folosind NDK (Native Development Kit).

Acest director este folosit de producătorii de jocuri, plasând acolo motorul de joc scris în C/C++, precum și de creatorii de aplicații de înaltă performanță (de exemplu, Google Chrome). Ne-am dat seama de dispozitiv. Dar cum obții fișierul pachet al aplicației care te interesează? Deoarece nu este posibil să ridicați fișiere APK de pe dispozitiv fără root (acestea sunt situate în directorul /data/app), iar rootarea nu este întotdeauna recomandabilă, există cel puțin trei moduri de a aduce fișierul aplicației pe computer:

• Extensie APK Downloader pentru Chrome;
• Aplicația Leecher APK reală;
• diverse găzduire de fișiere și Varezniks.

Care să folosești este o chestiune de gust; preferăm să folosim aplicații individuale, prin urmare, vom descrie utilizarea Real APK Leecher, mai ales că este scris în Java și, în consecință, va funcționa fie în Windows, fie în Nix.

După pornirea programului, trebuie să completați trei câmpuri: E-mail, Parolă și ID dispozitiv - și selectați o limbă. Primele două sunt adresa de e-mail și parola contului dvs. Google pe care le utilizați pe dispozitiv. Al treilea este identificatorul dispozitivului și poate fi obținut prin tastarea codului pe dialer # #8255## și apoi găsiți linia ID dispozitiv. Când completați, trebuie doar să introduceți ID-ul fără prefixul android.

După completare și salvare, apare adesea mesajul „Eroare la conectarea la server”. Nu are nimic de-a face cu Google Play, așa că nu ezitați să îl ignorați și să căutați pachete care vă interesează.

Vizualizați și modificați

Să presupunem că ați găsit un pachet care vă interesează, l-ați descărcat, l-ați despachetat... iar când ați încercat să vizualizați un fișier XML, ați fost surprins să descoperiți că fișierul nu era text. Cum să-l decompilați și cum să lucrați cu pachetele în general? Este cu adevărat necesar să instalați SDK-ul? Nu, nu este deloc necesar să instalați SDK-ul. De fapt, pentru toate etapele de despachetare, modificare și ambalare Pachete APK Sunt necesare următoarele instrumente:

• Arhivator ZIP pentru despachetare și ambalare;
• smali- mașină virtuală Dalvik bytecode assembler/disassembler (code.google.com/p/smali);
• apt- un instrument pentru ambalarea resurselor (în mod implicit, resursele sunt stocate în formă binară pentru a optimiza performanța aplicației). Inclus în Android SDK, dar poate fi obținut separat;
• semnatar- un instrument pentru semnarea digitală a unui pachet modificat (bit.ly/Rmrv4M).

Puteți utiliza toate aceste instrumente separat, dar acest lucru este incomod, deci este mai bine să utilizați software de nivel superior construit pe baza lor. Dacă lucrați pe Linux sau Mac OS X, există un instrument numit apktool. Vă permite să despachetați resurse în aspect original(inclusiv fișiere XML binare și arsc), reconstruiți pachetul cu resurse modificate, dar nu știe cum să semneze pachetele, așa că va trebui să rulați manual utilitarul de semnare. În ciuda faptului că utilitarul este scris în Java, instalarea sa este destul de nestandard. Mai întâi trebuie să obțineți fișierul jar în sine:

$ 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=~/bin:$PATH

Dacă lucrați pe Windows, atunci există un instrument excelent pentru acesta numit Virtuous Ten Studio, care acumulează și toate aceste instrumente (inclusiv apktool în sine), dar în loc de o interfață CLI oferă utilizatorului o interfață grafică intuitivă cu care puteți efectuați operațiuni de despachetare, dezasamblare și decompilare în câteva clicuri. Acest instrument este Donation-ware, adică uneori apar ferestre care vă cer să obțineți o licență, dar până la urmă acest lucru poate fi tolerat. Nu are rost să-l descrii, pentru că poți înțelege interfața în câteva minute. Dar apktool, datorită naturii sale de consolă, ar trebui discutat mai detaliat.

Să ne uităm la opțiunile apktool. Pe scurt, există trei comenzi de bază: d (decodificare), b (build) și if (install framework). Dacă totul este clar cu primele două comenzi, atunci ce face a treia declarație condiționată? Acesta despachetează cadrul specificat de UI, care este necesar în cazurile în care disecați orice pachet de sistem.

Să ne uităm la cele mai interesante opțiuni ale primei comenzi:

• -s- nu dezasamblați fișierele dex;
• -r- nu despachetați resurse;
• -b- nu introduceți informații de depanare în rezultatele dezasamblarii fișierului dex;
• --cadru-cadru- utilizați cadrul specificat de UI în loc de cel încorporat în apktool. Acum să ne uităm la câteva opțiuni pentru comanda b:
• -f- asamblare fortata fara verificarea modificarilor;
• -A- indicați calea către aapt (un instrument pentru construirea unei arhive APK), dacă dintr-un motiv oarecare doriți să o utilizați dintr-o altă sursă.

Utilizarea apktool este foarte simplă pentru a face acest lucru, trebuie doar să specificați una dintre comenzi și calea către APK, de exemplu:

$ apktool d mail.apk

După aceasta, toate fișierele extrase și dezasamblate ale pachetului vor apărea în directorul de e-mail.

Pregătirea. Dezactivarea publicității

Teoria este, desigur, bună, dar de ce este necesară dacă nu știm ce să facem cu pachetul despachetat? Să încercăm să aplicăm teoria în beneficiul nostru, și anume, să modificăm niște software pentru ca acesta să nu ne arate reclamă. De exemplu, să fie Virtual Torch - o torță virtuală. Acest software este ideal pentru noi, deoarece este plin de reclame enervante și, în plus, este suficient de simplu pentru a nu se pierde în jungla codului.

Deci, folosind una dintre metodele de mai sus, descărcați aplicația de pe piață. Dacă decideți să utilizați Virtuous Ten Studio, deschideți fișierul APK în aplicație și extrageți-l, pentru care creați un proiect (Fișier -> Proiect nou), apoi în meniul contextual proiect, selectați Import File. Dacă alegerea ta a căzut pe apktool, atunci rulează doar o comandă:

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

După aceasta, un arbore de fișiere similar cu cel descris în secțiunea anterioară va apărea în directorul com.kauf.particle.virtualtorch, dar cu un director smali suplimentar în loc de fișiere dex și un fișier apktool.yml. Primul conține codul dezasamblat al fișierului executabil dex al aplicației, cel de-al doilea conține informațiile de service necesare pentru ca apktool să asambla pachetul înapoi.

Primul loc pe care ar trebui să ne uităm este, desigur, AndroidManifest.xml. Și aici întâlnim imediat următoarea linie:

Nu este greu de ghicit că este responsabil pentru acordarea permisiunilor aplicației de a utiliza conexiunea la Internet. De fapt, dacă vrem doar să scăpăm de publicitate, cel mai probabil va trebui doar să blocăm aplicația de pe Internet. Să încercăm să facem asta. Ștergem linia specificată și încercăm să construim software-ul folosind apktool:

$ apktool b com.kauf.particle.virtualtorch

Fișierul APK rezultat va apărea în directorul com.kauf.particle.virtualtorch/build/. Totuși, nu va fi posibil să-l instalezi, deoarece nu are semnătură digitală și sume de verificare a fișierelor (pur și simplu nu are un director META-INF/). Trebuie să semnăm pachetul folosind utilitarul apk-signer. Lansat. Interfața este formată din două file - pe prima (Key Generator) creăm chei, pe a doua (APK Signer) semnăm. Pentru a ne crea cheie privată, completați următoarele câmpuri:

• Fișierul țintă- fișier de ieșire keystore; de obicei stochează o pereche de chei;
• ParolaȘi A confirma- parola pentru stocare;
• Alias- numele cheii din depozit;
• Parola aliasȘi A confirma- parola cheie secretă;
• Valabilitate- perioada de valabilitate (în ani). Valoarea implicită este optimă.

Câmpurile rămase sunt, în general, opționale - dar cel puțin unul trebuie completat.

AVERTIZARE

Pentru a semna o aplicație folosind apk-signer, trebuie să instalați Android SDK și să specificați drum completînainte de acesta în setările aplicației.

Toate informațiile sunt furnizate doar în scop informativ. Nici editorii, nici autorul nu sunt responsabili pentru niciuna posibil prejudiciu cauzate de materialele acestui articol.

Acum puteți semna APK-ul cu această cheie. În fila APK Signer, selectați fișierul nou generat, introduceți parola, aliasul cheii și parola pentru acesta, apoi găsiți fișier APKși cu îndrăzneală apasa butonul"Semn" Daca totul merge bine, pachetul va fi semnat.

INFO

Deoarece am semnat pachetul cu propria noastră cheie, acesta va intra în conflict cu aplicația originală, ceea ce înseamnă că atunci când vom încerca să actualizăm software-ul prin piață, vom primi o eroare.

Este necesară doar o semnătură digitală software terță parte, deci dacă faci modificări aplicații de sistem, care sunt instalate prin copierea în directorul /system/app/, nu trebuie să le semnați.

După aceea, descărcați pachetul pe smartphone, instalați-l și lansați-l. Voila, reclama a dispărut! În schimb, a apărut însă un mesaj că nu avem internet sau nu avem permisiunile corespunzătoare. În teorie, acest lucru ar putea fi suficient, dar mesajul pare enervant și, să fiu sincer, tocmai am avut noroc cu o aplicație stupidă. Cel mai probabil, software-ul scris în mod normal își va clarifica acreditările sau va verifica o conexiune la Internet și, în caz contrar, va refuza pur și simplu lansarea. Cum să fii în acest caz? Desigur, editați codul.

De obicei, autorii aplicației creează clase speciale pentru afișarea reclamelor și a metodelor de apel ale acestor clase atunci când aplicația sau una dintre „activitățile” acesteia (în termeni simpli, ecranele aplicației) este lansată. Să încercăm să găsim aceste clase. Mergem la directorul smali, apoi com (org conține doar biblioteca grafică deschisă cocos2d), apoi kauf (aici este, pentru că acesta este numele dezvoltatorului și tot codul său este acolo) - și aici este, directorul de marketing. În interior găsim o grămadă de fișiere cu extensia smali. Acestea sunt clase, iar cea mai notabilă dintre ele este clasa Ad.smali, după denumirea căreia este ușor de ghicit că este cea care afișează reclamă.

Am putea schimba logica funcționării acestuia, dar ar fi mult mai ușor să eliminați pur și simplu apelurile la oricare dintre metodele sale din aplicația în sine. Prin urmare, părăsim directorul de marketing și mergem la directorul de particule adiacent și apoi la virtualtorch. Atentie speciala Fișierul MainActivity.smali merită acest lucru. Acesta este standard pentru Clasa Android, care este creat de Android SDK și instalat ca punct de intrare în aplicație (analog cu funcția principală din C). Deschideți fișierul pentru editare.

Înăuntru există cod smali (asambler local). Este destul de confuz și dificil de citit din cauza naturii sale de nivel scăzut, așa că nu îl vom studia, ci pur și simplu vom găsi toate referințele la clasa Ad în cod și le vom comenta. Introducem linia „Ad” în căutare și ajungem la rândul 25:

Câmp anunț privat:Lcom/kauf/marketing/Ad;

Aici este creat un câmp de anunț pentru a stoca un obiect de clasă de anunțuri. Comentăm punând un semn ### în fața liniei. Continuăm căutarea. Linia 423:

Noua instanță v3, Lcom/kauf/marketing/Ad;

Aici are loc crearea obiectului. Hai sa comentam. Continuăm căutarea și găsim în rândurile 433, 435, 466, 468, 738, 740, 800 și 802 apeluri la metodele clasei Ad. Hai sa comentam. Arata ca asta e. Să salvăm. Acum pachetul trebuie pus la loc și verificat pentru funcționalitate și prezența reclamei. Pentru puritatea experimentului, returnăm linia eliminată din AndroidManifest.xml, asamblam pachetul, îl semnăm și îl instalăm.

Hopa! Publicitatea a dispărut doar în timp ce aplicația rula, dar a rămas în meniul principal, pe care îl vedem când lansăm software-ul. Așadar, așteptați, dar punctul de intrare este clasa MainActivity, iar reclama a dispărut în timp ce aplicația rula, dar a rămas în meniul principal, deci punctul de intrare este diferit? Pentru a identifica adevăratul punct de intrare, redeschideți fișierul AndroidManifest.xml. Și da, conține următoarele rânduri:

Ei ne spun (și, mai important, Android) că o activitate numită Start ar trebui să fie lansată ca răspuns la generarea unui intent (eveniment) android.intent.action.MAIN din categoria android.intent.category.LAUNCHER. Acest eveniment este generat atunci când atingeți pictograma aplicației din launcher, deci determină punctul de intrare, și anume clasa Start. Cel mai probabil, programatorul a scris mai întâi o aplicație fără meniu principal, punctul de intrare în care era clasa standard MainActivity, apoi a adăugat o nouă fereastră (activitate) care conține meniul și descrisă în clasa Start și a făcut-o manual intrarea. punct.

Deschideți fișierul Start.smali și căutați din nou linia „Ad”, găsim în rândurile 153 și 155 o mențiune a clasei FirstAd. Se află și în codul sursă și, judecând după nume, este responsabil pentru afișarea reclamelor pe ecranul principal. Să privim mai departe, există crearea unei instanțe a clasei FirstAd și o intenție care, după context, este legată de această instanță, iar apoi eticheta cond_10, a cărei tranziție condiționată se realizează exact înainte de a crea o instanță. din clasa:

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

Cel mai probabil, programul calculează cumva aleatoriu dacă publicitatea ar trebui să fie afișată pe ecranul principal și, dacă nu, sare direct la cond_10. Ok, să-i simplificăm sarcina și să înlocuim tranziția condiționată cu una necondiționată:

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

Nu mai există mențiuni despre FirstAd în cod, așa că închidem fișierul și reasamblam lanterna noastră virtuală folosind apktool. Copiați-l pe smartphone, instalați-l, lansați-l. Voila, toate reclamele au dispărut, pentru care ne felicităm pe toți.

Rezultate

Acest articol este doar o scurtă introducere în metodele de hacking și modificare a aplicațiilor Android. Multe probleme au rămas în spatele scenei, cum ar fi eliminarea protecției, analiza codului ofuscat, traducerea și înlocuirea resurselor aplicației, precum și modificarea aplicațiilor scrise folosind Android NDK. Cu toate acestea, având cunoștințe de bază, este doar o chestiune de timp să-ți dai seama de toate.

Ei bine, cartea lui Goloshchapov are și o descriere bună. Deoarece articolele pot dispărea online, aici voi face o compilație gratuită a tuturor surselor de mai sus. Și în același timp corectez inexactitățile. De la traducerea unor elemente (de exemplu ) Ei bine, în general, nu este nici măcar aproape de original. Practic, toate articolele sunt copy-paste și nu este clar cine a furat pe cine. Dar, într-un fel sau altul, practic descrierea acestui fișier și scopul său din aceste articole coincide cu originalul.
Fac asta ca un memento pentru mine și, dacă este util pentru altcineva, este bine.

Fișierul AndroidManifest.xml specifică configurația aplicației:

• declară numele pachetului Java al aplicației, care servește ca un identificator unic
• declară nivelurile API minime și maxime necesare pentru ca aplicația să funcționeze
• descrie componentele aplicației (Activiy, Service, Broadcast Receiver și Content Provider)
• listează orice biblioteci asociate cu aplicația (în afară de bibliotecile implicite Android)
• declară permisiunile necesare pentru ca aplicația să funcționeze (de exemplu, acces la rețea, permisiunea de a trimite SMS etc.)

Descrierea completă este în alma mater, dar o voi oferi și aici pentru o mai mare claritate.
. . . . . . . . .
Ordinea de aranjare a elementelor situate la același nivel este arbitrară. Toate valorile sunt stabilite prin atributele elementului. Elementul este elementul principal al manifestului și conține multe elemente copil care definesc structura și funcționarea aplicației. Elemente , Și sunt obligatorii. Alte elemente sunt opționale și sunt folosite în manifest dacă este necesar.

Element este elementul rădăcină al fișierului AndroidManifest.xml. În mod implicit, Expertul nou proiect Android din Eclipse creează acest element cu patru atribute:

Aceste atribute sunt necesare pentru orice aplicație Android și au următorul scop:

xmins:android— definește spațiul de nume Android. Această valoare este întotdeauna aceeași pentru toate aplicațiile.

pachet- Definește numele unic al pachetului de aplicație pe care l-ați specificat la crearea proiectului.

De ce trebuie să specificați pachetul? Dacă doriți să vă încărcați aplicația pe Google Play, aceasta verifică unicitatea atunci când acceptați aplicația, așa că este recomandat să vă folosiți numele pentru a evita conflictele cu alți dezvoltatori.

android:versionCode- în esență, aceasta este o versiune a aplicației dvs. Când lansați o nouă versiune, o indicați în acest câmp, trebuie să fie un număr întreg.

Mai sus am vorbit despre unicitatea pachetului, așa că dacă ați încărcat anterior aplicația pe Google Play, atunci când decideți să descărcați versiunea actualizată a aplicației, trebuie să respectați mai multe reguli. Numele pachetului trebuie să se potrivească cu ceea ce este deja descărcat de Google Play și să indice versiunea android:versionCode mult mai înalt. Dar aceasta este cu condiția să lansați o nouă versiune a aplicației dacă doriți să adăugați o versiune ușor corectată, apoi citiți mai jos;

Prin schimbare acest parametru iar prin încărcarea aplicației pe Google Play, tuturor utilizatorilor aplicației dumneavoastră li se va oferi să actualizeze noua versiune a aplicației.

android:versionName- indică numărul versiunii utilizatorului. Dacă ați găsit mai multe defecte în aplicația dvs. și le-ați corectat, atunci în acest caz puteți specifica o nouă versiune pentru acest câmp, care va spune Google Play că aceasta nu este o versiune nouă a aplicației, ci una îmbunătățită. Puteți folosi un șir sau o resursă șir pentru a denumi o versiune.

Prin modificarea acestui parametru și încărcarea aplicației pe Google Play, tuturor utilizatorilor aplicației dumneavoastră li se va oferi să actualizeze versiunea modificată a aplicației.

Element vă permite să solicitați permisiuni care trebuie acordate unei aplicații de către sistem pentru ca aceasta functionare normala.

Permisiunile sunt acordate în timpul instalării aplicației, nu în timp ce aplicația rulează. are un singur atribut numit permisiune android:nume. Aceasta ar putea fi o rezoluție definită pe element aceasta aplicație, o permisiune definită într-o altă aplicație sau una dintre permisiunile standard ale sistemului, de exemplu:

android:name=’android.permission.CAMERA’– acces la camera dispozitivului
android:name=’android.permission.READ_CONTACTS’– acces la baza de date de contacte

Element declară o permisiune care este utilizată pentru a restricționa accesul la anumite componente sau funcționalități ale unei anumite aplicații. Această secțiune descrie drepturile pe care alte aplicații trebuie să le solicite pentru a obține acces la aplicația dvs.

O aplicație își poate proteja propriile componente (Activitate, Serviciu, Receptor de difuzare și Furnizor de conținut) cu permisiuni. Poate folosi oricare dintre permisiunile de sistem definite de Android (listate în android.Manifest.permission) sau declarate de alte aplicații și își poate defini, de asemenea, propriile permisiuni. Noua permisiune trebuie declarată în atribut android:nume element in felul urmator:

permis android:name="com.samples.custom_permission”

În plus, sunt utilizate atribute suplimentare:

android:label— numele permisiunii afișat utilizatorului
android:descriere- descrierea permisiunii
android:pictogramă- pictograma permisiunii
android:permissionGroup— determină apartenența la un grup de permisiuni
android:protectionLevel— nivelul de protecție

Element declară numele de bază pentru arborele de permisiuni. Acest element nu declară permisiunea în sine, ci doar un spațiu de nume în care pot fi plasate alte permisiuni.

Element definește un nume pentru un set de permisiuni legate logic. Acestea pot fi ambele declarate în același manifest cu elementul Permisiuni așa cum sunt anunțate în altă parte. Acest element nu declară direct o permisiune, ci doar o categorie în care pot fi plasate permisiunile. O permisiune poate fi plasată într-un grup prin atribuirea numelui grupului în atribut permissionGroup element .

Element declară un obiect Instrumentation, care face posibilă controlul interacțiunii aplicației cu sistemul. Utilizat de obicei la depanarea și testarea unei aplicații și eliminat din versiunea de lansare a aplicației.

Element vă permite să declarați compatibilitatea unei aplicații cu o versiune specificată (sau versiuni API mai noi) Platforme Android. Nivelul API declarat de aplicație este comparat cu nivelul API al sistemului de dispozitiv mobil pe care este instalată aplicația.

Atributul principal utilizat într-un element este android:minSdkVersion, definește nivelul minim API necesar pentru ca aplicația să funcționeze. sistem Android va împiedica utilizatorul să instaleze aplicația dacă nivelul API al sistemului este mai mic decât valoarea definită în acest atribut. Este recomandabil să declarați întotdeauna acest atribut, de exemplu:

Atribut android:targetSdkVersion introdus începând cu API Level 4. Acesta este un număr întreg care indică nivelul API pentru care este destinată aplicația (țintă, ceea ce înseamnă scop). Dacă acest atribut nu este setat, valoarea sa implicită este minSdkVersion.

Acest atribut informează sistemul că ați testat aplicația cu acest nivel de API și că sistemul nu ar trebui să permită niciun comportament de compatibilitate, adică emularea apelurilor API care oferă suplimentar special. procesare software unele apeluri API) pentru a menține compatibilitatea directă a aplicației cu versiunea sistemului țintă. Aplicația poate rula în continuare pe versiuni mai vechi (până la versiuni nu mai puțin de minSdkVersion).

Pe măsură ce Android evoluează cu fiecare versiune nouă, un anumit comportament și chiar aspectul aplicației se pot schimba. Cu toate acestea, dacă nivelul API al platformei este mai mare decât versiunea specificată în targetSdkVersion a aplicației, sistemul poate activa comportamente de compatibilitate pentru a asigura că aplicația dumneavoastră funcționează conform așteptărilor. Puteți preveni o astfel de gestionare a compatibilității specificând targetSdkVersion egal cu nivelul API al platformei Android pe care rulează aplicația. De exemplu, setarea acestei valori la „11” sau mai mare va permite sistemului să seteze o nouă temă implicită (Holo) pentru aplicația dvs. atunci când rulați pe Android 3.0 sau o versiune ulterioară și, de asemenea, va dezactiva modul de compatibilitate cu ecranul atunci când programul rulează. ecrane mari(deoarece suportul API de nivel 11 implică implicit suport pentru ecrane mari).

Există multe comportamente de compatibilitate pe care sistemul le poate rezolva pe baza valorii acestui atribut. Unele dintre aceste comportamente sunt descrise în documentația relevantă a versiunii platformei, consultați Build.VERSION_CODES.

Pentru a vă asigura că aplicația dvs. respectă fiecare nouă lansare Android, trebuie să creșteți valoarea acestui atribut pentru a se potrivi cu cel mai recent nivel API, apoi trebuie să testați complet comportamentul aplicației pe acea nouă versiune a platformei.

Atribut android:maxSdkVersion introdus începând cu API Level 4. Acesta este un număr întreg care indică nivelul maxim API la care poate rula aplicația.

Pe versiunile Android 1.5, 1.6, 2.0 și 2.0.1, sistemul verifică valoarea acestui atribut atunci când aplicația este instalată și când aplicația este verificată pentru compatibilitate după o actualizare a sistemului. În orice caz, dacă atributul maxSdkVersion al aplicației este mai mic decât API-ul Nivel de sistem, atunci instalarea aplicației va fi interzisă. La verificarea compatibilității unei aplicații după o actualizare a sistemului, acest caz corespunde cu eliminarea completă a aplicației de pe dispozitiv. Pentru a ilustra modul în care acest atribut poate afecta o aplicație după o actualizare a sistemului, luați în considerare un exemplu.

Aplicația a declarat maxSdkVersion="5" în manifestul său și a fost publicată pe Google Play. Utilizator dispozitive Android 1.6 (API Level 4) a descărcat și instalat această aplicație. După câteva săptămâni, utilizatorul a primit un mesaj de la sistemul over-the-air cu o ofertă de actualizare a sistemului la Android 2.0 (API Level 5). După instalarea acestei actualizări, sistemul a verificat atributul maxSdkVersion al aplicației și a permis utilizarea în continuare a acestei aplicații. Aplicația a funcționat bine după aceea. Cu toate acestea, după ceva timp, dispozitivul a acceptat o altă actualizare de sistem Android 2.0.1 (API Level 6). După actualizare, sistemul nu permite rularea aplicației deoarece nivelul API al sistemului (6) este acum mai mare decât nivelul maxim pe care îl poate suporta aplicația (5). Sistemul face aplicația invizibilă pentru utilizator și o elimină de pe dispozitiv.

Avertisment: Utilizarea acestui atribut este depreciată. În primul rând, nu este nevoie să setați acest atribut ca mijloc de a bloca aplicația dvs. de a fi implementată pe versiuni noi ale platformei Android pe măsură ce acestea devin disponibile. Pentru Android, complet compatibilitate inversă aplicații vechi pentru versiuni noi de Android. Aplicația dvs. ar trebui să funcționeze corect pe toate versiunile noi, atâta timp cât utilizează numai API-ul standard și urmează cele mai bune reguli și practici de dezvoltare. În al doilea rând, trebuie să rețineți că utilizarea acestui atribut va duce la eliminarea automată a aplicației dvs. de pe dispozitivele utilizator care își actualizează sistemul la un nivel API mai mare decât cel specificat în atribut. Cele mai multe dintre dispozitivele pe care aplicația dvs. este probabil instalată primesc actualizări periodice de sistem din zbor, prin aer, așa că ar trebui să luați în considerare acest efect înainte de a seta acest atribut pentru aplicația dvs.

Viitor versiuni Android(dincolo de Android 2.0.1) nu va mai verifica maxSdkVersion și nu va mai aplica valoarea atunci când instalează sau verifică compatibilitatea aplicației. Cu toate acestea, Google Play va continua să folosească acest atribut ca filtru atunci când pune aplicații disponibile pentru descărcare de către utilizatori.

Element specifică hardware-ul necesar aplicației și configurarea software-ului dispozitiv mobil. De exemplu, o aplicație necesită o tastatură fizică sau un trackball pentru a funcționa. Specificația este folosită pentru a evita instalarea unei aplicații pe dispozitive care nu acceptă configurația necesară.

Dacă aplicația dvs. poate funcționa cu diferite configurații de dispozitiv, trebuie să includeți anumite elemente în manifest pentru fiecare configurație.

Puteți specifica orice combinație care conține. următoarele dispozitive

reqFiveWayNav- utilizați true dacă aplicația necesită un dispozitiv de intrare care acceptă navigarea în sus, în jos, stânga, dreapta și făcând clic pe elementul evidențiat. Aceste dispozitive includ trackball-uri și D-pad-uri. Practic depășit
reqHardKeyboard- utilizați true dacă aplicația necesită o tastatură hardware.
reqKeyboardType- vă permite să setați tipul tastaturii: nokeys, qwerty, twelvekey, undefined
reqNavigation- specificați una dintre valori: nonav, dpad, trackball, wheel sau undefined dacă este necesar un dispozitiv de navigare
reqTouchScreen- dacă este necesar un ecran tactil, atunci utilizați valoarea dorită din opțiunile posibile: notouch, stylus, finger, undefined. Acum aproape toate dispozitivele conțin un ecran tactil, deci este și depășit

Aplicația nu se va instala pe un dispozitiv care nu se potrivește cu configurația pe care ați setat-o. În mod ideal, ar trebui să dezvoltați o aplicație care să funcționeze cu orice combinație de dispozitive de intrare. În acest caz nu e necesar.

Element declară anumite funcționalități necesare pentru ca aplicația să funcționeze. În acest fel, aplicația nu va fi instalată pe dispozitive care nu au funcționalitatea necesară. De exemplu, o aplicație poate detecta că necesită o cameră cu focalizare automată. Dacă dispozitivul nu are o cameră încorporată cu autofocus, aplicația nu va fi instalată. De exemplu:

android.hardware.camera.față- este necesară camera hardware

Android.hardware.camera.autofocus- Necesită o cameră cu autofocus

Toți parametrii pot fi vizualizați la alma mater.

Element definește dimensiunile ecranului necesare pentru funcționarea normală a programului dvs. și permite compatibilitatea ecranului pentru dimensiunile ecranului mai mari decât cele specificate în acest parametru.

Pentru o mai mare claritate, voi da sintaxa

Determină dimensiunile și densitățile ecranului compatibile cu aplicația dvs. Un singur element poate fi prezent în fișierul manifest, dar poate conține multe elemente . De exemplu:
... ...
Sistemul Android nu citește acest element în fișierul manifest, nici în timpul instalării, nici în timpul lansării aplicației. Acest element este pur informativ și este folosit doar de servicii externe precum Google Play pentru a filtra afișarea aplicației dumneavoastră pe piață. Adică, dacă utilizatorul are parametri de ecran diferiți de cei specificați în acest element, atunci Google Play pur și simplu nu îi va arăta această aplicație.

În general, nu ar trebui să utilizați acest element.

Acest element declară formatul de compresie al unei singure texturi GL suportate de aplicația dvs. Dacă aplicația dvs. acceptă mai multe formate de comprimare a texturii, atunci trebuie să utilizați mai mult de unul dintre aceste elemente. De exemplu:

Toate valorile pot fi vizualizate la acest link. Puteți citi puțin despre acest parametru în rusă.

Element are o structură mult mai complexă decât toate elementele enumerate. Am luat structura acestui element din cartea lui Goloshchapov

Element unul dintre elementele principale ale manifestului, conținând o descriere a componentelor aplicației disponibile în pachet: stiluri, pictogramă etc. Conține elemente copil care declară fiecare dintre componentele incluse în aplicație. Nu poate exista decât un singur element într-un manifest .

Element copil declară o componentă Activitate. Dacă o aplicație conține mai multe activități, acestea trebuie declarate în manifest, creând un element separat pentru fiecare dintre ele . Dacă o Activitate nu este declarată în manifest, aceasta nu va fi vizibilă pentru sistem și nu va fi lansată când aplicația rulează sau va fi afișat un mesaj de eroare. Exemplu de declarație de activitate:

Aceste atribute ale elementelor sunt obligatorii și determină următoarele:

android:nume- numele clasei. Numele trebuie să includă denumirea completă a pachetului, dar dacă numele pachetului este deja definit în elementul rădăcină , numele clasei care implementează Activitatea poate fi scris sub formă prescurtată, omițând numele pachetului.

android:label— o etichetă text afișată utilizatorului în antetul Activitate.

Element conține multe alte atribute care definesc rezoluțiile, orientarea ecranului etc. Modificarea configurației în timp ce programul rulează

Când se schimbă limba, regiunea sau configurația hardware, Android oprește toate aplicațiile și apoi le repornește, reîncărcând valorile din resurse. Un astfel de comportament nu este întotdeauna adecvat sau de dorit. De exemplu, unele modificări de configurare (orientarea ecranului în spațiu, accesibilitatea tastaturii) pot apărea doar pentru că utilizatorul rotește dispozitivul sau scoate tastatura. Puteți personaliza modul în care aplicația dumneavoastră reacționează la astfel de modificări detectându-le și executându-le. propriile actiuni. Pentru a forța o activitate să urmărească modificările configurației pe măsură ce programul rulează, adăugați atributul la nodul său în manifest android:configChanges, indicând ce evenimente doriți să procesați.

Iată câteva valori care pot fi folosite pentru a descrie modificările de configurare:

orientare— poziția ecranului a fost schimbată de la portret la peisaj (sau invers);
tastatură Ascunsă— tastatura este extinsă sau ascunsă;
fontScale— utilizatorul a schimbat dimensiunea preferată a fontului;
local— utilizatorul a selectat noi setări de limbă;
tastatură— tipul tastaturii s-a schimbat; de exemplu, un telefon poate avea un panou cu 12 taste care, atunci când este rotit, dezvăluie o tastatură cu drepturi depline;
touch screen sau navigare— tipul de tastatură sau metoda de navigare s-a schimbat. De regulă, astfel de evenimente nu au loc.

În unele cazuri, mai multe evenimente se vor declanșa în același timp. De exemplu, atunci când utilizatorul scoate tastatura, majoritatea dispozitivelor generează evenimente tastatură AscunsăȘi orientare. Puteți selecta mai multe evenimente pe care doriți să le procesați singur, separându-le cu simbolul | .

Prezența atributului android:configChanges anulează repornirea aplicației când modificări specificate configuratii. În schimb, metoda din interiorul activității se declanșează onConfigurationChanged(). Ignorați-l pentru a putea gestiona modificările de configurare. Utilizați obiectul trecut Configurare pentru a obține noi valori. Nu uitați să apelați metoda cu același nume din clasa părinte și să reîncărcați valorile modificate din toate resursele care sunt utilizate în cadrul activității.

@Override public void onConfigurationChanged(Configuration _newConfig) ( super.onConfigurationChanged(_newConfig); [ ... Actualizați interfața de utilizare folosind date din resurse... ] if (_newConfig.orientation == Configuration.ORIENTATION_LANDSCAPE) ( [ ... Reacție la o orientare modificată a ecranului... ] ) if (_newConfig.keyboardHidden == Configuration.KEYBOARDHIDDEN_NO) ( [ ... Reacția la împingerea/retragerea tastaturii... ] ) )
Orice modificare a configurației care nu a fost marcată în mod explicit pentru procesare în cadrul aplicației dvs. va determina repornirea activității, ocolind apelul de metodă onConfigurationChanged .

Element acceptă noduri imbricate . Element definește tipurile de intenții la care poate răspunde o activitate, un serviciu sau un receptor de difuzare. Un filtru de intenție oferă componentelor client capacitatea de a prelua intențiile de tip declarat, eliminând cele care nu sunt semnificative pentru componentă și conține elemente copil. , , .