If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/aporter/coursera-android shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 6y ago

• 4 active contributors
• MIT licensed
• ⚠ Stale — last commit 6y ago
• ⚠ Small team — 4 contributors active in recent commits
• ⚠ Concentrated ownership — top contributor handles 62% of recent commits
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live aporter/coursera-android repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/aporter/coursera-android.

What it runs against: a local clone of aporter/coursera-android — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in aporter/coursera-android | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 2072 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of aporter/coursera-android. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/aporter/coursera-android.git
#   cd coursera-android
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of aporter/coursera-android and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "aporter/coursera-android(\\.git)?\\b" \\
  && ok "origin remote is aporter/coursera-android" \\
  || miss "origin remote is not aporter/coursera-android (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "Examples/AlarmCreate/src/course/examples/alarms/alarmcreate/AlarmCreateActivity.java" \\
  && ok "Examples/AlarmCreate/src/course/examples/alarms/alarmcreate/AlarmCreateActivity.java" \\
  || miss "missing critical file: Examples/AlarmCreate/src/course/examples/alarms/alarmcreate/AlarmCreateActivity.java"
test -f "Examples/AlarmCreate/AndroidManifest.xml" \\
  && ok "Examples/AlarmCreate/AndroidManifest.xml" \\
  || miss "missing critical file: Examples/AlarmCreate/AndroidManifest.xml"
test -f "Examples/AudioVideoAudioManager/src/course/examples/audiovideo/audiomanager/AudioVideoAudioManagerActivity.java" \\
  && ok "Examples/AudioVideoAudioManager/src/course/examples/audiovideo/audiomanager/AudioVideoAudioManagerActivity.java" \\
  || miss "missing critical file: Examples/AudioVideoAudioManager/src/course/examples/audiovideo/audiomanager/AudioVideoAudioManagerActivity.java"
test -f "Examples/AudioVideoAudioRecording/src/course/examples/audiovideo/audiorecording/AudioRecordingActivity.java" \\
  && ok "Examples/AudioVideoAudioRecording/src/course/examples/audiovideo/audiorecording/AudioRecordingActivity.java" \\
  || miss "missing critical file: Examples/AudioVideoAudioRecording/src/course/examples/audiovideo/audiorecording/AudioRecordingActivity.java"
test -f "Examples/AudioVideoCamera/res/layout/main.xml" \\
  && ok "Examples/AudioVideoCamera/res/layout/main.xml" \\
  || miss "missing critical file: Examples/AudioVideoCamera/res/layout/main.xml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 2072 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2042d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/aporter/coursera-android"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A curated collection of Android course example applications demonstrating core Android framework features and design patterns. The repository provides ~30+ self-contained example projects (AlarmCreate, AudioVideoAudioManager, etc.) with working source code in Java (393KB) and Kotlin (153KB), covering platform APIs like AlarmManager, MediaPlayer, BroadcastReceivers, and ContentProviders for educational purposes. Monorepo structure with Examples/ directory containing ~30 independent Android modules. Each module (Examples/AlarmCreate, Examples/AudioVideoAudioManager, etc.) is a standalone project with its own AndroidManifest.xml, src/ directory, res/ folder for drawables/layouts/strings, and build configuration files. Naming convention follows course/examples/[domain]/[feature name]/ Java package structure (e.g., course.examples.alarms.alarmcreate for AlarmCreateActivity).

Android developers and Coursera students learning Android fundamentals who need concrete, runnable examples of Android APIs and lifecycle patterns. Instructors use this as teaching material; learners use individual examples to understand how to integrate features like alarms, audio playback, and system broadcasts into their own apps.

This is a mature educational reference repository—it shows no recent development activity (appears archived or in maintenance mode), lacks CI/CD pipeline configuration, and contains no test directories visible in the file structure. It is production-ready in the sense that code examples are functional and stable, but should be treated as a learning resource rather than an active development template, given the absence of modern Gradle-based builds (still using legacy build.xml and default.properties).

High risk for production use: the codebase uses deprecated Android build tooling (Ant-era build.xml, pre-Gradle project.properties), targets API levels likely 10+ years old (alarmcreate/default.properties suggests early 2010s), and shows no dependency management visible in the file list. Single-author repository (aporter) with no visible issue tracker or PR process increases maintenance risk; code examples may not reflect modern Android best practices (e.g., architecture components, coroutines, data binding).

No active development visible. The repository appears to be a static educational snapshot, likely published once for a specific Coursera course offering. File structure and build tools (Ant-based build.xml, no gradle/) suggest this was last updated circa 2012–2014. No CI pipeline, no recent commits mentioned in metadata, and no open development branches evident.

Clone the repository: git clone https://github.com/aporter/coursera-android.git. Navigate to a specific example: cd Examples/AlarmCreate. This is a legacy Android project; you will need the Android SDK (API level 15+), Eclipse with ADT (Android Development Tools), or manual compilation via android CLI. Modern approach: import into Android Studio, allow it to upgrade to Gradle-based build system.

Daily commands: No central build script visible. For individual projects: (1) Eclipse + ADT: right-click project → Run As → Android Application. (2) Android Studio: File → Open, select Examples/AlarmCreate, let Gradle sync, then Run. (3) Command line (requires Android SDK): android update project -p Examples/AlarmCreate && ant debug install. Legacy projects may require API level 15–18 emulator or device.

• Examples/AlarmCreate/src/course/examples/alarms/alarmcreate/AlarmCreateActivity.java — Primary entry point demonstrating alarm scheduling with AlarmManager—essential for understanding the Alarms example architecture.
• Examples/AlarmCreate/AndroidManifest.xml — Declares alarm receivers and permissions required for background alarm execution; every contributor must understand the manifest structure.
• Examples/AudioVideoAudioManager/src/course/examples/audiovideo/audiomanager/AudioVideoAudioManagerActivity.java — Core audio management example showing AudioManager API usage for controlling audio focus and streams.
• Examples/AudioVideoAudioRecording/src/course/examples/audiovideo/audiorecording/AudioRecordingActivity.java — Demonstrates MediaRecorder API for audio capture; critical for understanding Android media recording patterns.
• Examples/AudioVideoCamera/res/layout/main.xml — Layout template pattern used across examples for camera and media UI components.
• Examples/AlarmCreate/project.properties — Build configuration and API level targeting; must be reviewed when adding new examples or updating SDK versions.

• AlarmCreateActivity (Activity, AlarmManager, SharedPreferences) — UI for configuring alarm parameters (time, label, sound); calls AlarmManager to schedule pending intent
  • Failure mode: Alarm not scheduled if AlarmManager permission missing or device clock incorrect; pending intent drops after app uninstall
• AlarmNotificationReceiver (BroadcastReceiver, NotificationManager, MediaPlayer) — Handles alarm trigger broadcast; creates system notification and optionally plays sound
  • Failure mode: Notification fails if VIBRATE or WAKE_LOCK permission missing; audio playback may be overr

Add a New Alarm Example

1. Create new Activity class extending AlarmCreateActivity in Examples/AlarmCreate/src/course/examples/alarms/alarmcreate/ (Examples/AlarmCreate/src/course/examples/alarms/alarmcreate/YourNewAlarmActivity.java)
2. Create corresponding BroadcastReceiver for alarm trigger handling following AlarmNotificationReceiver pattern (Examples/AlarmCreate/src/course/examples/alarms/alarmcreate/YourAlarmReceiver.java)
3. Add activity and receiver declarations to AndroidManifest.xml with required WAKE_LOCK and RECEIVE_BOOT_COMPLETED permissions (Examples/AlarmCreate/AndroidManifest.xml)
4. Add new layout XML file in res/layout/ following main.xml naming convention (Examples/AlarmCreate/res/layout/your_alarm_layout.xml)

Add a New Audio/Video Example

1. Create new Activity in Examples/AudioVideo{Feature}/src/course/examples/audiovideo/{feature}/ extending AppCompatActivity (Examples/AudioVideo{Feature}/src/course/examples/audiovideo/{feature}/YourAudioVideoActivity.java)
2. Declare activity and required media permissions (RECORD_AUDIO, CAMERA) in AndroidManifest.xml (Examples/AudioVideo{Feature}/AndroidManifest.xml)
3. Create layout XML in res/layout/ with media controls following AudioVideoAudioManager/res/layout/main.xml pattern (Examples/AudioVideo{Feature}/res/layout/main.xml)
4. Add localized strings to res/values/strings.xml for UI labels and messages (Examples/AudioVideo{Feature}/res/values/strings.xml)

Add a New System Event Receiver

1. Create BroadcastReceiver class in appropriate Examples subdirectory following SmsReceiver.java pattern (Examples/AppFundamentalsVideoSourceExamples/src/YourEventReceiver.java)
2. Implement onReceive() method to handle intent and extract broadcast data (Examples/AppFundamentalsVideoSourceExamples/src/YourEventReceiver.java)
3. Declare receiver in corresponding AndroidManifest.xml with intent-filter matching broadcast action (Examples/{YourExample}/AndroidManifest.xml)

• AlarmManager — Provides reliable scheduling of events even after device reboot or app termination; essential for alarm clock applications
• BroadcastReceiver — Enables background event handling for system intents (alarms, SMS, boot events) without keeping Activity running
• MediaRecorder — Native Android API for audio/video capture with low latency; supports hardware acceleration on modern devices
• AudioManager — Provides audio focus and stream management to prevent playback conflicts between apps
• PendingIntent — Allows granting background permission to AlarmManager and other services without maintaining app lifecycle

• Separate examples per feature rather than monolithic app

  • Why: Improves code clarity and isolation; each example can be studied independently as a self-contained module
  • Consequence: Increases repo size and requires duplication of boilerplate AndroidManifest, layout resources, and build config

• Uses legacy android-support libraries and older API patterns

  • Why: Examples target broad API level compatibility (likely API 8-16 based on drawable density buckets); documented at time of course creation
  • Consequence: Patterns may not reflect modern AndroidX best practices; requires migration effort for production use

• No dependency injection or abstraction layers

  • Why: Keeps examples minimal and directly demonstrating platform APIs without extra libraries
  • Consequence: Tight coupling to Android framework APIs; less reusable component code

• Not a real-time streaming framework—examples use discrete MediaRecorder snapshots
• Does not implement custom services or IPC beyond basic BroadcastReceiver pattern
• Not production-grade error handling or recovery; examples assume happy-path execution
• No persistent database or content provider implementations; examples use in-memory state

No hidden environment variables or service dependencies documented. Gotchas: (1) Projects use legacy Ant build.xml—Android Studio may not auto-detect them; use 'Import Project' and accept Gradle migration. (2) AndroidManifest.xml files target minSdkVersion ~10–15; many APIs (e.g., AlarmManager, MediaPlayer patterns) will fail on modern Android 12+ due to permission model changes (SCHEDULE_EXACT_ALARM, runtime permissions). (3) Some projects reference raw audio assets (alarm_rooster.mp3 in AlarmCreate/res/raw/)—these must be present or app will crash at runtime. (4) No build.gradle files visible, meaning Gradle version and dependency versions are unknown; manual Gradle setup required for modern builds.

• BroadcastReceiver and Intent-based IPC — AlarmNotificationReceiver in this repo demonstrates inter-process communication via system broadcasts—critical for understanding loose coupling in Android and how background alarms trigger app logic without keeping the app running.
• PendingIntent — AlarmCreateActivity uses PendingIntent to defer alarm callbacks; this is a core Android capability for scheduling work that must survive app termination.
• AlarmManager and System Alarms — The AlarmCreate module teaches low-level system alarm scheduling; understanding AlarmManager is essential for implementing background tasks before the WorkManager era.
• ContentProvider contract and CRUD operations — BrowserProvider.java demonstrates the ContentProvider pattern (query, insert, update, delete)—foundational for secure data sharing between apps and understanding Android's content resolver pattern.
• Android Service lifecycle and background execution — MediaPlaybackService illustrates the Service component lifecycle; critical for understanding how apps execute tasks independent of UI and interact with system components.
• Resource qualification and density-aware drawables — Each project contains res/drawable-hdpi, drawable-mdpi, drawable-xhdpi, drawable-xxdhpi folders; learning to provide density-qualified resources is essential for supporting diverse Android device screens.
• AndroidManifest.xml permissions and component declaration — Manifest files in each module declare activities, receivers, services, and permissions; understanding manifest structure is foundational for any Android project configuration and security model.

• android/architecture-samples — Google's official Android architecture examples showing modern MVVM, Repository pattern, LiveData, and ViewModel—direct successor to legacy patterns in this Coursera course repo.
• android/sunflower — Google's open-source Android sample app demonstrating best practices with Jetpack components (Room, WorkManager, Paging)—modern alternative to the alarm/service patterns shown here.
• square/picasso — Ecosystem companion: common dependency in Android courses for image loading; works alongside the basic MediaPlayer examples in this repo.
• google/android-training-course-in-kotlin — Google's official Kotlin-based Android training repository; successor to this Java-heavy course material with modern language and APIs.
• codepath/android_guides — Community-maintained Android development guide with similar scope to this Coursera repo but with continuous updates for modern API levels and Gradle builds.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Migrate legacy Android project structure to modern Gradle-based build system

The repo contains multiple projects using legacy Ant-based build files (build.xml, default.properties, proguard.cfg) from the Android SDK Tools era (~2012). This makes the projects incompatible with modern Android Studio and recent Android SDK versions. Migrating to Gradle would enable CI/CD integration, dependency management, and allow the examples to run on current Android tooling.

• [ ] Convert Examples/AlarmCreate/build.xml and default.properties to build.gradle and gradle.properties
• [ ] Repeat migration for Examples/AudioVideoAudioManager and Examples/AudioVideoAudioRecording projects
• [ ] Update AndroidManifest.xml files to target modern API levels (currently undefined from file structure)
• [ ] Create a root build.gradle or settings.gradle to manage all subprojects
• [ ] Test compilation and runtime on Android Studio with latest Gradle plugin

Add README documentation for each example project with setup and execution instructions

While the repo root has a minimal README, each Examples/* subdirectory lacks documentation explaining what the example demonstrates, its dependencies, and how to run it. The file structure shows specialized projects (AlarmCreate, AudioVideoAudioManager, AudioVideoAudioRecording) that would benefit students/users with clear guidance. Add individual README.md files for top-level examples.

• [ ] Create Examples/AlarmCreate/README.md documenting alarm APIs, AlarmManager usage, and intent receivers (AlarmLoggerReceiver, AlarmNotificationReceiver)
• [ ] Create Examples/AudioVideoAudioManager/README.md explaining AudioManager API and the audio resource (slow_whoop_bubble_pop.mp3)
• [ ] Create Examples/AudioVideoAudioRecording/README.md for the recording functionality
• [ ] Add a summary table in the root README.md linking to all example READMEs with 1-sentence descriptions

Create integration tests validating core functionality of key example applications

The repo contains runnable Android applications but no automated tests validating that they function correctly. This is critical for a courseware repo where code examples must be reliable. Adding Android instrumented tests (using AndroidJUnit4) for AlarmCreate and AudioVideoAudioManager would ensure examples work across API levels and prevent regressions.

• [ ] Create Examples/AlarmCreate/src/androidTest/java/course/examples/alarms/alarmcreate/AlarmCreateActivityTest.java with tests for AlarmManager creation and receiver invocation
• [ ] Create Examples/AudioVideoAudioManager/src/androidTest/java/course/examples/audiovideo/audiomanager/AudioVideoAudioManagerActivityTest.java testing AudioManager initialization
• [ ] Add androidTestImplementation dependencies (androidx.test.runner, androidx.test.rules) to build.gradle files
• [ ] Document test execution in each project's README.md (e.g., 'Run tests with: ./gradlew connectedAndroidTest')

• Add JUnit 4 test cases for Examples/AlarmCreate/src/course/examples/alarms/alarmcreate/AlarmCreateActivity.java and AlarmNotificationReceiver.java. Currently zero test coverage exists; write unit tests that mock AlarmManager, PendingIntent, and BroadcastReceiver firing.: Medium
• Create a gradle-based build configuration: add build.gradle files to Examples/AlarmCreate, Examples/AudioVideoAudioManager, and Examples/AppFundamentalsVideoSourceExamples to replace Ant build.xml. Define compileSdkVersion 30+, migrate to AndroidX, and document minSdkVersion constraints.: Medium
• Document the Examples/AppFundamentalsVideoSourceExamples/src/BrowserProvider.java ContentProvider example with inline Javadoc comments explaining the contract (query(), insert(), delete()) and add a simple integration test using ContentProvider test utilities.: Easy

• High · Outdated Android Build Configuration — Examples/AlarmCreate/, Examples/AudioVideoAudioManager/, Examples/AudioVideoAudioRecording/, and other example projects. The codebase uses legacy Android build files (default.properties, proguard.cfg, build.xml) and project structure patterns from Android SDK versions prior to Android Studio adoption. These legacy configurations may contain outdated security practices and lack modern security features. Fix: Migrate to Android Studio with updated Gradle build system. Update to modern Android SDKs and use current ProGuard/R8 obfuscation configurations. Enable modern security features like certificate pinning and up-to-date dependency management.
• High · Missing AndroidManifest.xml Security Attributes — Examples/AlarmCreate/AndroidManifest.xml, Examples/AudioVideoAudioManager/AndroidManifest.xml, Examples/AudioVideoAudioRecording/AndroidManifest.xml. Based on file structure, AndroidManifest.xml files are present but not visible for review. Legacy Android projects often lack critical security attributes such as android:usesCleartextTraffic=false, proper permission declarations, and intent-filter protections. Fix: Review and update all AndroidManifest.xml files to include: android:usesCleartextTraffic=false, android:allowBackup=false, proper android:permission attributes, exported=false for components not intended for external use, and appropriate intent-filter restrictions.
• Medium · Potential Insecure Data Storage — Examples/AlarmCreate/src/course/examples/alarms/alarmcreate/, Examples/AudioVideoAudioRecording/src/course/examples/audiovideo/audiorecording/. The codebase contains example applications with raw resource files (alarm_rooster.mp3, slow_whoop_bubble_pop.mp3) and activities (AlarmCreateActivity, AlarmNotificationReceiver) that may handle sensitive data like alarm settings, logs, and notifications. No evidence of encryption or secure storage mechanisms. Fix: Implement secure storage using Android Keystore for sensitive data. Use encrypted SharedPreferences or encrypted databases (e.g., SQLCipher). Avoid storing sensitive information in plain text in SharedPreferences or files.
• Medium · Broadcast Receiver Security Risk — Examples/AlarmCreate/src/course/examples/alarms/alarmcreate/AlarmLoggerReceiver.java, Examples/AlarmCreate/src/course/examples/alarms/alarmcreate/AlarmNotificationReceiver.java, Examples/AppFundamentalsVideoSourceExamples/src/SmsReceiver.java. The codebase contains BroadcastReceiver implementations (AlarmLoggerReceiver, AlarmNotificationReceiver, SmsReceiver) without visible protection mechanisms. Unprotected broadcast receivers can be exploited by other applications. Fix: Protect broadcast receivers by: 1) Using exported=false in manifest unless external access is required, 2) Implementing permission checks, 3) Using LocalBroadcastManager for internal broadcasts, 4) Validating intent data from untrusted sources.
• Medium · Missing Input Validation — Examples/AlarmCreate/src/course/examples/alarms/alarmcreate/AlarmCreateActivity.java, Examples/AudioVideoAudioRecording/src/course/examples/audiovideo/audiorecording/AudioRecordingActivity.java. Activity classes (AlarmCreateActivity, AudioRecordingActivity, etc.) likely accept user input without visible validation or sanitization, creating risks for injection attacks and unexpected behavior. Fix: Implement comprehensive input validation for all user-provided data. Sanitize and validate all Intent extras, SharedPreferences data, and user interface inputs. Use type-safe parsing with proper error handling.
• Low · No Evidence of Dependency Management Security — Root level and Example project directories. The provided dependency file is empty. There's no Maven/Gradle dependency file (build.gradle or pom.xml) visible for vulnerability scanning of third-party libraries. Fix: Implement modern dependency management using build.gradle files. Regularly scan dependencies using tools like OWASP Dependency-Check or Snyk. Keep all libraries updated to patch known vulnerabilities.
• Low · Legacy ProGuard Configuration — undefined. The presence of proguard.cfg and proguard-project.txt suggests legacy obfuscation setup. Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.