versiuni Android API. „Heart of a Robot”: Cum să utilizați API-ul sistemului Android în scopuri personale. Instrumente pentru dezvoltarea și depanarea aplicațiilor

Mai multe informații despre cum funcționează nivelurile API sunt disponibile în Ce este nivelul API?

Componentele aplicației

Servicii izolate

Navigare în stiva de aplicații

Android 4.1 facilitează implementarea modelelor de design adecvate pentru navigarea în sus. Tot ce trebuie să faceți este să adăugați android:parentActivityName la fiecare element din fișierul manifest. Sistemul folosește aceste informații pentru a deschide activitatea corespunzătoare atunci când utilizatorul apasă butonul Sus din bara de acțiuni (în timp ce termină și activitatea curentă). Deci, dacă declarați android:parentActivityName pentru fiecare activitate, nu aveți nevoie de metoda onOptionsItemSelected() pentru a gestiona evenimentele de clic pe pictograma aplicației din bara de acțiuni — sistemul se ocupă acum de acel eveniment și reia sau creează activitatea corespunzătoare.

Puteți gestiona datele media criptate în codecuri prin apelare queueSecureInputBuffer() împreună cu API-urile MediaCrypto, în loc de queueInputBuffer() normal.

Android Beam™ acceptă acum transferuri mari de sarcină utilă prin Bluetooth. Când definiți datele de transferat cu oricare noul setBeamPushUris() sau noua interfață de apel invers NfcAdapter.CreateBeamUrisCallback, Android predă transferul de date către Bluetooth sau alt transport alternativ pentru a obține viteze de transfer mai rapide. Acest lucru este util în special pentru încărcături utile mari, cum ar fi fișierele imagine și audio și nu necesită asociere vizibilă între dispozitive. Aplicația dvs. nu necesită lucrări suplimentare pentru a profita de transferurile prin Bluetooth.

Când utilizați interfața de apel invers, sistemul apelează metoda createBeamUris() a interfeței atunci când utilizatorul execută o partajare cu Android Beam, astfel încât să puteți defini URI-urile de partajat la momentul partajării. Acest lucru este util dacă URI-urile de partajat pot varia în funcție de contextul utilizatorului din cadrul activității, în timp ce apelarea setBeamPushUris() este utilă atunci când URI-urile de partajat sunt neschimbate și le puteți defini în siguranță din timp.

Descoperirea serviciului de rețea

Android 4.1 adaugă suport pentru descoperirea serviciilor bazate pe DNS multicast, care vă permite să găsiți și să vă conectați la servicii oferite de dispozitive similare prin Wi-Fi, cum ar fi dispozitive mobile, imprimante, camere foto, playere media și altele care sunt înregistrate pe rețeaua locală. reţea.

Înainte de a începe să descoperiți servicii pe dispozitive locale, trebuie să apelați și addServiceRequest() . Când WifiP2pManager.ActionListener pe care îl treceți la această metodă primește un apel invers cu succes, puteți începe apoi să descoperiți servicii pe dispozitivele locale apelând discoverServices() .

Când sunt descoperite servicii locale, veți primi un apel invers fie către WifiP2pManager.DnsSdServiceResponseListener, fie către WifiP2pManager.UpnpServiceResponseListener , în funcție de dacă v-ați înregistrat pentru a utiliza Bonjour sau Upnp. Reapelul primit în ambele cazuri conține un obiect WifiP2pDevice reprezentând dispozitivul peer.

Utilizarea rețelei

Serviciile de accesibilitate pot, de asemenea, să efectueze acțiuni în numele utilizatorului, inclusiv clic, defilare și trecere prin text folosind performAction și setMovementGranularities . Metoda performGlobalAction() permite, de asemenea, serviciilor să efectueze acțiuni precum Înapoi, Acasă și să deschidă Aplicații și Notificări recente.

Navigare în aplicație personalizabilă

Când construiți o aplicație Android, acum puteți personaliza schemele de navigare găsind elemente focalizabile și widget-uri de intrare folosind findFocus() și focusSearch() și setați focalizarea folosind setAccessibilityFocused() .

Widgeturi mai accesibile

Noua clasă android.view.accessibility.AccessibilityNodeProvider vă permite să prezentați vizualizări personalizate complexe către serviciile de accesibilitate, astfel încât acestea să poată prezenta informațiile într-un mod mai accesibil. Android.view.accessibility.AccessibilityNodeProvider permite unui widget utilizator cu conținut avansat, cum ar fi o grilă de calendar, să prezinte o structură semantică logică pentru serviciile de accesibilitate, care este complet separată de structura de aspect a widget-ului. Această structură semantică permite serviciilor de accesibilitate să prezinte un model de interacțiune mai util pentru utilizatorii cu deficiențe de vedere.

Copiaza si lipeste

Copiați și lipiți cu intenții

Renderscript

Funcționalitatea de calcul pentru renderscript a fost îmbunătățită cu următoarele caracteristici:

• Suport pentru mai multe nuclee într-un singur script.
• Suport pentru citirea din alocare cu mostre filtrate din calcul într-un nou script API rsSample.
• Suport pentru diferite niveluri de precizie FP în #pragma .
• Suport pentru interogarea informațiilor suplimentare de la obiectele RS dintr-un script de calcul.
• Numeroase îmbunătățiri ale performanței.

Sunt disponibile și noi pragmate pentru a defini precizia în virgulă mobilă cerută de Renderscript-urile de calcul. Acest lucru vă permite să activați operațiuni asemănătoare NEON, cum ar fi operațiuni rapide de matematică vectorială pe calea CPU, care altfel nu ar fi posibile cu standardul complet IEEE 754-2008.

Notă: Motorul grafic experimental Renderscript este acum depreciat.

Animaţie

Animații de lansare a activității

Vizualizări de la distanță

• „sans-serif” pentru Roboto obișnuit
• „sans-serif-light” pentru Roboto Light
• „sans-serif-condensed” pentru Roboto Condensed

Vibrați pentru controlerele de intrare

Dacă dispozitivele de intrare conectate au propriile capacități de vibrație, acum puteți controla vibrația acelor dispozitive folosind API-urile Vibrator existente, pur și simplu apelând getVibrator() pe InputDevice .

Permisiuni

Această caracteristică definește „televizorul” ca fiind o experiență tipică de televiziune din camera de zi: afișată pe un ecran mare, unde utilizatorul stă departe și forma dominantă de intrare este ceva ca un d-pad și, în general, nu prin atingere sau un mouse/pointer-dispozitiv.

Oricine a scris software mai mult sau mai puțin serios pentru diferite sisteme de operare mobile știe că Android este cel mai deschis sistem de operare pentru dezvoltatori. Disponibil pentru aplicații terță parte API-ul aici este mult mai larg, sistemul în sine este mai flexibil, iar regulile de introducere a aplicațiilor pe piață sunt foarte liberale. Cu toate acestea, Android are și o serie de API-uri de sistem care sunt ascunse de aplicațiile terțe și sunt disponibile numai pentru software-ul stoc. În acest articol vom încerca să ne dăm seama cum să accesăm aceste API-uri și ce oportunități deschid.

Puțină teorie

După cum știm cu toții, în Android există un astfel de concept - permisiunile aplicatiei(permisiuni, permisiuni). Permisiunile sunt scrise în fișierul Manifest.xml al fiecărei aplicații și determină ce funcții API le poate accesa aplicația. Dacă doriți să lucrați cu camera, adăugați linia la Manifest.xml . Aveți nevoie de acces la cardul de memorie - android.permission.READ_EXTERNAL_STORAGE. Totul este simplu și logic, iar toate puterile disponibile aplicațiilor sunt bine documentate.

Există, totuși, un detaliu foarte important în această schemă armonioasă, pe care înșiși creatorii Android-ului îl numesc nivel de acces(nivel de protecție). Pentru a înțelege ce este aceasta, încercați să adăugați următoarea linie la Manifest.xml al oricăreia dintre aplicațiile dvs.:

În teorie, această putere ar trebui să deschidă accesul la un API care vă permite să vă puneți smartphone-ul în modul avion, să activați/dezactivați GPS-ul și să faceți alte lucruri utile. Dar IDE-ul nu crede așa și, prin urmare, evidențiază imediat linia ca o eroare cu formularea „Permisiunea este acordată numai aplicațiilor de sistem”. Acesta este un avertisment despre încălcarea acelui nivel de acces. IDE-ul pare să ne spună: da, puteți încerca să acordați aplicației dvs. permisiunea WRITE_SECURE_SETTINGS, dar Android încă nu vă va permite să utilizați API-ul care i-a fost atribuit până când nu faceți aplicația dvs. una de sistem. Ce înseamnă „sistemic” în acest caz? Aceasta înseamnă: îl semnezi cu aceeași cheie digitală cu care este semnat firmware-ul însuși (încercați să obțineți o astfel de cheie de la un Samsung sau LG!).

Oficial, Android are patru niveluri de acces:

• normal- permisiuni „normale”, care dau aplicației acces la funcții inofensive care nu pot fi utilizate în mod rău intenționat (exemple: SET_ALARM, ACCESS_NETWORK_STATE, VIBRATE). Sistemul nici măcar nu vă va spune că aplicația le folosește deloc;
• periculos- puteri „periculoase”, utilizatorul va fi informat despre acestea la instalarea aplicației sau va vedea o fereastră de avertizare în Android 6.0 (exemple: READ_SMS, SEND_SMS, CALL_PHONE, READ_CALL_LOG);
• semnătură- disponibil numai pentru aplicațiile semnate cu cheia de firmware (exemple: GET_TASKS, MANAGE_USERS, WRITE_SETTINGS, MOUNT_UNMOUNT_FILESYSTEMS);
• privilegiat- disponibil pentru aplicațiile situate în directorul /system/priv-app.

În cele mai multe cazuri, semnătura și nivelurile de acces privilegiat sunt echivalente. De exemplu, pentru a obține permisiunea MANAGE_USERS, o aplicație trebuie fie să fie semnată cu o cheie de firmware, fie să fie localizată în directorul /system/priv-app. Dar există și excepții: de exemplu, autoritatea MANAGE_DEVICE_ADMIN are nivelul de acces la semnătură, adică singura modalitate de a-l obține este să semnezi aplicația cu cheia de firmware.

Există, de asemenea, un set de niveluri de acces interne introduse în Android pentru a rezolva anumite probleme: instalator, dezvoltare, preinstalat, app, pre23. În esență, acestea sunt cârje, iar în această etapă poate nu vă gândiți la ele, dar vom reveni la nivelul de acces la dezvoltare și ne va fi foarte util. Între timp, să vorbim despre cum să obținem nivelurile de acces de care avem nevoie și despre ce oferă acestea.

nivel de acces privilegiat

Privileged nu este cel mai înalt nivel de acces și nu vă permite să utilizați întregul API Android. Cu toate acestea, în majoritatea cazurilor se dovedește a fi destul de suficient, deoarece vă permite să instalați și să eliminați aplicații și utilizatori (INSTALL_PACKAGES, DELETE_PACKAGES, MANAGE_USERS), să gestionați bara de stare (STATUS_BAR), să gestionați unele setări de alimentare (WRITE_SECURE_SETTINGS), să citiți și Schimbare Setări Wi-Fi(READ_WIFI_CREDENTIAL, OVERRIDE_WIFI_CONFIG), dezactivați aplicațiile și componentele acestora (CHANGE_COMPONENT_ENABLED_STATE) și multe altele.

Pentru ca o aplicație să primească nivelul de acces privilegiat, aceasta trebuie să fie instalată în directorul /system/priv-app, ceea ce înseamnă că trebuie să vină preinstalată ca parte a firmware-ului. Cu toate acestea, cu root, putem plasa aplicația noastră în acest director folosind două funcții:

// O funcție de utilitate care pur și simplu execută o comandă shell static public boolean runCommandWait(String cmd, boolean needu) (încercați ( String su = "sh"; if (needsu) (su = "su"; ) Procesul de proces= Runtime.getRuntime().exec(new String(su, "-c", cmd)); int rezultat = process.waitFor(); returnare (rezultat == 0); ) catch (IOException e) ( throw new RuntimeException(e); ) catch (InterruptedException e) ( throw new RuntimeException(e); ) ) // Funcția face ca aplicația specificată să fie una de sistem și trimite smartphone-ul la o repornire soft statică public void makeAppSystem(String appName ) ( String systemPrivAppDir = "/system/priv-app/"; String systemAppDir = "/system/app/"; String appPath = "/data/app/" + appName; // Connect /system în modul citire-scriere dacă (!runCommandWait("mount -o remount,rw /system", true)) ( Log.e(TAG, "makeAppSystem: Nu se poate monta /sistem"); return; ) int api = Build .VERSION.SDK_INT; String appDir = systemPrivAppDir; // Copiați aplicația în /system/priv-app sau /system/app, în funcție de versiunea Android, dacă (api >= 21) ( runCommandWait("cp -R " + appPath + "* " + appDir, adevărat); runCommandWait("chown -R 0:0 " + appDir + appName + "*", adevărat); runCommandWait ("rm -Rf " + appPath + "*", adevărat); ) else ( dacă (api< 20) { appDir = systemAppDir; } runCommandWait("cp " + appPath + "* " + appDir, true); runCommandWait("chown 0:0 " + appDir + appName + "*", true); runCommandWait("rm -f " + appPath + "*", true); } // Отправляем смартфон в мягкую перезагрузку Shell.runCommand("am restart", true); }

Nu voi descrie funcția runCommandWait; pur și simplu execută o comandă shell și așteaptă să se finalizeze (citiți mai multe în articolul meu despre scrierea aplicațiilor cu drepturi root). Funcția makeAppSystem, la rândul său, ia numele complet al aplicației (acesta este același com.example.app pe care îl specificați atunci când creați un proiect nou în Android Studio) și îl transferă în /system/priv-app sau /system/ aplicație, în funcție de versiunea de Android pe care o utilizați. Codul ți se poate părea puțin ciudat, dar de fapt este absolut corect și ia în considerare doi factori:

• înainte de Android 4.4 (Nivel API: 20) directorul /system/priv-app nu exista și asta este tot aplicații de sistem situat în /system/app ;
• începând cu Android 5.0 (Nivel API: 21), pachetele de aplicații nu sunt stocate pur și simplu în /data/app și /system/priv-app, ci sunt plasate în propriile subdirectoare separate.

Cum se folosește acest cod? Este foarte simplu: definiți în Manifest.xml al aplicației dumneavoastră toate puterile privilegiate de care are nevoie, indiferent de erorile IDE. Apoi, chiar la începutul codului aplicației, inserați un apel la makeAppSystem cu numele aplicației în sine ca argument, compilați și rulați. După lansare, aplicația se mută în /system/priv-app, repornește smartphone-ul și toate API-urile privilegiate sunt deschise pentru aceasta.

Lista puterilor privilegiate poate fi găsită în sursele Android. Doar căutați cuvântul privilegiat. Mai multe despre cum să le folosiți puțin mai târziu.

Nivel de acces la semnătură

Semnarea cu o cheie de firmware vă permite să obțineți cel mai înalt nivel de acces la API - semnătură. O aplicație cu un astfel de acces poate face aproape orice: să manipuleze orice setări Android (WRITE_SETTINGS, WRITE_SECURE_SETTINGS), să acorde drepturi de administrator al aplicațiilor (MANAGE_DEVICE_ADMINS), să apese pe butoane în mod programatic și să introducă date în orice fereastră (INJECT_EVENTS) și multe altele.

Obțineți acest nivel de acces la firmware de stoc aproape imposibil. Niciun producător de smartphone-uri nu vă va oferi o cheie pentru a-și semna firmware-ul. Dar dacă vorbim despre firmware personalizat, atunci lucrurile devin puțin mai ușoare. De exemplu, versiuni de noapte ale aceluiași CyanogenMod (și permiteți-mi să vă reamintesc că are mai mulți utilizatori decât utilizatori ai tuturor versiunilor Windows Phone, luate împreună) sunt semnate cu o cheie de testare, iar particularitatea sa este că este disponibilă publicului.

Dar asta nu este tot, CyanogenMod are un mecanism de securitate care, spre deosebire de Android pur, permite nu absolut tuturor aplicațiilor semnate cu cheia de firmware să primească nivelul de acces la semnătură, ci doar celor situate în /system/priv-app. Prin urmare, pentru a obține nivelul de acces la semnătură în CyanogenMod (nu în Cyanogen OS, subliniez), trebuie să:

1. Adăugați permisiunile necesare la Manifest.xml al aplicației.
2. Adăugați aplicației un apel la funcția makeAppSystem() descrisă în secțiunea anterioară.
3. Semnați versiunea de lansare a aplicației cu cheia platformei din depozitul CyanogenMod.

Dezvoltarea nivelului de acces

Android are un nivel de acces de dezvoltare special, a cărui diferență este că aplicațiile îl primesc nu prin plasarea în /system/priv-app sau folosind o semnătură digitală a firmware-ului, ci dinamic. Adică, sistemul poate acorda acest nivel de acces oricărei aplicații sau o poate revoca. Dar cel mai important este că, având drepturi root, aplicația își poate acorda acest nivel de acces independent.

Pentru a face acest lucru, trebuie doar să utilizați un cod ca acesta:

RunCommandWait("pm grant " + appName + " android.permission.WRITE_SECURE_SETTINGS", true);

În acest caz, appName va primi permisiunea WRITE_SECURE_SETTINGS, indiferent de locul în care este găzduit sau cu ce cheie este semnat. Misto? Fără îndoială, dar WRITE_SECURE_SETTINGS este de fapt singura permisiune utilă cu nivelul de acces de dezvoltare. Restul de paisprezece sunt puteri pentru depanare și testare (citire jurnale, depozite de memorie și așa mai departe).

Cum se utilizează API-ul de sistem?

Principala problemă pe care o veți întâlni atunci când lucrați cu API-ul de sistem este lipsa completă (cu câteva excepții) de documentație. Nu veți găsi aproape nicio mențiune despre acest lucru nici în manualele oficiale sau neoficiale. Informațiile vor trebui strânse bit cu bit, străbătând sute de pagini de forumuri și citind mii de pagini de cod sursă Android. Cu toate acestea, vă vom oferi un punct de plecare, deși unul mic, sub forma a câteva exemple utile.

WRITE_SECURE_SETTINGS

Permisiunea WRITE_SECURE_SETTINGS a fost introdusă în Android 4.2 pentru a proteja unele setări Android critice. Aceste setări includ: pornirea/dezactivarea modului avion, gestionarea setărilor de locație și transfer de date. Este protejat de trei niveluri de acces: semnătură, privilegiat și dezvoltare. Adică, puteți utiliza oricare dintre metodele de mai sus pentru a obține un nivel de acces pentru a acorda aplicației dvs. permisiunea WRITE_SECURE_SETTINGS.

Cum să folosiți noile oportunități? De exemplu, așa:

// Citiți valoarea setării curente boolean isEnabled = Settings.System.getInt(getContentResolver(), Settings.System.AIRPLANE_MODE_ON, 0) == 1; // Comută setarea Settings.System.putInt(getContentResolver(), Settings.System.AIRPLANE_MODE_ON, isEnabled ? 0: 1); // Trimite o intenție de schimbare a Intenției Intenție = new Intent(Intent.ACTION_AIRPLANE_MODE_CHANGED); intent.putExtra("stare", !isEnabled); sendBroadcast(intentie);

Acesta este un cod foarte simplu care trece stupid smartphone-ul în modul avion sau invers în funcție de starea curentă. Totul este simplu și concis.

INSTALL_PACKAGES

După cum sugerează și numele, permisiunea INSTALL_PACKAGES vă permite să instalați „în tăcere” pachete APK în sistem. Această caracteristică poate fi utilizată fie de aplicațiile semnate cu o cheie de firmware (semnătură), fie instalate în /system/priv-app . În acest caz, nici măcar nu este necesar să folosiți API-ul Java, doar apelați comanda pm (Package Manager) din consolă cu parametrii necesari:

RunCommandWait("pm install " + apkPath, false);

După ce comanda este procesată, pachetul apkPath va fi instalat pe sistem. Ați putea argumenta că același lucru se poate face și cu drepturile root și ați avea dreptate: în acest caz, este suficient să schimbați ultimul argument al funcției runCommandWait() la true. Cu toate acestea, merită să rețineți că aplicațiile cu drepturi de root, în primul rând, duc la apariția unei ferestre care solicită utilizatorului permisiunile corespunzătoare și, în al doilea rând, sunt înregistrate de același SuperSU. În caz contrar, este suficient să vă înregistrați software-ul o dată în /system/priv-app și va putea instala cât de mult software doriți fără întrebări.

În loc de concluzii

Asta e tot. Accesarea API-ului privat în Android nu este atât de dificil de realizat. Pe de altă parte, cu software-ul legitim, nu are sens să-l folosești în majoritatea cazurilor; este mai ușor să obții drepturi de root și să apelezi la cel adecvat. comenzile consolei: setări pentru a schimba setările, p.m pentru a instala/dezinstala aplicații, setprop pentru a modifica setările de nivel scăzut și așa mai departe. Totuși, dacă vorbim de software nu chiar obișnuit...

Android SDK include o varietate de biblioteci, documentație și instrumente care ajută la dezvoltarea aplicațiilor mobile pentru platforma Android.

• API Android SDK - biblioteci Android API furnizate pentru dezvoltarea aplicațiilor.
• Documentația SDK - include informații de referință extinse care detaliază ceea ce este inclus în fiecare pachet și clasă și cum să îl utilizați atunci când dezvoltați aplicații.
• AVD (Android Virtual Device) - emulator mobil interactiv dispozitive Android. Folosind un emulator, puteți rula și testa aplicații fără a utiliza un dispozitiv Android real.
• Instrumente de dezvoltare - SDK-ul include mai multe instrumente de dezvoltare care vă permit să compilați și să depanați aplicațiile pe care le creați.
• Exemplu de cod - SDK-ul Android oferă exemple de aplicații care demonstrează unele dintre capabilități Android, Și programe simple, care vă arată cum să utilizați anumite funcții API în codul dvs.

Versiunile SDK și Android API Level

Înainte de început Dezvoltare de aplicații Android Este util să înțelegeți abordarea generală a platformei pentru gestionarea schimbărilor API. De asemenea, este important să înțelegeți Nivelul API Android (API Layer Identifier) ​​și rolul acestuia în a face aplicația dvs. compatibilă cu dispozitivele pe care va fi instalată.

Nivelul API- o valoare întreagă care identifică în mod unic versiunea API a platformei Android. Platforma oferă structuri API cu care aplicațiile le pot folosi pentru a interacționa sistem Android. Fiecare versiune ulterioară a platformei Android poate include actualizări API.

Actualizările structurii API sunt concepute pentru a se asigura că noul API rămâne compatibil cu versiunile anterioare ale API-ului. Astfel, majoritatea modificărilor aduse API-ului sunt cumulative și introduc altele noi funcţionalitate sau le corectează pe cele anterioare. Deoarece unele dintre API-uri sunt actualizate constant, API-urile învechite nu sunt recomandate pentru utilizare, dar nu sunt eliminate din motive de compatibilitate cu aplicațiile existente.

Nivelul API pe care îl folosește o aplicație Android este determinat de un identificator întreg care este specificat în fișierul de configurare al fiecărei aplicații Android.

Tabelul determină corespondența dintre nivelul API și versiunea platformei Android.

Conformitatea cu versiunea platformei și nivelul API

Instrumente pentru dezvoltarea și depanarea aplicațiilor

Pe lângă emulator, SDK-ul include și multe alte instrumente pentru depanarea și instalarea aplicațiilor pe care le creați. Dacă dezvoltați aplicații Android folosind IDE-ul Eclipse, multe instrumente Linie de comanda, incluse în SDK, sunt deja folosite la construirea și compilarea proiectului. Cu toate acestea, pe lângă acestea, SDK-ul conține o serie de instrumente utile pentru dezvoltarea și depanarea aplicațiilor:

• android- un instrument de dezvoltare important lansat din linia de comandă care vă permite să creați, să ștergeți și să configurați dispozitive virtuale, să creați și să actualizați proiecte Android (când lucrați în afara mediului Eclipse) și să actualizați SDK-ul Android cu noi platforme, suplimente și documentație;
• Serviciul Dalvik Debug Monitor (DDMS)- integrat cu Dalvik Virtual Machine, standard mașină virtuală Platformă Android, acest instrument vă permite să gestionați procesele atât pe emulator, cât și pe dispozitiv și, de asemenea, ajută la depanarea aplicațiilor. Puteți utiliza acest serviciu pentru a încheia procese, pentru a selecta un proces specific pentru depanare, pentru a genera date de urmărire, pentru a vizualiza informații despre heap sau fir, pentru a face capturi de ecran de emulator sau de dispozitiv și multe altele;
• Vizualizator de ierarhie- un instrument vizual care vă permite să depanați și să optimizați interfața cu utilizatorul a aplicației în curs de dezvoltare. Afișează un arbore vizual al ierarhiei vizualizării, analizează performanța redesenării imagini grafice pe ecran și poate îndeplini multe alte funcții pentru a analiza interfața grafică a aplicațiilor;
• Layoutpt este un instrument de linie de comandă care ajută la optimizarea schemelor de marcare și a ierarhiilor de marcare în aplicația pe care o creați. Necesar pentru rezolvarea problemelor la crearea de interfețe grafice complexe care pot afecta performanța aplicației;
• Remiză 9-patc h- editor grafic, care vă permite să creați cu ușurință grafică NinePath pentru interfața grafică a aplicațiilor dezvoltate;
• sqlite3- un instrument de accesare a fișierelor de date SQLite create și utilizate de aplicațiile Android;
• Traceview- acest instrument oferă o analiză grafică a jurnalelor de urmărire care pot fi generate din aplicații;
• mksdcard- un instrument de imagine de disc pe care îl puteți utiliza într-un emulator pentru a simula existența card extern memorie (de ex. card SD).
• Cel mai important dintre ele este emulator dispozitiv mobil , cu toate acestea, SDK-ul include și alte instrumente pentru depanare, împachetare și instalarea aplicațiilor dvs. pe emulator.

Dispozitiv virtual Android

Dispozitiv virtual Android (Dispozitiv virtual Android) este un emulator care rulează computer obișnuit. Emulatorul este folosit pentru a proiecta, depana și testa aplicații într-un mediu de rulare real.

Înainte de a putea rula un emulator de dispozitiv Android, trebuie să creați Dispozitiv virtual Android (AVD) . AVD Definește imaginea sistemului și setările dispozitivului utilizate de emulator.

Există două moduri de a crea un emulator de dispozitiv:

1. Pe linia de comandă folosind utilitarul Android, disponibil în directorul în care ați instalat Android SDK, în folderul instrumente.
2. Din punct de vedere vizual Cu folosind Android SDK și AVD Manager în Eclipse IDE selectând elementul de meniu Fereastra | Android SDK și AVD Manager. Va apărea fereastra Android SDK și AVD Manager, cu care puteți crea și configura emulatori de dispozitive mobile, precum și descărca actualizări Android SDK.

De asemenea, va apărea fereastra Android SDK și AVD Manager dacă apelați android.exe fără parametri pe linia de comandă.

iAndroid SDK și AVD Manager

Fereastra Android SDK și AVD Manager

În partea dreaptă a panoului Listă de dispozitive virtuale Android existente, faceți clic pe butonul Nou, care va deschide fereastra Creare AVD nou.

În această fereastră, setați configurația dorită pentru emulatorul de dispozitiv care este creat:

• Nume- numele dispozitivului care se creează;
• Ţintă- Versiunea Android SDK acceptat de dispozitiv. Dispozitivul este compatibil cu versiunile SDK mai vechi, adică dacă este selectat Android 2.0, emulatorul va accepta versiunile SDK 1.6, 1.5, 1.1;
• Card SD- instalează un card SD virtual;
• Piele-tipul de ecran al dispozitivului. Platforma descărcabilă include o serie de skin-uri de emulator care pot fi folosite pentru a simula performanța aplicației pe dispozitive de diferite dimensiuni și rezoluții de ecran. Un set de skin-uri pentru emulator în funcție de versiunea instalată SDK-ul specificat în câmpul țintă conține diferite tipuri și dimensiuni de ecran, de exemplu:
• HVGA(Jumătate de măsură Video VGA Matrice grafică), dimensiune 320x480, densitate medie, ecran normal;
• WVGA800 (Wide Video Graphics Array), dimensiune 480x800, densitate mare, ecran normal;
• WVGA854 (Wide Video Graphics Array), 480x854, densitate mare, ecran normal;
• QVGA (Quarter Video Graphics Array), dimensiune 240x320, densitate redusă, ecran mic;
• WQVGA (Wide Quarter Video Graphics Array), dimensiune 240x400, densitate redusă, ecran normal;

• Hardware- imitarea echipamentelor instalate pe aparat. Dacă este necesar, făcând clic pe butonul Nou, puteți deschide o fereastră pentru adăugarea de echipamente virtuale suplimentare.

Fereastra pentru adăugarea de hardware virtual suplimentar

După ce setați configurația și faceți clic pe butonul Creare AVD, managerul va crea un nou dispozitiv virtual, al cărui nume și versiunea API vor apărea în listă. Lista dispozitivelor virtuale Android existente.

Pentru mai multe reglaje, este mai bine să utilizați instrumentul de linie de comandă andnoid.exe. Are mai multe caracteristici decât AVD-ul vizual Map9er și este convenabil pentru configurarea rețelei, a porturilor și a hardware-ului virtual al emulatorului. Din păcate, din cauza spațiului limitat al cărții, nu este posibil să luăm în considerare acest instrument mai detaliat.

În funcție de suportat versiuni APIaspect dispozitiv virtual va fi diferit.

Fereastra emulatorului este proiectată sub forma unui telefon cu o tastatură suplimentară. După ce sistemul pornește, apare Ecranul de start - Desktop Android. Pentru a-l accesa, folosiți butonul cu pictograma casei. Emulatorul simulează și el touch screen a unui dispozitiv mobil real - în emulator, faceți clic pe butonul stâng al mouse-ului de pe ecran.

Emulatorul are două desktop-uri virtuale, care pot fi navigate folosind butoanele săgeată de pe bară de navigare dispozitiv sau prin mișcarea cursorului în timp ce țineți apăsat butonul stâng al mouse-ului (într-un dispozitiv real, prin mișcarea degetului pe ecran). Pe lângă comenzile rapide ale programelor, puteți plasa widget-uri pe desktop.

Aspectul AVD versiunea 1.5

Aspectul AVD versiunea 2.0

Pentru a testa aspectul aplicația care se creează la diferite poziții ale ecranului folosind o combinație de taste +Puteți schimba aspectul ecranului de la vertical la orizontal și invers.

Bara din partea de sus a ecranului este Bara de stare. Conține pictograme de notificare de sistem: puterea semnalului stației comunicatii mobile, încărcarea bateriei și ora curentă. Panou Bara de stare este, de asemenea, conceput pentru a afișa (sub formă de pictograme care apar în partea stângă a panoului) notificări ale utilizatorului pentru apeluri pierdute, mesaje text și multimedia necitite, e-mail primite și notificări de sistem de la serviciile care rulează în fundal. Dacă în Bara de stare selectați pictograma de notificare și trageți în jos marcatorul care apare, se deschide un panou de notificare extins cu informații mai detaliate și un buton pentru a închide notificarea.

Marcatorul din partea de jos a ecranului vă permite să deschideți o fereastră pentru lansarea aplicațiilor instalate pe sistem - Lansatorul de aplicații. Fereastra se extinde când faceți clic pe marcator.

Cu toate acestea, emulatorul nu acceptă unele funcționalități disponibile pe dispozitivele reale:

• mesajele primite și trimise. Cu toate acestea, puteți simula apeluri telefonice prin interfața emulator;

Platforma de lansare aplicații instalateLansatorul de aplicații

• conexiune USB;
• cameră video (cu toate acestea, există un simulator de cameră video);
• conectarea căștilor;
• determinarea stării conexiunii;
• determinarea nivelului de încărcare baterie; D detectarea introducerii sau scoaterii cardului SD;
• Conexiune Bluetooth.

Cu siguranță, telefoane reale ușor diferit de emulator, dar în general AVD proiectat de foarte înaltă calitate și aproape ca funcționalitate față de dispozitivul real.

CUPRINS ÎN: DESCRIERE:

Vă permite să specificați compatibilitatea aplicației cu una sau mai multe versiuni de platformă folosind niveluri API. În ciuda numelui său, acest element este folosit pentru a indica numărul nivelului API, nu numărul versiunii SDK sau versiunea platformei Android. Nivelul API este un singur întreg și este întotdeauna asociat cu numărul de platformă Android corespunzător.

ATRIBUTE: android:minSdkVersion

Un număr întreg care indică nivelul minim API de care aplicația necesită pentru a funcționa. Sistemul împiedică instalarea aplicației dacă nivelul API pe dispozitiv este mai mic decât cel specificat în acest atribut. Acest atribut trebuie folosit întotdeauna.

Atenţie: dacă nu specificați acest atribut, sistemul va folosi o valoare implicită de 1 , ceea ce înseamnă că aplicația este compatibilă cu toate versiunile de Android. Dacă aplicația nu acceptă toate versiunile (de exemplu, folosește API 3) și nu specificați o valoare minSdkVersion, atunci când instalați aplicația pe un sistem cu un API mai mic de 3, se va bloca dacă încearcă să folosească funcții indisponibile a API-ului din amonte. Prin urmare, specificați întotdeauna valoarea corespunzătoare a nivelului API pentru acest atribut.

Android:targetSdkVersion

Un număr întreg care indică versiunea API-ului pe care o vizează aplicația. Dacă atributul nu este specificat, este utilizată valoarea echivalentă cu minSdkVersion.

Atributul spune sistemului că ați testat aplicația în versiunea specificată și că sistemul nu ar trebui să permită aplicației să ruleze în modul de compatibilitate. Odată cu lansarea de noi versiuni, comportamentul și aspectul sistemului se modifică. Cu toate acestea, dacă nivelul API al platformei este mai mare decât versiunea specificată în acest atribut, sistemul permite utilizarea modului de compatibilitate, astfel încât aplicația să funcționeze așa cum vă așteptați. Puteți dezactiva acest comportament setând targetSdkVersion la versiunea platformei pe care rulează aplicația. De exemplu, setarea valorii 11 și altele vor permite sistemului să aplice tema Xono atunci când rulează pe Android 3.0 și versiuni ulterioare și, de asemenea, dezactivează modul de compatibilitate a ecranului atunci când rulează pe ecrane mai mari (deoarece API 11 acceptă implicit ecrane mai mari).

Pentru a susține o aplicație cu fiecare versiune de Android, trebuie să creșteți valoarea acestui atribut în funcție de cel mai recent nivel API disponibil și apoi să testați temeinic aplicația pe platforma corespunzătoare.

Adăugat în API 4.

Android:maxSdkVersion

Număr întreg indicând nivel maxim Un API în care aplicația poate rula.

În Android 1.5, 1.6 și 2.0.1, sistemul a verificat valoarea atributului la instalarea și validarea aplicației după o actualizare a sistemului. În orice caz, dacă valoarea atributului este mai mică decât nivelul API al sistemului, sistemul nu va permite instalarea aplicației. Dacă aplicația este verificată după o actualizare a sistemului și versiunile nu se potrivesc, aplicația este eliminată de pe dispozitiv.

Pentru a arăta modul în care un atribut afectează o aplicație după o actualizare a sistemului, luați în considerare următorul exemplu:

Pentru aplicație, valoarea atributului este maxSdkVersion=5 . Un utilizator al unui dispozitiv cu Android 1.6 (API 4) a descărcat și a instalat aplicația. Câteva săptămâni mai târziu, utilizatorul a actualizat versiunea Android la 2.0 (API 5). După actualizare, sistemul verifică din nou atributul și lasă aplicația pe dispozitiv. Aplicația funcționează bine. Cu toate acestea, după ceva timp, dispozitivul este actualizat la versiunea Android 2.0.1 (API 6). După actualizare, sistemul nu poate confirma că aplicația rulează deoarece nivelul API al sistemului (6) este mai mare decât maximul setat pentru aplicație (5). Sistemul șterge aplicația.

Avertizare: nu este recomandată specificarea acestui atribut!În primul rând, nu este nevoie să setați atributul pentru a preveni instalarea pe noile versiuni de Android pe măsură ce acestea sunt lansate, deoarece noile versiuni sunt complet compatibile cu versiunea precedentă. Aplicația ar trebui să funcționeze corect cu versiuni noi, cu condiția ca API-ul standard să fie utilizat. În al doilea rând, rețineți că în unele cazuri specificarea atributului poate duce la dezinstalarea aplicației după următoarea actualizare a sistemului până la mai mult nivel inalt API. Majoritatea dispozitivelor actualizează periodic versiunea platformei prin aer, așa că ar trebui să luați în considerare acest fapt înainte de a specifica acest atribut.

Adăugat în API 4.

Android după versiunea 2.0.1 nu mai verifică atributul maxSdkVersion în timpul instalării aplicației sau după o actualizare a sistemului. Google Play va folosi atributul pentru a filtra aplicațiile pentru a preveni instalarea pe dispozitive neadecvate.

ADAUGAT: Nivelul API 1

Ce este un nivel API?

Nivelul API este un număr întreg care identifică o revizuire unică a API-ului platformei Android.

Platforma Android oferă un API pe care aplicațiile îl pot folosi pentru a interacționa cu sistemul de bază și include:

• un set de pachete și clase de nucleu.
• un set de elemente și atribute XML pentru fișierul manifest.
• un set de elemente și atribute XML pentru declararea resurselor.
• set de intenții.
• un set de permisiuni pe care aplicațiile le necesită și sunt incluse în sisteme.

Fiecare versiune ulterioară de Android poate include actualizări ale aplicațiilor de sistem.

Actualizările cadru sunt concepute pentru a rămâne compatibile cu versiunile anterioare. Adică, majoritatea modificărilor aduse API-ului adaugă noi capabilități. Când actualizați o parte a unui API, partea veche este marcată ca depreciată, dar nu este eliminată, astfel încât aplicațiile existente o pot folosi în continuare. Funcțiile sunt foarte rar eliminate din API și acest lucru se datorează în principal din motive de securitate. Toate celelalte părți ale versiunilor anterioare sunt transferate fără modificări.

Cadru care folosește Platforma Android este specificat folosind un număr întreg numit nivel API. Fiecare versiune de Android acceptă exact un nivel API, deși include și mai multe versiuni timpurii(până la API 1). Prima versiune de Android respectă API 1.