Paano Gumagana ang Pag-install ng Android App sa ilalim ng Hood

Kapag na-tap mo ang "I-install" sa isang APK file o nag-download ng app mula sa Play Store, magsisimula ang isang kumplikadong pagkakasunud-sunod ng mga operasyon sa likod ng mga eksena. Ang lumilitaw na isang simpleng progress bar ay aktwal na kumakatawan sa dose-dosenang mga hakbang na kinasasangkutan ng pag-parse ng package, pag-verify ng cryptographic, pamamahala ng pahintulot, pagkuha ng file, at pag-optimize ng code. Ang pag-unawa sa prosesong ito ay nakakatulong na ipaliwanag kung bakit minsan nabigo ang mga pag-install at kung ano ang maaari mong gawin tungkol dito.

Sa artikulong ito, tatalakayin namin ang bawat pangunahing hakbang ng pipeline ng pag-install ng Android, mula sa sandaling makatanggap ang system ng APK hanggang sa punto kung saan handa nang ilunsad ang app.

Hakbang 1: Pagsisimula ng Pag-install

Ang proseso ng pag-install ay nagsisimula nang iba depende sa pinagmulan:

• Play Store: Dina-download ng Play Store app ang APK (o mga split APK) at tinatawagan ang package installer ng system na may mga espesyal na pribilehiyo na lumalampas sa ilang kumpirmasyon ng user.
• Sideloading: Kapag nagbukas ka ng APK file, inilulunsad ng Android ang aktibidad ng package installer. Sa Android 8.0 at mas bago, ang pag-install ng app ay dapat may pahintulot na "Mag-install ng mga hindi kilalang app" para sa partikular na pinagmulan nito.
• ADB: Ang adb install command ay direktang nakikipag-ugnayan sa package manager service sa pamamagitan ng USB, na ganap na lumalampas sa graphical installer.

Anuman ang pinagmulan, ang lahat ng mga pag-install ay umaabot sa parehong serbisyo ng system: ang PackageManagerService (PMS). Ito ang pangunahing awtoridad para sa lahat ng pagpapatakbo ng package sa Android.

Hakbang 2: Pag-parse ng Package

Bago ang anumang bagay, kailangang maunawaan ng system kung ano ang malapit nang i-install. Hinihimok ng PackageManagerService ang PackageParser na basahin ang APK file at i-extract ang metadata nito.

Binabasa ng parser ang AndroidManifest.xml file mula sa loob ng APK. Ang binary XML file na ito ay naglalaman ng kritikal na impormasyon:

• Pangalan ng package: Ang natatanging identifier para sa app (hal., com.example.myapp)
• Code at pangalan ng bersyon: Ginagamit upang matukoy kung ito ay isang pag-upgrade o isang bagong pag-install
• Minimum at target na mga bersyon ng SDK: Tinutukoy ang compatibility sa device
• Ipinahayag na mga pahintulot: Parehong mga pahintulot na hinihiling ng app at mga custom na pahintulot na tinukoy nito
• Mga Bahagi: Mga aktibidad, serbisyo, broadcast receiver, at content provider na nirerehistro ng app
• Mga tampok ng hardware at software: Mga Kinakailangan tulad ng camera, GPS, o mga partikular na bersyon ng OpenGL

Kung mali ang anyo ng manifest o hindi wasto ang istraktura ng APK, nabigo ang pag-install sa yugtong ito na may mensaheng "Parse error." Isa ito sa mga pinakakaraniwang dahilan kung bakit hindi na-install ang mga naka-sideload na APK.

Hakbang 3: Mga Pagsusuri sa Pagkatugma

Kapag na-parse na ang manifest, nagsasagawa ang system ng isang serye ng mga pagsusuri sa compatibility:

• Bersyon ng SDK: Kung mas mataas ang minSdkVersion ng app kaysa sa API level ng device, tatanggihan ang pag-install.
• ABI compatibility: Kung naglalaman ang APK ng mga katutubong aklatan, susuriin ng system kung tumutugma ang mga ito sa arkitektura ng CPU ng device. Ang APK na may armeabi-v7a lang na mga library ay hindi mai-install sa isang x86-only na device.
• Mga kinakailangang tampok: Kung idineklara ng app ang mga kinakailangang feature ng hardware (tulad ng android.hardware.telephony), ibe-verify ng system na sinusuportahan sila ng device.
• Magagamit na imbakan: Sinusuri ng system kung may sapat na libreng espasyo para i-install ang app, kabilang ang espasyo para sa mga kinuhang native na library at mga na-optimize na DEX file.

Hakbang 4: Pag-verify ng Lagda

Ito ay isa sa mga pinakamahalagang hakbang sa proseso ng pag-install. Bine-verify ng Android ang cryptographic signature ng APK para matiyak ang integridad at pagiging tunay nito.

Ang proseso ng pag-verify ay depende sa kung aling mga signing scheme ang naroroon:

V1 Signature (JAR Signing)

Sinusuri ng system ang direktoryo ng META-INF/ para sa mga signature file (.SF, .RSA o .DSA). Ang bawat file sa APK ay na-verify laban sa mga digest na nakalista sa manifest. Ito ay mabagal dahil ang bawat file ay dapat na indibidwal na na-hash.

Lagdang V2 (APK Signature Scheme v2)

Ipinakilala sa Android 7.0, nilalagdaan ng scheme na ito ang buong APK bilang isang binary blob. Ang signature block ay ipinasok sa pagitan ng ZIP central directory at end-of-central-directory record. Mas mabilis ang pag-verify dahil gumagana ito sa mga raw byte nang hindi kinakailangang i-decompress ang mga indibidwal na entry.

V3 Signature (Pag-ikot ng Key)

Available mula sa Android 9.0, pinalawak ng V3 ang V2 na may suporta para sa pag-ikot ng key. May kasama itong proof-of-rotation na istraktura na nag-uugnay sa luma at bagong signing key, na nagpapahintulot sa mga developer na baguhin ang kanilang signing key habang pinapanatili ang pagiging tugma ng update.

V4 Signature (Incremental)

Ipinakilala ng Android 11 ang V4 para sa mga incremental na pag-install. Nagbibigay ito ng signature na batay sa puno ng Merkle na nagbibigay-daan sa pag-verify ng mga indibidwal na bloke habang ini-stream ang mga ito sa device.

Kung nabigo ang pag-verify ng lagda para sa anumang kadahilanan, ang pag-install ay agad na abort. Maaari mong tingnan ang lagda ng APK bago i-install gamit ang aming Tool ng Tagasuri ng APK.

I-update ang Pagtutugma ng Lagda

Kung naka-install na ang isang app na may parehong pangalan ng package, magsasagawa ang system ng karagdagang pagsusuri: dapat tumugma ang certificate ng pag-sign ng bagong APK sa certificate ng kasalukuyang pag-install. Pinipigilan nito ang isang malisyosong partido na palitan ang isang lehitimong app ng pinakialaman na bersyon. Kung hindi tumugma ang mga lagda, makikita mo ang error na "Hindi naka-install ang app: Sumasalungat ang package sa isang umiiral nang package na may parehong pangalan."

Hakbang 5: Pagkumpirma ng User

Para sa mga naka-sideload na pag-install, ang system ay nagpapakita ng dialog ng pagkumpirma ng pag-install na nagpapakita ng:

• Ang pangalan at icon ng app (kinuha mula sa mga mapagkukunan ng APK)
• Pinahintulutan ang mga kahilingan ng app (sa mga mas lumang bersyon ng Android)
• Kung ito ay isang bagong pag-install o isang update
• Anumang mga babala tungkol sa pinagmulan ng app o mga potensyal na panganib

Sa Android 12 at mas bago, ang screen ng kumpirmasyon ay mas simple dahil ang mga pahintulot sa runtime ay ibinibigay nang paisa-isa kapag kailangan ng app ang mga ito, sa halip na sa oras ng pag-install.

Hakbang 6: Pagkuha at Paglalagay ng File

Kapag nakumpirma na ng user (o para sa pag-install ng Play Store, awtomatikong), magsisimula ang system sa pag-extract at paglalagay ng mga file:

Imbakan ng APK

Ang APK file mismo ay kinopya sa /data/app/[package-name]-[random]/base.apk. Para sa mga split APK installation, ang mga karagdagang file tulad ng split_config.arm64_v8a.apk ay inilalagay sa tabi ng base APK. Ang orihinal na APK sa folder ng Mga Download ay hindi binago o tinanggal.

Native Library Extraction

Kung ang APK ay naglalaman ng mga katutubong aklatan (sa lib/ na direktoryo), ang mga ito ay na-extract sa /data/app/[package-name]-[random]/lib/[abi]/. Sa mga mas bagong bersyon ng Android, maaaring i-opt ng mga app na panatilihing naka-compress ang mga native na library sa loob ng APK at direktang i-load ang mga ito gamit ang android:extractNativeLibs="false", na nakakatipid ng storage space.

Paglikha ng Direktoryo ng Data

Ginagawa ng system ang direktoryo ng pribadong data ng app sa /data/data/[package-name]/ (o /data/user/0/[package-name]/ sa mga multi-user na device). Ang direktoryo na ito ay pagmamay-ari ng isang natatanging Linux UID na nakatalaga sa app, na tinitiyak na walang ibang app ang makaka-access dito nang walang mga pribilehiyo sa ugat.

Hakbang 7: Pag-optimize ng DEX

Ang hakbang na ito ay kung saan binago ng Android ang bytecode ng app sa isang format na na-optimize para sa partikular na hardware ng device. Ang proseso ay makabuluhang nagbago sa kasaysayan ng Android:

Ang Dalvik Era (Android 4.4 at mas luma)

Ang orihinal na Dalvik virtual machine ay gumamit ng Just-In-Time (JIT) compilation. Sa panahon ng pag-install, ang classes.dex file ay na-optimize sa isang ODEX file na naglalaman ng na-verify at na-optimize na bytecode. Ito ay medyo mabilis ngunit nangangahulugan na ang app ay tumakbo nang mas mabagal sa runtime dahil karamihan sa mga code ay binibigyang-kahulugan pa rin.

ART na may AOT (Android 5.0 hanggang 6.0)

Pinalitan ng Android Runtime (ART) ang Dalvik at ipinakilala ang Ahead-Of-Time (AOT) compilation. Sa panahon ng pag-install, ang buong DEX bytecode ay pinagsama-sama sa native machine code. Pinabilis nito ang pagtakbo ng mga app ngunit makabuluhang pinataas ang oras ng pag-install at paggamit ng storage. Ang ilang mga app ay tumagal ng ilang minuto upang mai-install.

Compilation na Ginagabayan ng Profile (Android 7.0+)

Gumagamit ang modernong Android ng hybrid na diskarte. Sa panahon ng pag-install, tanging mga kritikal na startup path ang pinagsama-sama. Habang pinapatakbo ng user ang app, kinokolekta ng system ang mga profile ng execution na tumutukoy sa mga madalas na ginagamit na code path. Sa panahon ng idle maintenance (kadalasan habang nagcha-charge magdamag), kino-compile ng system ang mga maiinit na path na ito sa native code. Binabalanse nito ang bilis ng pag-install, paggamit ng storage, at performance ng runtime.

Ang pinagsama-samang code ay nakaimbak sa /data/dalvik-cache/ o sa tabi ng APK bilang .odex, .vdex, at .art file. Naglalaman ang .vdex file ng na-verify na DEX code, ang .odex file ay naglalaman ng pinagsama-samang native code, at ang .art file ay naglalaman ng mga paunang inisyal na heap na larawan para sa mas mabilis na pagsisimula.

Hakbang 8: Pagpaparehistro ng Pahintulot

Inirerehistro ng PackageManagerService ang mga ipinahayag na pahintulot at mga bahagi ng app sa system:

• Ang Mga pahintulot sa oras ng pag-install (tulad ng INTERNET o VIBRATE ay awtomatikong ibinibigay nang walang pakikipag-ugnayan ng user).
• Ang Mga pahintulot sa runtime (tulad ng CAMERA o LOCATION ay nakarehistro ngunit hindi ipinagkaloob). Dapat hilingin ng app ang mga ito sa runtime.
• Ang Mga filter ng layunin ay nakarehistro upang malaman ng system kung aling mga app ang maaaring pangasiwaan kung aling mga aksyon (tulad ng pagbubukas ng URL o pagbabahagi ng nilalaman).
• Ang Mga tagapagbigay ng nilalaman ay nakarehistro sa kanilang mga awtoridad upang matanong sila ng ibang mga app.

Hakbang 9: Pagsasama ng System

Ang mga huling hakbang ay isinasama ang app sa Android system:

• Pag-update ng database ng package: Ang database ng package ng system (/data/system/packages.xml ay ina-update kasama ang impormasyon ng bagong app, kasama ang nakatalagang UID, mga pahintulot, at mga deklarasyon ng bahagi nito).
• Notification ng launcher: Inaabisuhan ang home screen launcher tungkol sa bagong app upang maipakita nito ang icon ng app.
• Broadcast: Nagpapadala ang system ng PACKAGE_ADDED broadcast, na nagpapahintulot sa iba pang mga app na tumugon sa bagong pag-install (halimbawa, ang mga backup na app ay maaaring mag-iskedyul ng backup).
• Konteksto ng SELinux: Ang mga file ng app ay may label na may naaangkop na konteksto ng seguridad ng SELinux batay sa target na bersyon ng SDK nito at ipinahayag na mga pahintulot.

Bakit Nabigo ang mga Pag-install

Ang pag-unawa sa pipeline ng pag-install ay nakakatulong sa pag-diagnose ng mga karaniwang pagkabigo:

• "Error sa pag-parse": Ang APK ay sira, hindi kumpleto, o may maling pormang manifest. Madalas itong nangyayari sa mga hindi kumpletong pag-download o hindi wastong na-convert na mga file.
• "Hindi naka-install ang app" (signature mismatch): Sinusubukan mong mag-update ng app gamit ang APK na nilagdaan ng ibang key. Dapat mo munang i-uninstall ang kasalukuyang bersyon.
• "Hindi sapat na storage": Walang sapat na espasyo para sa APK, mga na-extract na library, at DEX optimization output. Ang aktwal na espasyong kailangan ay karaniwang 2-3x ang laki ng APK.
• "Ang package ay sumasalungat sa umiiral na package": Parehong pangalan ng package ngunit magkaibang lagda. Karaniwan kapag lumilipat sa pagitan ng Play Store at mga naka-sideload na bersyon.
• Na-block ang pag-downgrade ng bersyon: Bilang default, pinipigilan ng Android ang pag-install ng mas lumang bersyon kaysa sa mas bago. Maaaring i-override ito ng ADB sa adb install -d.

Hatiin ang Pag-install ng APK

Kapag nag-i-install ng mga split APK (mula sa App Bundles), bahagyang naiiba ang proseso. Gumagamit ang system ng pag-install batay sa session API:

1. Isang bagong sesyon ng pag-install ay nilikha
2. Ang bawat hating APK ay isinusulat sa session
3. Nakatuon ang session, na nagti-trigger sa buong pipeline ng pag-verify
4. Ang lahat ng mga split ay dapat na may katugmang mga pangalan ng package, bersyon code, at signing certificate

Ito ang mekanismong ginagamit ng mga installer at tool ng XAPK tulad ng aming APKS sa APK merger para pangasiwaan ang mga multi-file na pag-install.

Pag-install sa pamamagitan ng ADB

Kapag ginamit mo ang adb install, nilalampasan ng proseso ang graphical installer ngunit sinusunod ang parehong panloob na pipeline. Nakikipag-ugnayan ang ADB sa serbisyo ng manager ng package sa pamamagitan ng koneksyon sa socket. Sinusuportahan nito ang mga karagdagang flag na hindi magagamit sa pamamagitan ng GUI:

• -r: Palitan ang kasalukuyang app (payagan ang muling pag-install)
• -d: Payagan ang pag-downgrade ng bersyon
• -g: Ibigay kaagad ang lahat ng pahintulot sa runtime
• -t: Payagan ang pag-install ng mga test-only APK
• --install-multiple: Mag-install ng mga split APK sa isang session

Ano ang Mangyayari Sa Pag-uninstall

Para sa pagkakumpleto, narito ang mangyayari kapag inalis ang isang app:

1. Ang mga proseso ng app ay pinapatay
2. Ang APK at mga na-extract na aklatan ay tinanggal mula sa /data/app/
3. Aalisin ang direktoryo ng pribadong data ng app (maliban kung pinili ng user na panatilihin ang data)
4. Ang mga pinagsama-samang DEX cache file ay tinanggal
5. Ang database ng package ay na-update
6. Isang PACKAGE_REMOVED broadcast ang ipinadala
7. Inaalis ng launcher ang icon ng app

Tandaan na ang mga file na partikular sa app sa external na storage (/Android/data/[package]/ at /Android/obb/[package]/ ay tatanggalin din sa Android 10 at mas bago, salamat sa saklaw na pagpapatupad ng storage).

Bakit Nakakatipid ang Pag-unawa sa PackageManager sa Oras ng Pag-debug

Ang proseso ng pag-install ng Android ay isang maingat na nakaayos na pagkakasunud-sunod ng mga pagsusuri sa seguridad, pagpapatakbo ng file, at pagsasama ng system. May layunin ang bawat hakbang, mula sa pagprotekta sa mga user laban sa mga na-tamper na app hanggang sa pag-optimize ng performance para sa partikular na hardware. Kapag nabigo ang mga pag-install, kadalasang tumuturo ang error sa isang partikular na hakbang sa pipeline na ito, at ang pag-unawa sa proseso ay nakakatulong sa iyong masuri at malutas ang mga isyu nang mabilis.

Ang pag-install mula sa Play Store, pag-sideload ng APK sa pamamagitan ng kamay, at pagtulak ng build gamit ang ADB na lahat ng funnel sa pamamagitan ng parehong pinagbabatayan na pipeline, ang isa na tumitiyak na ang bawat app sa iyong device ay na-verify, nailagay nang tama, at na-optimize para sa iyong hardware.