Android
Mobile hacking wiki
Last updated
Mobile hacking wiki
Last updated
All android devices follow same architecture. Android is open source and linux based.
Read more about Android architecture: https://developer.android.com/guide/platform
APKs contain DEX files(Dalvik executable). In android java files are not executed directly rather it is first converted to dex byte code and ART converts that byte code to machine level code.
Each Android app lives in its own security sandbox, protected by the following Android security features:
The Android operating system is a multi-user Linux system in which each app is a different user.
By default, the system assigns each app a unique Linux user ID, which is used only by the system and is unknown to the app. The system sets permissions for all the files in an app so that only the user ID assigned to that app can access them.
Each process has its own virtual machine (VM), so an app's code runs in isolation from other apps.
By default, every app runs in its own Linux process. The Android system starts the process when any of the app's components need to be executed, and then shuts down the process when it's no longer needed or when the system must recover memory for other apps.
App components are the essential building blocks of an Android app. Each component is an entry point through which the system or a user can interact with your app. Some components depends on each other.
There are four types of app components:
Activities
Services
Broadcast receivers
Content providers
Activities: An activity is the entry point for interacting with the app. It represents a single screen with a user interface. For example, an email app might have one activity that shows a list of new emails, another activity to compose an email, and another activity for reading emails. Although the activities work together to form a cohesive user experience in the email app, each one is independent of the others.
A different app can start any one of these activities if the email app allows it. For example, a camera app might start the activity in the email app for composing a new email to let the user share a picture.
Services: A service is a general-purpose entry point for keeping an app running in the background for all kinds of reasons. It is a component that runs in the background to perform long-running operations or to perform work for remote processes. A service does not provide a user interface.
For example, a service might play music in the background while the user is in a different app, or it might fetch data over the network without blocking user interaction with an activity
Broadcast receivers: A broadcast receiver is a component that lets the system deliver events to the app outside of a regular user flow so the app can respond to system-wide broadcast announcements. Because broadcast receivers are another well-defined entry into the app, the system can deliver broadcasts even to apps that aren't currently running.
So, for example, an app can schedule an alarm to post a notification to tell the user about an upcoming event. Because the alarm is delivered to a BroadcastReceiver
in the app, there is no need for the app to remain running until the alarm goes off.
Many broadcasts originate from the system, like a broadcast announcing that the screen is turned off, the battery is low, or a picture is captured. Apps can also initiate broadcasts, such as to let other apps know that some data is downloaded to the device and is available for them to use.
Although broadcast receivers don't display a user interface, they can create a status bar notification to alert the user when a broadcast event occurs. More commonly, though, a broadcast receiver is just a gateway to other components and is intended to do a very minimal amount of work.
Content providers: A content provider manages a shared set of app data that you can store in the file system, in a SQLite database, on the web, or on any other persistent storage location that your app can access. Through the content provider, other apps can query or modify the data, if the content provider permits it.
For example, the Android system provides a content provider that manages the user's contact information. Any app with the proper permissions can query the content provider, such as using ContactsContract.Data
, to read and write information about a particular person.
A unique aspect of the Android system design is that any app can start another app’s component. For example, if you want the user to capture a photo with the device camera, there's probably another app that does that—and your app can use it instead of developing an activity to capture a photo yourself. You don't need to incorporate or even link to the code from the camera app. Instead, you can start the activity in the camera app that captures a photo. When complete, the photo is even returned to your app so you can use it. To the user, it seems as if the camera is actually a part of your app.
When the system starts a component, it starts the process for that app, if it's not already running, and instantiates the classes needed for the component. For example, if your app starts the activity in the camera app that captures a photo, that activity runs in the process that belongs to the camera app, not in your app's process. Therefore, unlike apps on most other systems, Android apps don't have a single entry point: there's no main()
function.
Because the system runs each app in a separate process with file permissions that restrict access to other apps, your app can't directly activate a component from another app. However, the Android system can. To activate a component in another app, you deliver a message to the system that specifies your intent to start a particular component. The system then activates the component for you.
Activate components
An asynchronous message called an intent activates three of the four component types: activities, services, and broadcast receivers. Intents bind individual components to each other at runtime. You can think of them as the messengers that request an action from other components, whether the component belongs to your app or another.
An intent is created with an Intent
object, which defines a message to activate either a specific component (an explicit intent) or a specific type of component (an implicit intent).
Before the Android system can start an app component, the system must know that the component exists by reading the app's manifest file, AndroidManifest.xml
. Your app declares all its components in this file, which is at the root of the app project directory.
The manifest does a number of things in addition to declaring the app's components, such as the following:
Identifies any user permissions the app requires, such as internet access or read-access to the user's contacts.
Declares the minimum API level required by the app, based on which APIs the app uses.
Declares hardware and software features used or required by the app, such as a camera, Bluetooth services, or a multitouch screen.
e.g.
Read more about android components here: https://developer.android.com/guide/components/fundamentals
There are two types of intents:
Explicit intents specify which application will satisfy the intent, by supplying either the target app's package name or a fully-qualified component class name. You'll typically use an explicit intent to start a component in your own app, because you know the class name of the activity or service you want to start. For example, you might start a new activity within your app in response to a user action, or start a service to download a file in the background.
Implicit intents do not name a specific component, but instead declare a general action to perform, which allows a component from another app to handle it. For example, if you want to show the user a location on a map, you can use an implicit intent to request that another capable app show a specified location on a map.
More on Intent and Intent Filters: https://developer.android.com/guide/components/intents-filters
Apps can use shared prefernces to store a few values. It's like a private database each app can use.