Android Programming (IT-606) - Unit 1 Short Notes

1.1 Introduction to Android & Mobile Ecosystem

What is Android?

• Open-source, Linux-based mobile operating system stack.

• Primarily designed for touchscreen mobile devices (smartphones, tablets).

• Owned by Google; maintained via Android Open Source Project (AOSP).

• Google Mobile Services (GMS) is proprietary Google software (Play Store, GMS apps) licensed separately from AOSP.

History & Evolution (Key Milestones)

• 2008: Android 1.0 (API 1) released.

• 2009: Android 1.5 "Cupcake" → Widgets, on-screen keyboard.

• 2010: Android 2.3 "Gingerbread" → Native SIP, gaming improvements.

• 2011: Android 3.0 "Honeycomb" → Tablet-specific UI.

• 2014: Android 5.0 "Lollipop" → Material Design, ART runtime.

• 2016: Android 7.0 "Nougat" → Multi-window, Doze.

• 2023: Android 14 → Improved privacy, battery life.

Android Platform Architecture (Layered Model)

[[DIAGRAM: CANVAS: Draw a 5-layer pyramid from bottom to top:

1. Linux Kernel (Hardware abstraction, drivers, security)

2. Hardware Abstraction Layer (HAL) (Standardized hardware interfaces)

3. Native C/C++ Libraries (SQLite, OpenGL ES, WebKit, Media)

4. Android Runtime (ART) (AOT & JIT compilation, garbage collection)

5. Application Framework (Java/Kotlin APIs: Activity Manager, View System, etc.)

Top: Applications (System & User apps)]]

• Linux Kernel: Core hardware abstraction (display, camera, audio), driver model, security (SELinux), memory management.

• Hardware Abstraction Layer (HAL): Provides standard interfaces for hardware vendors; allows Android OS to interact with device-specific hardware without modifying core OS.

• Native C/C++ Libraries: Implement core functionalities (e.g., libc, SQLite, OpenGL ES, WebKit for web rendering, Media Framework for audio/video).

• Android Runtime (ART): Replaced Dalvik VM. Uses Ahead-Of-Time (AOT) compilation during install (.oat files) + Just-In-Time (JIT) for hot code paths. Improves performance and battery life.

• Application Framework: High-level Java/Kotlin APIs for app development. Key managers: ActivityManager, ViewSystem, ResourceManager, NotificationManager.

• Applications: System apps (Phone, Contacts) and user-installed apps.

1.2 Setting Up the Development Environment

Prerequisites

• Java Development Kit (JDK): Version 11 or 17 (for recent Android Studio). Set JAVA_HOME environment variable.

Android Studio (Official IDE)

• Based on IntelliJ IDEA.

• Key Components:

  • SDK Manager: Downloads SDK platforms, tools, system images.

  • AVD Manager: Creates/manages virtual devices.

  • Gradle Build System: Dependency management, build automation (build.gradle files).

  • Project Structure: app/src/main/ (code, resources, manifest), build.gradle (module & project level).

Android SDK (Software Development Kit)

• SDK Platforms: Android API levels (e.g., API 34 = Android 14).

• SDK Tools:

  • platform-tools (ADB, Fastboot)

  • build-tools (aapt, dx, zipalign)

  • emulator

  • cmdline-tools

Android Virtual Device (AVD) / Emulator

• Creating AVD: Select device profile, system image (x86 for speed), configure RAM/VM heap.

• Emulator vs. Physical Device:

  | Emulator | Physical Device | |---|---| | Slower (unless x86 + HAXM/KVM) | Faster, real-world performance | | Easy to test multiple configurations | Limited to one device at a time | | No hardware sensors (GPS, accelerometer) by default | Full sensor access | | Good for initial testing, UI layout | Essential for final testing, battery/thermal |

• Common Emulator Controls: Rotate, GPS location injection, network speed, battery level.

• Troubleshooting: Ensure HAXM (Intel) or KVM (AMD) installed; enable virtualization in BIOS; use x86 images.

[!TIP] Exam Tip: Know the difference between AOSP (open-source) and GMS (proprietary Google services). Also, ART's AOT vs. JIT compilation is frequently asked.

1.3 Anatomy of an Android Application

Project Structure in Android Studio

app/

├── src/

│   ├── main/

│   │   ├── java/          # Kotlin/Java source files

│   │   ├── res/           # Resources (layouts, values, drawables)

│   │   ├── AndroidManifest.xml

│   │   └── assets/        # Raw files (not compiled into R)

├── build.gradle (Module-level)  # App-specific config, dependencies

└── build.gradle (Project-level) # Global config, repositories

AndroidManifest.xml File

• Purpose: Declares all app components, permissions, hardware features, and API level requirements to the Android system.

• Essential Elements:

  
  <manifest package="com.example.app">
  
      <uses-permission android:name="android.permission.INTERNET"/>
  
      <uses-feature android:name="android.hardware.camera" android:required="false"/>
  
      <application
  
          android:icon="@mipmap/ic_launcher"
  
          android:label="@string/app_name">
  
          <activity android:name=".MainActivity">
  
              <intent-filter>
  
                  <action android:name="android.intent.action.MAIN"/>
  
                  <category android:name="android.intent.category.LAUNCHER"/>
  
              </intent-filter>
  
          </activity>
  
          <service android:name=".MyService"/>
  
          <receiver android:name=".MyReceiver"/>
  
          <provider android:name=".MyProvider"
  
                    android:authorities="com.example.app.provider"/>
  
      </application>
  
  </manifest>
  
  

• Permissions:

  | Type | Definition | Example | |---|---|---| | Normal | Low-risk, auto-granted | INTERNET, ACCESS_NETWORK_STATE | | Dangerous | User privacy/data risk; runtime request needed (API 23+) | CAMERA, READ_CONTACTS, ACCESS_FINE_LOCATION | | Signature | Only granted if signing certificates match (system apps) | SIGNATURE protection level |

• Intent Filters: Declare component capabilities (<action>, <category>, <data>). Main/Launcher activity must have MAIN action + LAUNCHER category.

Resources (res/ directory)

• Configuration-specific resources: e.g., res/layout-land/ (landscape), res/values-fr/ (French strings). System auto-selects based on device configuration.

[!TIP] Common Pitfall: Forgetting to declare an Activity in the manifest causes ActivityNotFoundException. Also, R class is auto-generated; errors in res/ (e.g., invalid XML) break the build.

1.4 Core Application Components (The "Four Pillars")

1. Activities

• Definition: Single, focused screen with a UI. Entry point for user interaction.

• Lifecycle (CRITICAL TOPIC):

  | Callback | State | When Called | Next State | |---|---|---|---| | onCreate() | Created | First call; setContentView, init | Started | | onStart() | Started | Activity becomes visible | Resumed | | onResume() | Resumed | Activity in foreground, user interaction | (Running) | | onPause() | Paused | Another activity comes in front (partial obscuring) | Stopped | | onStop() | Stopped | Activity fully hidden | Destroyed/Restarted | | onDestroy() | Destroyed | Final cleanup; activity finishing or system kill | (Dead) | | onRestart() | Restarted | After onStop() before onStart() | Started |

• Lifecycle Flow Diagram:

  DiagramCANVAS: Draw a state diagram with circles: Created → Started → Resumed → Paused → Stopped → Destroyed. Arrows: onCreate→onStart→onResume. From Resumed: onPause→onStop→onDestroy. From Stopped: onRestart→onStart. Also show: onPause→onResume (if returns quickly), onSaveInstanceState before onStop.

• Tasks & Back Stack: Activities are organized in tasks (stack of activities). Back button pops stack. FLAG_ACTIVITY_NEW_TASK, FLAG_ACTIVITY_CLEAR_TOP manipulate stack.

2. Services

• Definition: Background component for long-running operations without UI.

• Types:

  | Started Service | Bound Service | |---|---| | startService() / startForegroundService() | bindService() | | Runs until stopSelf()/stopService() | Runs while at least one client is bound | | No direct client communication | Clients call via IBinder interface | | Use: File download, sync | Use: RPC, local service (e.g., music player controller) |

• Service Lifecycle:

  • Started: onCreate() → onStartCommand() (returns START_STICKY etc.) → onDestroy().

  • Bound: onCreate() → onBind() → onUnbind() → onDestroy().

• Foreground Services: Must show persistent notification; used for user-aware tasks (music, location tracking). Requires FOREGROUND_SERVICE permission (API 28+).

3. Broadcast Receivers

• Definition: Responds to system-wide or app-specific broadcast Intents.

• Types:

  • Static (Manifest-declared): Registered in AndroidManifest.xml. Can launch app even if not running (system delivers broadcast).

  • Dynamic (Context-registered): Registered via registerReceiver() at runtime. Only active while registering component (e.g., Activity) is alive.

• Common System Broadcasts: BOOT_COMPLETED, BATTERY_LOW, CONNECTIVITY_CHANGE (limited in API 24+), SMS_RECEIVED.

• Custom App Broadcasts: Use sendBroadcast() (normal) or sendOrderedBroadcast() (ordered). Define custom action string (e.g., "com.example.ACTION_CUSTOM").

• Background Execution Limits (API 26+): Implicit broadcasts cannot wake background apps; manifest-declared receivers for most implicit broadcasts are ignored. Use JobScheduler or explicit broadcasts.

4. Content Providers

• Definition: Manages structured data sharing between apps. Provides a secure interface (like a database "server").

• Purpose: Encapsulate data (e.g., Contacts, MediaStore) with permission control. Other apps access via ContentResolver.

• Core Classes:

  • ContentProvider: Implements query(), insert(), update(), delete(), getType().

  • ContentResolver: Client-side object to query/insert/update/delete.

  • Uri: Unique identifier for data (e.g., content://com.example.provider/table).

• CRUD Operations:

  
  // Query
  
  Cursor cursor = getContentResolver().query(uri, projection, selection, selectionArgs, sortOrder);
  
  // Insert
  
  Uri newUri = getContentResolver().insert(uri, values);
  
  

• Permissions: Declare <provider android:permission="..."> or <grant-uri-permission> for fine-grained access.

[!TIP] Exam Focus: Activity lifecycle states/callbacks are highly tested. Know the exact sequence for configuration change (onPause→onStop→onDestroy→onCreate→onStart→onResume) and multi-window (onPause→onResume if partially visible). Also, differentiate started vs. bound services and static vs. dynamic broadcast receivers.

1.5 Intents & Intent Filters

Intent

• Definition: Messaging object for requesting an action from another app component (activity, service, broadcast receiver).

• Types:

  | Explicit Intent | Implicit Intent | |---|---| | Component name explicitly set (setComponent() or class in constructor) | Only action/data/category specified; system resolves best component | | Used within same app | Used to request actions from other apps (e.g., view URL, send email) | | Example: Intent(this, DetailActivity::class.java) | Example: Intent(Intent.ACTION_VIEW, Uri.parse("https://...")) |

• Common Actions: ACTION_VIEW, ACTION_SEND, ACTION_EDIT, ACTION_DIAL.

• Data & MIME Types:

  • setData(uri) for data (e.g., content://contacts/...).

  • setType(mimeType) for type (e.g., "image/jpeg").

  • setDataAndType(uri, mimeType) for both.

• Extras: Key-value pairs for additional data (putExtra("key", value)). Retrieved via getIntent().get...Extra().

Intent Filters

• Definition: Component's capability declaration in AndroidManifest.xml for receiving implicit intents.

• Filter Elements:

  
  <intent-filter>
  
      <action android:name="android.intent.action.VIEW"/>
  
      <category android:name="android.intent.category.DEFAULT"/>
  
      <category android:name="android.intent.category.BROWSABLE"/>
  
      <data android:scheme="http" android:host="www.example.com"/>
  
  </intent-filter>
  
  

• Resolution Process:

  1. System queries all installed apps' manifest intent filters.

  2. Matches action (must match exactly).

  3. Matches category (all categories in filter must be present in intent; CATEGORY_DEFAULT required for startActivity()).

  4. Matches data (scheme, host, port, path, MIME type).

  5. If multiple matches, shows chooser (or best match if default set).

• Default Category: CATEGORY_DEFAULT is automatically added to startActivity()/startService() intents; filter must include it to be considered.

[!TIP] Common Pitfall: Implicit intent for ACTION_SEND requires setType() (e.g., "text/plain"); otherwise, no match. Also, CATEGORY_DEFAULT is often forgotten in filters, causing component not to appear in chooser.

1.6 Basic UI Components & Layouts (Introduction)

View & ViewGroup

• View: Base class for UI widgets (atomic components). Handles drawing & events.

• ViewGroup: Container for Views (and other ViewGroups). Defines layout parameters.

Common Layouts (ViewGroups)

Common Widgets (Views)

• TextView: Display text (non-editable).

• EditText: User text input (android:inputType for keyboard type).

• Button: Clickable button (android:onClick or setOnClickListener).

• ImageView: Display images (android:src).

• CheckBox: Multiple selection.

• RadioButton: Single selection (grouped in RadioGroup).

• Basic Attributes (all Views):

  • android:id (@+id/...)

  • android:layout_width/height (match_parent, wrap_content, dp)

  • android:padding, android:margin

  • android:text, android:src, android:onClick

[!TIP] Exam Tip: ConstraintLayout is the recommended layout for performance (flatter view hierarchy). Know how to create constraints (start/end/top/bottom to another view or parent). Also, dp (density-independent pixels) for layout, sp (scale-independent pixels) for font sizes.