Mobile Security Platform

Components of an Android Application


Activities Activities are presentation layer of our applications. The UI of our application is built around one or more extensions of the Activity class. By using Fragments and Views, activities set the layout and display the output and also respond to the user’s actions. An activity is implemented as a subclass of class Activity. An activity represents a single screen with a user interface,in-short Activity performs actions on the screen. For example, an email application might have one activity that shows a list of new emails, another activity to compose an email, and another activity for reading emails. If an application has more than one activity, then one of them should be marked as the activity that is presented when the application is launched.
An activity is implemented as a subclass of Activity class as follows 
public class MainActivity extends Activity {
    }
Services Services are like invisible workers of our app. These components run at the backend, updating your data sources and Activities, triggering Notification, and also broadcast Intents. They also perform some tasks when applications are not active. A service can be used as a subclass of class Service: 
  public class MyService extends Service {
        }
As every Android app runs in its own sandbox environment and cannot affect other apps by default but two apps can have same Linux User ID and can also share the same Dalvik VM if they are signed with the same Certificates.

Intents are two types: Explicit and Implicit

Explicit: you specifies the target’s full package name
Implicit: the intent just describes tye type of action to perform.
Intents can also carry data between apps or component, similar to how GET/POST requests are used in HTTP communications. Intent is basically a message that is passed between components (such as Activities, Services, Broadcast Receivers, and Content Providers). So, it is almost equivalent to parameters passed to API calls

To be simple Intent can be used:
-To start an Activity, typically opening a user interface for an app
-As broadcasts to inform the system and apps of changes
-To start, stop, and communicate with a background service
-To access data via ContentProviders
-As callbacks to handle events
An intent is an abstract description of an operation to be performed. It can be used with startActivity to launch an Activity, broadcastIntent to send it to any interested BroadcastReceiver components, and startService (Intent) or bindService(Intent, ServiceConnection, int) to communicate with a background Service.
Intent-filters are a component in the AndroidManifest.xml file that defines types of intents an activity, service, or Broadcast Receiver can respond or handle.
Pending Intents These allow other applications to take actions on behalf of your application, using your app’s identity and permissions. Constructing a Pending Intent it should be specified an intent and the action to perform. If the declared intent isn’t Explicit (doesn’t declare which intent can call it) a malicious application could perform the declared action on behalf of the victim app. Moreover, if an action isn’t specified, the malicious app will be able to do any action on behalf the victim.
Broadcast intent is a type of message that allows communication between different components of an Android application. They are a mechanism for sending events or messages within the Android system. Broadcast intents can be received by multiple apps. However, from API version 14, it’s possible to specify the app that should receive the message using Intent.set Package.
Broadcasts are commonly used for various purposes, such as notifying the system or other apps about specific events, triggering background processes, or allowing different components of an app to communicate. It’s important to note that starting from Android 8.0 (Oreo), implicit broadcasts are generally restricted to improve system security and performance. Android 8.0 or higher must use explicit broadcasts when communicating with components within their own apps.
Broadcast Recievers are the components which listen for Broadcast Intents sent from application. They are meant to respond to system-wide events in the background. Broadcast receivers are the listeners. system can deliver these events even to apps that are currently not running. They are defined in AndroidManifest file in a receiver element, or dynamically defined using the registerReciever method. Receivers is used to process input from other apps. for securing it, you can validate the data received from other apps or potentially limiting which app’s broadcasts your reciever accepts.
When statically defined you can limit which app’s broadcasts you accept through the use of permissions within the reciever element defined in the AndroidManifest.xml. When dynamically defining a receiver you pass the permission as an argument to the registerReciever method. In the manifest you can limit the broadcasts you accept through the use of permissions within the receiver element. When dynamically defined you can pass the permission to the registerReceiver method. Broadcast Receivers simply respond to broadcast messages from other applications or from the system. For example, applications can also initiate broadcasts to let other applications know that some data has been downloaded to the device and is available for them to use, so this is broadcast receiver who will intercept this communication and will initiate appropriate action.
A broadcast receiver is implemented as a subclass of BroadcastReceiver class and each message is broadcaster as an Intent object. 
public class MyReceiver  extends  BroadcastReceiver {
            public void onReceive(context,intent){}
            }
Sticky Broadcasts This kind of Broadcasts can be accessed long after they were sent. These were deprecated in API level 21 and it’s recommended to not use them. They allow any application to sniff the data, but also to modify it. If you find functions containing the word “sticky” like sendStickyBroadcast or sendStickyBroadcastAsUser, check the impact and try to remove them. Contet Providers are the term that is used for Android apps share structured data such as relational databases (SQLite). Data is supplied from one application to others on request by a component known as a Content provider. Probably most of the Content Providers are used as interface for a database. They manage a shared set of app data. they provide high level API to access data so that other apps and services can query/interact with it. You can store the data in the file system, an SQLite database, on the web, or any other persistent storage location your app can access. A Content provider component supplies data from one application to others on request. Such requests are handled by the methods of the ContentResolver class. The data may be stored in the file system, the database or somewhere else entirely. A content provider is implemented as a subclass of ContentProvider class and must implement a standard set of APIs that enable other applications to perform transactions. 
 public class MyContentProvider extends  ContentProvider {
        public void onCreate(){}
        }



References:

Geeks for Geeks
OWASP Mobile Application Security
Home

Search