Note: you might hear of Adiantum, which is an encryption method designed for devices running Android 9 (API level 28) and higher whose CPUs lack AES instructions. Adiantum is only relevant for ROM developers or device vendors, Android does not provide an API for developers to use Adiantum from applications. As recommended by Google, Adiantum should not be used when shipping ARM-based devices with ARMv8 Cryptography Extensions or x86-based devices with AES-NI. AES is faster on those platforms.
gatekeeperdwhich is the service that exposes GateKeeper, (2) GateKeeper HAL, which is the hardware interface and (3) the TEE implementation which is the actual software that implements the GateKeeper functionality in the TEE.
user:role:type:mls_levelwhich defines which users are able to execute which types of actions on it. For example, one process may only be able to read a file, while another process may be able to edit or delete the file. This way, by working on a least-privilege principle, vulnerable processes are more difficult to exploit via privilege escalation or lateral movement.
Prior to Android 6.0 (API level 23), all permissions an app requested were granted at installation (Install-time permissions). From API level 23 onwards, the user must approve some permissions requests during runtime (Runtime permissions).
res/xml/network_security_config.xmlfile in the application.
/data/data/[package-name]. This directory holds the app's data. Linux directory permissions are set such that the directory can be read from and written to only with the app's unique UID.
/data/datafolder. For example, we can see that Google Chrome and Calendar are assigned one directory each and run under different user accounts:
u0_a188. If the permissions an app requested are granted, the corresponding group ID is added to the app's process. For example, the user ID of the app below is 10188. It belongs to the group ID 3003 (inet). That group is related to android.permission.INTERNET permission. The output of the
idcommand is shown below.
Zygotestarts up during Android initialization. Zygote is a system service for launching apps. The Zygote process is a "base" process that contains all the core libraries the app needs. Upon launch, Zygote opens the socket
/dev/socket/zygoteand listens for connections from local clients. When it receives a connection, it forks a new process, which then loads and executes the app-specific code.
startServicemethod. Though these processes aren't directly visible to the user, they are generally things that the user cares about (such as background network data upload or download), so the system will always keep such processes running unless there's insufficient memory to retain all foreground and visible processes.
onCreatehandler is called when the app process is first created. Other callback methods include
onCreatemanager is overridden by the app developers. This is how most user interface components are declared and initialized.
onDestroymay be overridden when resources (like network connections or connections to databases) must be explicitly released or specific actions must occur when the app shuts down.
addServiceand retrieved by name with the static
startActivity. The intent describes the activity and carries necessary data.
android:exportedattribute. As at least one filter was defined, the default value will be set to "true". In absence of any filters, it will be set to "false".
android:priorityattribute as well as programmatically via the
IntentFilter.setPrioritymethod. However, note that receivers with the same priority will be run in an arbitrary order.
LocalBroadcastManager). They can be used to make sure intents are received from the internal app only, and any intent from any other app will be discarded. This is very useful for improving security and the efficiency of the app, as no interprocess communication is involved. However, please note that the
LocalBroadcastManagerclass is deprecated and Google recommends using alternatives such as
CONNECTIVITY_ACTIONbroadcast unless they register their Broadcast Receivers with
Context.registerReceiver(). The system does not send
ACTION_NEW_VIDEObroadcasts as well.
Context.registerReceiverare not affected by this limitation.
NETWORK_STATE_CHANGED_ACTIONbroadcast doesn't receive information about the user's location or personally identifiable data.
META-INF/MANIFEST.MF. All files must be signed with a common certificate. This scheme does not protect some parts of the APK, such as ZIP metadata. The drawback of this scheme is that the APK verifier needs to process untrusted data structures before applying the signature, and the verifier discards data the data structures don't cover. Also, the APK verifier must decompress all compressed files, which takes considerable time and memory.
<apk name>.apk.idsig. Remember to specify it using the
--v4-signature-fileflag when verifying a v4-signed APK with
keytoolcommand. The following command creates a RSA key pair with a key length of 2048 bits and an expiry time of 7300 days = 20 years. The generated key pair is stored in the file 'myKeyStore.jks', which is in the current directory):
[SDK-Path]/build-tools/[version]. For API 24.0.2 and below, you can use 'jarsigner', which is part of the Java JDK. Details about the whole process can be found in official Android documentation; however, an example is given below to illustrate the point.
zipaligntool should always be used to align the APK file before distribution. This tool aligns all uncompressed data (such as images, raw files, and 4-byte boundaries) within the APK that helps improve memory management during app runtime.
Zipalign must be used before the APK file is signed with apksigner.