Android Full Screen Display Modes and System Permission Architecture

Review of Fundamental Android Concepts and Design Patterns

• Core Android Context Types:

  • Activity Context: Bound directly to the lifecycle of an individual Activity component.

  • Application Context: Bound to the lifecycle of the overall Application process.

• The Adapter Design Pattern:

  • Problem Solved: Converts the interface of a class into another interface expected by clients, enabling classes with incompatible interfaces to collaborate seamlessly.

  • Key Participating Classes:

  • Target: Defines the domain-specific interface that the Client uses.

  • Adaptee (or Service): Defines the existing interface that requires adaptation.

  • Adapter: Adapts the interface of Adaptee to the Target interface.

  • Client: Collaborates with objects conforming to the Target interface.

  • Generalization and Abstraction: While writing design pattern implementations in code often feels intuitive, formalizing them into defined patterns can appear to overcomplicate basic logic. However, this abstraction is critical to generalize solutions across diverse development contexts and architectural frameworks.

Core Components of the Android Display

• Primary Display Regions on Android Devices:

  • Status Bar:

  • Position: Located at the absolute top of the device screen.

  • Functionality: Displays operating system information including battery power, cellular/Wi-Fi signal strength, system clock time, and notification icons.

  • Ownership: Governed directly by the operating system (OS).

  • Action Bar:

  • Position: Positioned near the top of the layout, below the status bar.

  • Functionality: Displays the application title, context-specific navigation, and app action controls.

  • Ownership: Managed as part of the application component itself. Default modern themes (themes.xml) hide the Action Bar, but it can be toggled programmatically.

  • Navigation Bar:

  • Position: Located at the bottom of the device screen.

  • Functionality: Contains hardware or software system navigation controls, including Back, Home, and Recent Apps/Overview buttons.

  • Ownership: Governed directly by the operating system. Visibility and presence vary across physical hardware and virtual emulators.

• Operational Trade-offs of Full Screen Modes:

  • Full screen visibility grants maximum layout real estate to the application by hiding OS and app bars.

  • Hiding the status bar or navigation bar deprives users of system controls and contextual awareness.

  • Best Practice Guideline: Full screen execution should be used exclusively when necessary for core user experience (e.g., media playback, gaming, digital painting) rather than solely to maximize display space.

Programmatic Control of Full Screen Display Modes

• Hiding Application versus Operating System UI Components:

  • Action Bar Removal:

  • Action Bar is an application component, accessed via AppCompatActivity using getSupportActionBar().

  • Programmatically hidden by calling actionBar.hide().

  • Status Bar and Navigation Bar Removal:

  • Status and Navigation bars are OS components, controlled via the Decor View using getWindow().getDecorView().setSystemUiVisibility(int visibility).

  • View.SYSTEM_UI_FLAG_FULLSCREEN: Hides the status bar. Despite the flag name FULLSCREEN, the navigation bar remains visible when this flag is used alone.

  • View.SYSTEM_UI_FLAG_HIDE_NAVIGATION: Hides the navigation bar.

• Combining Flags using Bitwise Logic:

  • Executing setSystemUiVisibility() sequentially with distinct flags causes subsequent calls to overwrite prior configurations.

  • Multiple UI flags must be combined into a single integer using the Bitwise OR (|) operator.

• Bitwise OR Logic and Truth Table:

  • Operates on binary bit positions, returning $1$ (true) if at least one input bit is $1$ (true).

  • Bitwise OR Truth Table:

  • Input A = $0$, Input B = $0$ $\rightarrow$ Output = $0$

  • Input A = $0$, Input B = $1$ $\rightarrow$ Output = $1$

  • Input A = $1$, Input B = $0$ $\rightarrow$ Output = $1$

  • Input A = $1$, Input B = $1$ $\rightarrow$ Output = $1$

System UI Visibility Modes

• Lean Back Mode:

  • Target Use Case: Media consumption applications where interaction is passive, such as video playback.

  • Operational Behavior: Hides system bars to offer full screen viewing. Tapping anywhere on the screen immediately restores all system bars.

  • Flag Implementation: java int uiOptions = View.SYSTEM_UI_FLAG_FULLSCREEN | View.SYSTEM_UI_FLAG_HIDE_NAVIGATION; getWindow().getDecorView().setSystemUiVisibility(uiOptions);     

• Immersive Mode:

  • Target Use Case: Applications with active user interaction across the display, such as games, image galleries, or paginated book readers.

  • Operational Behavior: Screen taps do not restore system bars. System bars reappear only when the user swipes inward from any screen edge containing a hidden system bar.

  • Flag Implementation: java int uiOptions = View.SYSTEM_UI_FLAG_FULLSCREEN | View.SYSTEM_UI_FLAG_HIDE_NAVIGATION | View.SYSTEM_UI_FLAG_IMMERSIVE; getWindow().getDecorView().setSystemUiVisibility(uiOptions);     

• Sticky Immersive Mode:

  • Target Use Case: Apps with frequent edge-swiping operations, such as fast-paced mobile games or digital drawing tools.

  • Operational Behavior: Swiping from a hidden edge displays semi-transparent system bars. The bars automatically fade out after a few seconds of inactivity or as soon as the user taps inside the application area.

  • Flag Implementation: java int uiOptions = View.SYSTEM_UI_FLAG_FULLSCREEN | View.SYSTEM_UI_FLAG_HIDE_NAVIGATION | View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY; getWindow().getDecorView().setSystemUiVisibility(uiOptions);     

• Full Screen Implementation (Combined Action Bar and Immersive Mode): ```java ActionBar actionBar = getSupportActionBar(); if (actionBar != null) { actionBar.hide(); }

  int uiOptions = View.SYSTEM_UI_FLAG_FULLSCREEN | View.SYSTEM_UI_FLAG_HIDE_NAVIGATION | View.SYSTEM_UI_FLAG_IMMERSIVE;

  getWindow().getDecorView().setSystemUiVisibility(uiOptions);   ```

• Monitoring System UI Visibility Changes:

  • Applications can register callbacks to listen for system visibility changes and adjust internal layout elements dynamically when system bars appear or disappear.

Practical Step-by-Step Display Mode Demonstration

• Restoring the Default Action Bar in Layout Themes:

  • Open res/values/themes.xml and remove the default style configurations that enforce NoActionBar.

  • Rebuild the application to verify the appearance of the top Action Bar showing the application name.

• Implementing Hiding Logic inside onCreate():

  • Ensure UI configuration code is placed inside the onCreate() activity lifecycle method.

  • Retrieve the Action Bar via getSupportActionBar() and execute actionBar.hide() to remove it programmatically.

• Testing Individual System Flags:

  • Status Bar Test: Setting View.SYSTEM_UI_FLAG_FULLSCREEN removes the status bar while maintaining the navigation bar.

  • Navigation Bar Test: Setting View.SYSTEM_UI_FLAG_HIDE_NAVIGATION removes the navigation bar while leaving the status bar visible.

• Verifying Interactive Full Screen Modes:

  • Lean Back Verification: Combining SYSTEM_UI_FLAG_FULLSCREEN and SYSTEM_UI_FLAG_HIDE_NAVIGATION hides both bars. A single screen tap restores visibility.

  • Immersive Verification: Adding SYSTEM_UI_FLAG_IMMERSIVE keeps bars hidden upon screen taps; an edge swipe restores visibility.

  • Sticky Immersive Verification: Replacing with SYSTEM_UI_FLAG_IMMERSIVE_STICKY displays semi-transparent bars upon edge swipe, which automatically fade away after brief inactivity.

Android Security Model and App Isolation

• Multi-functional Smartphone Capabilities:

  • Modern mobile devices consolidate numerous distinct physical tools into a single platform (e.g., cellular connectivity, SMS messaging, torch/flashlight, camera, internet, mobile games, GPS navigation, motion sensors).

• Application Interoperability versus Security Threats:

  • Android applications interoperate with system resources and third-party tools to maximize functionality.

  • Security Risks: Users cannot unconditionally trust third-party application developers. Developers may introduce vulnerabilities, engage in unauthorized data harvesting, or construct malicious code.

  • Data Collection Trade-offs:

  • Positive Impacts: Aggregated GPS location tracking powers real-time traffic updates in navigation tools (e.g., Google Maps dynamic rerouting around roadblocks or traffic jams).

  • Privacy & Commercial Concerns: Background tracking enables targeted advertising (e.g., immediate display ads triggered by user conversations or search histories), potential private data leaks, device exploitation, and financial fraud.

• Linux Kernel-Level Application Sandbox:

  • Sandboxing: Every Android app is completely isolated inside its own execution sandbox.

  • Linux Account Isolation: Each application is assigned a unique, distinct Linux user account and user ID (UID).

  • File System Access Limits: Applications are prevented from directly inspecting or modifying files belonging to other applications.

  • Non-Root Execution: Applications execute with standard user privileges rather than administrative (root) privileges, preventing unauthorized modifications to the core operating system.

Android Permission Architecture and Dynamic Runtime Handling

• Permission Fundamentals:

  • System permissions protect access to sensitive user data (e.g., contacts, SMS) and critical system features (e.g., camera, location sensors, internet connectivity).

  • Identification: Each permission is identified by a unique string label (e.g., android.permission.CAMERA).

  • Manifest Declarations: All permissions required by an application must be explicitly declared in AndroidManifest.xml using <uses-permission> elements.

• Evolution of Android Permission Handling:

  • Pre-Android $6.0$ (API Level $23$) Model: Install-time permissions. Users were required to accept all requested permissions in a single batch before installing an app. Denying permissions prevented installation.

  • Android $6.0$ (API Level $23$) and Newer Model: Runtime dynamic permissions. Users grant or reject individual sensitive permissions dynamically while using the app as specific features require them.

• Permission Categories:

  • Normal Permissions:

  • Characteristics: Cover actions outside the app's isolated sandbox with minimal threat to user privacy or system stability.

  • Examples: Setting alarms (SET_ALARM), setting time zones (SET_TIME_ZONE), viewing network state (ACCESS_NETWORK_STATE).

  • Management: Automatically granted by the OS at install time. Must still be declared in AndroidManifest.xml.

  • Dangerous Permissions:

  • Characteristics: Grant access to private user data or sensitive hardware features that impact system operations.

  • Examples: Camera access, reading/writing contacts, reading SMS messages, fine/coarse GPS location.

  • Management: Require explicit approval from the user at runtime. Feature calls fail if permission is withheld.

• Runtime Permission Handling Workflow:

  1. Declare the permission in AndroidManifest.xml using <uses-permission>.

  2. Check permission status prior to feature execution using ContextCompat.checkSelfPermission().

  3. Request user authorization using ActivityCompat.requestPermissions() if permission is ungranted.

  4. Handle user approval or denial within the onRequestPermissionsResult() callback before executing protected application logic.