ANDROID DEVELOPMENT FRAMEWORKS

1. Native Android Development

Android SDK (Software Development Kit)

 Provided by Google, the SDK includes all necessary tools to build Android apps:
o APIs to interact with device hardware (camera, sensors, GPS).
o Build tools like aapt, dx, adb, etc.
o Emulators for testing.
o Documentation and code samples.

Programming Languages: Kotlin / Java

 Java: The original language for Android development, widely used and supported.
 Kotlin: Now the preferred language for Android (officially supported by Google since
2017).
o Offers null safety, concise syntax, and better support for functional programming.
o Fully interoperable with Java.

Android Studio

 The official IDE, based on IntelliJ IDEA.

 Offers:
o Code editor, emulator, layout editor.
o Gradle-based build system.
o Real-time profiler, debugging tools.
o Instant Run / Hot Swap for faster builds.

2. Cross-Platform Frameworks
Flutter (by Google)

 Uses Dart language.

 Builds natively compiled apps for Android, iOS, web, and desktop.
 Offers:
o Custom and highly responsive UI widgets.
o Hot reload for quick UI testing.
o Direct access to native code via platform channels.
React Native (by Meta/Facebook)

 Uses JavaScript + React to write components.

 Apps run inside a JavaScript engine but can use native modules for performance.
 Benefits:
o Reusability of components.
o A vast ecosystem and third-party libraries.
o Some code sharing with web React projects.

Xamarin (by Microsoft)

 Uses C# and .NET to build apps for Android, iOS, and Windows.
 UI can be shared or designed separately per platform.
 Offers:
o Native API access.
o Integration with Visual Studio.
o Great for enterprise development.

Kotlin Multiplatform Mobile (KMM)

 Lets developers share business logic between Android and iOS.

 UI is still written natively (SwiftUI for iOS, XML/Jetpack Compose for Android).
 Useful for apps needing native performance but with shared codebase (e.g., data layer,
network layer).

3. Hybrid Frameworks
Ionic

 Built on Angular, but now supports React and Vue too.

 Uses Capacitor or Cordova to access native features.
 HTML, CSS, and JavaScript power the app.
 Good for fast prototyping or apps that don’t need heavy native features.

Apache Cordova

 Wraps web apps inside a native container using WebView.

 Allows access to device APIs via plugins.
 Deprecated by Adobe (PhoneGap), but still maintained in open-source.
4. Android Architecture and Key Components
Android OS Architecture (Layered Structure)

1. Linux Kernel
o Core of Android OS.
o Handles memory, process management, security, networking.
o Drivers for hardware (Wi-Fi, Bluetooth, display, etc.).
2. Native Libraries
o C/C++ libraries such as:
 WebKit (browser engine)
 SQLite (database)
 OpenGL/Skia (graphics)
 libc, Media libraries
3. Android Runtime (ART)
o Replaced Dalvik in Android 5.0+
o Compiles bytecode (DEX) into native code (AOT: Ahead-of-Time).
o Uses the Linux kernel for low-level functions like threading and memory
management.
4. Application Framework
o Java/Kotlin APIs used to develop apps.
o Provides classes to interact with:
 Activities, Services, Broadcast Receivers, Content Providers
 NotificationManager, LocationManager, etc.
5. Applications Layer
o All system and third-party apps run here.
o Built using Android SDK or other frameworks.

Android Application Components

1. Activities
o Represent a single screen with a user interface.
o Entry point for interacting with the user.
o Managed in an activity stack (back stack).
2. Services
o Run in the background for long operations.
o No UI (e.g., playing music, downloading files).
3. Broadcast Receivers
o Respond to system-wide events (e.g., battery low, boot complete).
o Can start services or activities in response.
4. Content Providers
o Manage access to shared data (contacts, media, etc.).
o Use URI-based access.
Installing and running applications on android:
What Is Android Studio?
Android Studio is like a big digital workshop where you can build Android apps. It has all the
tools, templates, and a place to write your app code.

Step 1: What You Need Before You Start

Before making an app, your computer needs:

 Java JDK: Think of it like the brain that helps your computer understand app-making
instructions.
 Android Studio: The main software where you’ll build your app.
 Enough Space & RAM: Android Studio needs about 2.5 GB of space and some memory
to run smoothly.

Step 2: Installing Android Studio (On Windows)

1. Download Android Studio from the official website.
2. You’ll get a file named something like android-studio-bundle.exe.
3. Double-click it and follow the instructions just like you install any other software (Next
→ Next → Finish).
4. It will ask you where to install things. You can just leave the default locations.
5. Make sure you have Java JDK installed, or the setup won’t continue.

Step 3: Starting Your First App Project (Hello World!)

Creating Your App

1. Open Android Studio.

2. Click “Start a new Android Studio project”.
3. Name your app Hello World.
4. Choose a default folder to save it (just leave it as is if unsure).
5. Choose the minimum version of Android your app supports (API 15 is safe—it works on
97% of devices).
6. Select Empty Activity (this means you’re starting with a blank screen).
7. Name the activity MainActivity and layout file activity_main.xml.
 8. Click Finish—Android Studio will set everything up for you.

Step 4: Create a Virtual Android Device (Emulator)

Since you might not have a real phone connected, you can use a virtual phone on your
computer.

1. Go to Tools > AVD Manager (or click the phone icon).

2. Click Create Virtual Device.
3. Choose a phone like Pixel XL and click Next.
4. Choose a version of Android (like Oreo), download if needed.
5. Click Finish.

Now you have a phone simulator ready to test your app.

▶ Step 5: Run Your App

1. Click the Run icon (a green triangle at the top).
2. Select your virtual device.
3. Android Studio will open the emulator (virtual phone).
4. You’ll see your app launch with the message “Hello World” on the screen!

Running the App on a Real Android Phone

Setup your phone:

1. Go to Settings > About phone.

2. Tap Build number 7 times until it says You’re a developer!.
3. Go to Settings > Developer options:
o Turn it ON.
o Enable USB Debugging.
o (Optional) Enable Stay awake while charging.

Plug in your phone:

1. Connect it using a USB data cable.

2. You’ll see a popup: Allow USB debugging? Tap OK.
3. Click Run in Android Studio and select your device.
 4. The app will open on your real phone!

� Understanding Activities (In Simple Words)

What is an Activity?

An Activity in Android is like a page in a book.

 Each screen you see in an app is an activity.

 For example, the login screen is one activity, and the home screen is another.
 Your app can have one or many activities.

Why is it important?

 It holds all the buttons, text, and images you see on the screen.
 In coding terms, it's where your user interface (UI) is created.

Think of it this way:

An Activity = a screen = a page in your app.

What's Inside an Activity?

Every activity has two parts:

1. Layout file (activity_main.xml) – This is like drawing the layout (where things go).
o Example: Placing a "Hello World" message in the center.
2. Java or Kotlin file (MainActivity.java) – This controls what happens when someone
uses the app (logic).

What is an AVD (Android Virtual Device)?

An AVD is a software-based Android phone or tablet that runs on your computer.

 It simulates how your app behaves on a real Android device.

 Useful for testing your app on different screen sizes, Android versions, and hardware
configurations.

Think of it as a virtual phone that lives inside your computer.

 Why Use an AVD?
 Test your app without needing a real phone.
 Simulate different devices (Pixel, Nexus, tablets, etc.).
 Try various Android versions (from Android 4.0 to Android 13+).
 Check how your app looks and performs on various screen sizes and resolutions.
 Faster setup than connecting multiple real devices.

How to Create an AVD (Step-by-Step)

✅ Prerequisites:

 You must have Android Studio installed.

 The Android Emulator and SDK components should already be set up during
installation.

Steps to Create an AVD:

1. Open Android Studio

Launch Android Studio on your computer.

2. Go to AVD Manager

 From the top menu, select:

o Tools > Device Manager (or AVD Manager on older versions).
o OR click the Device Manager icon ( ) in the toolbar.

3. Click “+ Create Device”

 A new window opens showing a list of predefined devices like:

o Pixel 6, Pixel XL, Nexus 5X, Tablet, etc.
4. Select a Hardware Profile

 Choose a device (e.g., Pixel 5).

 Click Next.

5. Choose a System Image

 Pick an Android version (e.g., Android 12.0 (S) or Android 13 (T)).

 If the image isn't downloaded, click Download.
 After the download, click Next.

6. Configure Your AVD

You can adjust:

 AVD name (e.g., “Pixel_Android12”)

 Orientation (portrait/landscape)
 RAM or device size (optional)
 Enable Device Frame, Hardware acceleration, etc.

Click Finish when ready.

7. Launch the AVD

 Back in the AVD Manager, find your device in the list.

 Click the Play (▶) icon to start the emulator.
 The virtual device will boot like a real phone.
 Once it’s ready, you can install and test your app on it.

How to Use AVD to Run Your App

1. In Android Studio, open your project.
2. Click Run > Run App or press Shift + F10.
3. Choose your AVD from the list of available devices.
4. The emulator launches, and your app appears on the virtual screen.
TYPES OF ANDROID APPLICATIONS:
1. Native Apps
 Built specifically for Android using Java or Kotlin.
 Run directly on the Android OS, with full access to device features (camera, GPS,
contacts, etc.).
 High performance, better user experience.

Examples:

 WhatsApp
 Google Maps
 Instagram (Android version)

2. Web Apps
 Apps that run through a browser and don’t require installation.
 Usually built with HTML, CSS, and JavaScript.
 Work well on both Android and iOS if properly optimized (responsive design).

Examples:

 Mobile versions of websites like:

o Twitter (mobile site)
o News portals (like CNN.com mobile)

3. Hybrid Apps
 Combination of web and native apps.
 Use web technologies (HTML, CSS, JS) but are wrapped in a native shell.
 Can access some native features using plugins (e.g., camera, GPS).
 Built using frameworks like Ionic, Apache Cordova, PhoneGap.

Examples:

 Uber (early versions)

 Instagram (uses both native and web elements)

4. Cross-Platform Apps
 One codebase runs on multiple platforms (Android, iOS).
 Built using frameworks like:
o Flutter (Dart)
o React Native (JavaScript)
o Xamarin (C#)

Examples:

 Facebook
 Skype
 Google Ads

5. Progressive Web Apps (PWAs)

 A type of web app that looks and behaves like a native app.
 Can work offline, send push notifications, and be installed on the home screen.
 Built using modern web technologies.

Examples:

 Twitter Lite
 Pinterest Lite

6. Utility Apps
 Apps that provide basic tools or services.
 Typically small, fast, and focused on solving a single problem.

Examples:

 Calculator
 Flashlight
 File Manager
 Alarm Clock
7. Game Apps
 Apps for entertainment or educational purposes through gameplay.
 Often require high performance, graphics, and sound capabilities.

Examples:

 PUBG Mobile
 Candy Crush
 Subway Surfers

8. Business Apps
 Help users perform business-related tasks or productivity functions.
 Often used by companies to manage operations.

Examples:

 Microsoft Office (Word, Excel)

 Zoom
 Trello

9. E-commerce Apps
 Used for online shopping or order tracking.
 Include features like product search, payment gateways, and order management.

Examples:

 Amazon
 Flipkart
 Myntra

10. Educational Apps

 Provide learning content, quizzes, and tutorials.
 Often include video, audio, or interactive lessons.

Examples:

 Duolingo
 Khan Academy
 BYJU’S

11. Media & Entertainment Apps

 Used for streaming, reading, watching videos, or listening to music.

Examples:

 YouTube
 Spotify
 Netflix
 Kindle

12. Travel & Navigation Apps

 Help users with maps, directions, and travel planning.

Examples:

 Google Maps
 Uber
 Booking.com

�‍ 13. Health & Fitness Apps

 Help users track workouts, calories, heart rate, or offer guided meditation.

Examples:

 Google Fit
 MyFitnessPal
 Headspace
Best practices in Android programming:
1. Organize Your Code Properly
Just like organizing your room or files, your code should also be neat and easy to understand.

 Break your app into parts (like UI, logic, and data).
 It makes the app easier to fix or add new features.

Think of it like having a clean kitchen where everything is in the right drawer.

2. Make the App Look Good and Work Well

 Use simple, clean layouts that look good on all screen sizes (phones, tablets).
 Follow Google's Material Design rules (colors, buttons, spacing).
 Add a dark mode so it’s easy on the eyes at night.

Make the app look modern, clean, and user-friendly.

3. Keep It Fast
 Don’t do heavy work on the screen (main) thread.
 Use background threads for loading data or downloading files.

Don’t make the app freeze — keep it smooth.

4. Use the Right Tools

Use Google's own tools called Jetpack. They help build apps easily and safely.

 Room → for saving data

 ViewModel → to keep screen data safe
 LiveData → to update the screen when data changes
 Navigation → to move between screens

Jetpack is like a toolbox full of ready-made, trusted tools.

 5. Keep User Data Safe
 Don’t store passwords or API keys in the code.
 Use encryption or Android’s Keystore.
 Always use HTTPS for internet connections.

Protect your users like locking your house.

6. Use the Internet Wisely

 Check if the phone has internet before making network calls.
 Handle errors like “No internet” or “Server error” gracefully.

Don’t let the app crash if the Wi-Fi is off!

7. Test Your App

 Check that your app works by writing tests.
 Test different situations: no internet, phone rotation, empty list, etc.
 Try it on different screen sizes.

Like checking a product before selling it.

8. Name Things Clearly

 Use clear names like LoginActivity, UserProfile, etc.
 Don’t name things like abc123 or x1y2.

Good names = better teamwork and easier debugging.

9. Support Multiple Languages

 Don’t write messages like “Hello” directly in code.
 Use strings.xml so it can easily be translated to other languages.
 Let people all over the world use your app!

10. Make It Small and Efficient

 Don’t include big images or unused files.
 Use tools like ProGuard or R8 to shrink your app.

Smaller apps install faster and save space on users’ phones.

11. Ask for Permissions the Right Way

 Only ask for permissions (like camera or location) when needed.
 Show a message explaining why you need it.

What is the Android Manifest File?

The AndroidManifest.xml is a very important file in every Android app. It tells the Android
system about your app — what it does, what it needs, and how it should run.

Think of it as the identity card or blueprint of your app.

Why is the Manifest File Important?

Because it:

 Describes the structure of your app

 Declares what components (activities, services, etc.) your app uses
 Requests permissions (like camera, internet, storage)
 Tells the system how to start your app
 Helps with security, performance, and compatibility

Where is it Located?
You can find it in your project at:
nginx
CopyEdit
app > manifests > AndroidManifest.xml

Key Elements of AndroidManifest.xml

Let’s break it down with simple examples.

1. <manifest>

This is the root tag. It includes:

 Package name (unique name of your app)

xml
CopyEdit
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.myfirstapp">

2. <application>

Describes the whole app and contains all components like activities, services, etc.

xml
CopyEdit
<application
android:allowBackup="true"
android:label="My First App"
android:icon="@mipmap/ic_launcher">

3. <activity>

Each screen in your app is an activity. You must tell the system which ones exist.

xml
CopyEdit
<activity android:name=".MainActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

This makes MainActivity the screen that opens first when the app launches.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"

package="com.example.helloworld">

<uses-permission android:name="android.permission.INTERNET" />

<application

android:allowBackup="true"

android:label="Hello World"

android:icon="@mipmap/ic_launcher">

<activity android:name=".MainActivity">

<intent-filter>

<action android:name="android.intent.action.MAIN"/>

<category android:name="android.intent.category.LAUNCHER"/>

</intent-filter>

</activity>

</application>

</manifest>

What Is Resource Externalization?

Externalizing resources means separating static data (like strings, colors, dimensions, styles,
images, etc.) from your application logic (Java/Kotlin/Swift code). These are stored in dedicated
resource files instead of being hardcoded.

Benefits of Externalizing Resources

 1. Maintainability: Easier to update values without touching the core logic.
2. Localization: Allows the app to support multiple languages by simply providing
translations.
3. Consistency: Centralized styles and themes promote a uniform look.
4. Scalability: Easier to add new UI components or themes.
5. Reusability: Values can be reused across layouts or components.

Key Resource Types (Android-Focused)

Resource Type Purpose

strings.xml Text strings (UI labels, messages)
colors.xml Color values used in the app
dimens.xml Dimensions like margins, padding, text sizes
styles.xml Style definitions (font, text appearance)
themes.xml Application themes (light, dark, custom themes)
menu.xml Menu items and structure
layouts/*.xml UI layout definitions
drawables/ Images and XML-based shapes
mipmap/ App icons (various resolutions)

Example (Android)

strings.xml

xml
CopyEdit
<resources>
<string name="app_name">MyApp</string>
<string name="welcome_message">Welcome to MyApp!</string>
</resources>

colors.xml

xml
CopyEdit
<resources>
<color name="primaryColor">#6200EE</color>
<color name="accentColor">#03DAC5</color>
</resources>

styles.xml

xml
CopyEdit
<resources>
<style name="AppTheme"
parent="Theme.MaterialComponents.DayNight.DarkActionBar">
<item name="colorPrimary">@color/primaryColor</item>
<item name="colorAccent">@color/accentColor</item>
</style>
</resources>

menu/main_menu.xml

xml
CopyEdit
<menu xmlns:android="http://schemas.android.com/apk/res/android">
<item
android:id="@+id/action_settings"
android:title="@string/menu_settings" />
</menu>

Externalization in iOS (Swift)

iOS also supports localization and resource management but does it slightly differently:

 Localizable.strings for string localization.

 Asset Catalog for images and colors.
 .xib or .storyboard files for layouts.
 Themes are often handled programmatically or via asset catalogs.

Best Practices

1. Always use resource references (e.g., @string/welcome_message) instead of

hardcoding.
2. Group similar resources into appropriately named files (e.g., colors.xml,
dimens.xml).
3. Use themes and styles for consistent UI design.
4. Utilize localization tools (res/values-<locale> in Android) for multi-language
support.
5. Automate resource management in large projects using tools like Gradle or localization
platforms (e.g., Lokalise, Crowdin).
app/

└── src/

└── main/

├── java/ → Java/Kotlin code

├── res/ → Resources (externalized assets)

│ ├── layout/ → XML layout files (UI screens)

│ ├── menu/ → XML menu files (for toolbars, navigation)

│ ├── values/ → Common values (strings, colors, styles, themes)

│ │ ├── strings.xml → App text labels/messages

│ │ ├── colors.xml → Color definitions

│ │ ├── dimens.xml → Dimensions (margins, font sizes, etc.)

│ │ ├── styles.xml → Reusable style definitions

│ │ ├── themes.xml → App-wide themes

│ ├── drawable/ → Images, shape XMLs, etc.

│ ├── mipmap/ → App launcher icons (various densities)

└── AndroidManifest.xml → App config (components, permissions,

etc.)

Why Device-Independent Units Matter

Mobile devices come in a wide variety of screen sizes and pixel densities. A "100-pixel" width
might look huge on one device and tiny on another. To ensure your UI looks consistent across
devices, we use density-independent units.

Key Measurement Units in Android

 Unit Meaning Use Case
dp Density-independent pixels Layout dimensions and positioning
sp Scale-independent pixels Text sizes (respects user font settings)
Avoid unless you're doing low-level
px Raw pixels
work
% (in Percent-based values (with
Flexible layouts
XML) ConstraintLayout)
in / mm /
pt
Real-world units (inches, mm, points) Rarely used in mobile apps

dp – Density-independent Pixels

 1 dp ≈ 1 pixel on a 160 dpi screen (baseline)

 On higher-density screens, Android scales dp so elements stay physically the same size
 Formula:
px = dp × (dpi / 160)

EXAMPLE:

<Button

android:layout_width="200dp"

android:layout_height="48dp"

android:text="Click me" />

No matter the screen resolution, that button will have the same physical size on different devices.

sp – Scale-independent Pixels (for text)

 Like dp, but also respects user's font size settings

 Use it only for text sizes

✅ Example:
<TextView

android:textSize="16sp"
 android:text="Hello World" />This allows users with vision impairments to increase
font size without breaking layout design.

px – Pixels (avoid when possible)

 Actual screen pixels

 Use only when absolutely necessary (e.g., bitmaps or canvas drawing)

Example: How Scaling Works on Different Screens

Let’s say you set a margin of 10dp. Here's how it translates to pixels on different densities:

Screen Density Scale Factor 10dp = ? px

ldpi (120dpi) 0.75× 7.5px
mdpi (160dpi) 1.0× 10px
hdpi (240dpi) 1.5× 15px
xhdpi (320dpi) 2.0× 20px
xxhdpi (480dpi) 3.0× 30px
xxxhdpi (640dpi) 4.0× 40px

iOS Equivalent Units

In iOS:

 Uses points instead of dp

 1 point = 1 pixel on non-Retina, 2 pixels on Retina, 3 on Super Retina
 Similar idea: layout stays the same across devices, pixels just get denser

Best Practices
✅ Use:

 dp for layout sizes and positioning

 sp for text sizes

❌ Avoid:
 Hardcoded px values
 Using real-world units like mm or in unless you're doing print-like apps