Project 5: Timekeeper Constraint-Aware Scheduler

Build a scheduler that chooses an honest Android execution mechanism, persists timing intent, reconciles registrations, and measures requested versus actual delivery.

Quick Reference

Attribute	Value
Difficulty	Level 3 — Advanced
Time Estimate	20-30 hours
Language	Kotlin; Java and SQL are useful alternatives for adapter and registry exercises
Prerequisites	Projects 1-4, Android lifecycle, time concepts, durable IDs, idempotency
Key Topics	WorkManager, AlarmManager, Doze, constraints, exact access, reboot, DST, reconciliation

1. Learning Objectives

By completing this project, you will:

Select in-process work, WorkManager, AlarmManager, or a foreground service from explicit requirements.
Explain which timing promises each mechanism can and cannot make.
Persist desired schedule state before creating disposable platform registrations.
Reconcile schedules idempotently after app start, reboot, time change, or authority change.
Model wall-clock recurrence separately from elapsed duration and delivery time.
Define behavior for daylight-saving gaps, overlaps, timezone changes, and past-due occurrences.
Reload the current rule by stable ID when work begins.
Measure requested time, eligibility, actual start, delay, retries, and restriction evidence.
Test Doze, process death, exact-alarm revocation, duplicate reconciliation, and force-stop expectations.

2. Theoretical Foundation

2.1 Core Concepts

Persistent versus in-process work

Coroutines and handlers are appropriate while the owning process and lifecycle remain alive. WorkManager is for persistent, deferrable work that should execute after constraints become satisfied, even if the original process disappears. It does not promise a precise wall-clock instant. Choosing persistent work solely because it is asynchronous is a category error.

Alarm semantics

AlarmManager represents time-based wakeups outside the app lifecycle. Inexact alarms let the system batch work for battery efficiency. Exact alarms consume more resources, require special authority on modern Android for common use, and are justified only for genuinely precise user-facing functions. An alarm callback should hand off bounded work rather than becoming an untracked background runtime.

Foreground service

A foreground service is for immediate, user-perceptible work with an ongoing notification and a qualifying service type where required. It is not a scheduling API and does not make the process immortal. Background-start restrictions and duration policies still apply.

Desired state and projection

The database stores schedule intent: rule ID, recurrence, precision policy, constraints, timezone policy, next logical occurrence, and enabled state. Work requests and PendingIntent-based alarm registrations are projections of that intent. Reconciliation compares durable desired state with known platform registration state and converges idempotently.

Wall clock versus monotonic clock

Wall time expresses calendar intent such as 07:30 America/Sao_Paulo. It can jump due to user change, network correction, or timezone movement. Monotonic elapsed time measures duration within one boot and does not represent a future civil-time recurrence. A scheduler needs both kinds of reasoning without conflating them.

Eligibility versus delivery

A schedule may become logically due, then wait for system delivery, then wait for constraints, then start work, then retry. Diagnostics must distinguish these stages. API acceptance proves only that a request was registered, not that it ran at the requested moment.

2.2 Why This Matters

Scheduling is where desktop-daemon assumptions fail most visibly on Android. The OS optimizes wakeups, applies Doze and standby restrictions, limits background starts, and may kill processes. OEM policies introduce additional delays. A correct automation product does not promise every-five-minute immortality.

Honest timing creates better UX. A user can choose Best effort within a window, When constraints allow, or Exact user-facing reminder when legitimately supported. If exact access is absent or revoked, the app can preserve the rule, explain the precision change, and offer an inexact alternative.

Durable reconciliation prevents duplicate registrations and missing work. Boot, app start, time change, package replace, and capability change can all invoke the same convergence function safely.

2.3 Historical Context / Background

Android background execution evolved from broad services and alarms toward JobScheduler and WorkManager for battery-aware durable work. Doze batches deferred activity when devices remain idle. Android 12 and later tightened exact-alarm access and background foreground-service launches. New target SDK levels continue to refine quota and foreground-service behavior.

The direction is consistent: declare the work’s real urgency and constraints, use the narrowest mechanism, and expect the system to manage resources. Automation tools must surface these contracts instead of hiding them.

2.4 Common Misconceptions

WorkManager runs exactly at a requested time: it runs eligible persistent work under system scheduling.
Periodic work is a precise timer: periodic delivery is constrained, inexact, and has a platform-defined minimum interval.
Foreground service means always running: it is visible, restricted, stoppable, and purpose-specific.
Repeating alarm solves recurrence: DST and timezone semantics still require application decisions.
Boot receiver should execute the routine: it should reconcile or enqueue and return quickly.
One successful registration is durable truth: registrations can drift from edited or disabled rules.
Process death and force-stop are equivalent: force-stop imposes user/system state that ordinary restart assumptions must respect.
Exact is always better: exact wakeups cost battery and face stronger policy requirements.

3. Project Specification

3.1 What You Will Build

Build Timekeeper with:

A scheduling decision matrix.
Durable schedule registry linked to current rule IDs.
WorkManager adapter for deferrable constrained work.
AlarmManager adapter for user-visible wall-clock delivery where justified.
In-process adapter for short visible-session timers.
Foreground-work classification for one bounded visible export simulation.
Reconciliation after app start, reboot, timezone/time changes, and exact-access changes.
A diagnostics screen showing requested versus actual timing.
Debug scenarios for Doze, retry, duplicate reconciliation, and DST.

The project plans or invokes only safe demo actions. It does not create aggressive polling or hidden perpetual services.

3.2 Functional Requirements

Requirement capture: Record durability, precision, urgency, visibility, constraints, recurrence, and maximum delay.
Mechanism decision: Return selected mechanism or reject an impossible contract with explanation.
Durable-first update: Commit desired schedule before platform registration.
Stable identity: Unique work names and alarm identities derive from durable schedule IDs.
Current rule load: Worker/alarm handoff reloads the enabled current rule by ID.
One recurrence at a time: Compute and register the next wall-clock occurrence after delivery or relevant change.
DST policy: Handle nonexistent and repeated local times explicitly.
Reconciliation: Add missing, update changed, and cancel obsolete projections idempotently.
Exact-access degradation: Disable exact precision or offer best effort without deleting intent.
Diagnostics: Record requested, registered, eligible, actual, delay, constraints, retries, and reason evidence.
Backoff: Classify retryable and permanent demo failures.
Battery restraint: Reject unjustified high-frequency schedules.

3.3 Non-Functional Requirements

Reliability: Reconciliation can run repeatedly without duplicate effects.
Honesty: UI copy states timing windows and restrictions rather than claiming precision not provided.
Battery: Deferrable work uses constraints and batching; exact alarms are exceptional.
Privacy: Schedule traces contain rule IDs and timing evidence, not sensitive action payloads.
Compatibility: API-level and exact-access differences remain in platform adapters.
Testability: Clocks, zone rules, schedulers, and registration stores are injectable.

3.4 Example Usage / Output

Schedule: morning-routine
User intent: 07:30 local time
Precision: BEST EFFORT
Timezone policy: follow device zone
Mechanism: INEXACT ALARM

Requested occurrence: 2026-07-16 07:30:00 -03:00
Registered: 2026-07-15 18:04:22 -03:00
Observed delivery: 2026-07-16 07:34:18 -03:00
Delay: 4m 18s
Evidence: delivered in system batch
Next occurrence: 2026-07-17 07:30:00 -03:00

3.5 Real World Outcome

Open the Schedules screen and create two routines. The first is a local-time reminder at 07:30 with Best effort precision. The second is a deferrable maintenance demo requiring charging and unmetered network. Before saving, a decision panel explains the chosen mechanism and timing contract.

The Diagnostics screen lists durable schedule ID, rule ID, desired recurrence, platform projection, requested occurrence, last eligibility, actual start, delay, constraints, retry count, restriction state, and next occurrence. It clearly distinguishes Scheduled from Actually ran.

Enable Doze in a test scenario. Best-effort or constrained work is delayed. When it eventually runs, the trace names delay evidence instead of reporting a silent failure. Reconcile three times and inspect that only one future registration exists.

Reboot the emulator. A short receiver path invokes reconciliation, producing exactly one platform projection per enabled schedule. Change timezone; wall-clock rules recompute from local intent, while duration-based demo work remains duration-based.

Simulate exact access, then revoke it. Exact precision becomes unavailable, the rule remains in the library, and the user sees a choice to accept Best effort or leave the rule disabled. Run DST gap and overlap fixtures; each selects the documented skip, shift, earlier-offset, or later-offset behavior exactly once.

4. Solution Architecture

4.1 High-Level Design

 Compose schedule editor
          |
          v
 ScheduleIntent + TimingContract
          |
          v
 +-----------------------+
 | Mechanism selector    |
 | durability / urgency  |
 | precision / visibility|
 | constraints           |
 +-----------+-----------+
             |
     durable schedule transaction
             |
             v
 +-----------------------+       system signals
 | Schedule registry     | <---- boot / time / zone /
 | source of truth       |       app start / access change
 +-----------+-----------+
             |                         |
             +------------+------------+
                          v
                   Reconciler
        +-------------+---+--------------+
        |             |                  |
        v             v                  v
   WorkManager   AlarmManager      in-process/FGS
   projection    projection        qualified path
        |             |                  |
        +-------------+------------------+
                          |
                  delivery envelope
                          |
                  reload current rule
                          |
                     RuleForge plan
                          |
                  timing diagnostics

4.2 Key Components

Component	Responsibility	Key Decisions
TimingContract	Captures user-visible promise	Separate from API mechanism
MechanismSelector	Chooses or rejects scheduler	Pure decision table
ScheduleRepository	Persists desired schedules and next occurrence	Source of truth
RecurrenceCalculator	Resolves zone, DST, and next local occurrence	Injectable clock and zone rules
WorkProjection	Maps durable IDs to unique work	Reloads current rule
AlarmProjection	Maps stable alarm identity and PendingIntent semantics	Exact only when justified
Reconciler	Converges desired and registered state	Safe on repeated signals
DeliveryRecorder	Stores requested/actual timing evidence	Structured delay causes
RestrictionInspector	Reports Doze, constraints, access, and force-stop caveats	Does not overclaim OEM reasons

4.3 Data Structures

ScheduleIntent
  schedule_id
  rule_id
  enabled
  schedule_kind
  recurrence
  zone_policy
  precision_policy
  constraints
  maximum_acceptable_delay optional
  next_logical_occurrence

TimingContract
  mechanism
  promise_text
  requires_special_access
  visible_execution_required
  degradation

DeliveryEvidence
  schedule_id
  requested_at
  registered_at
  eligible_at optional
  started_at optional
  completed_at optional
  delay
  constraints_snapshot
  attempt
  reason_code

4.4 Algorithm Overview

Key Algorithm: Reconcile Durable Schedules

Load all enabled durable schedule intents in bounded pages.
Recompute next logical occurrence when zone, time, rule, or access state changed.
Select the honest mechanism for each current timing contract.
Build the expected projection identity and parameters.
Compare expected projections with the app’s durable registration ledger and queryable platform state.
Cancel obsolete or changed projections.
Create missing projections using stable unique identity.
Record registration evidence transactionally.
Mark unsupported or blocked schedules as degraded without deleting them.
Emit a reconciliation summary with added, updated, canceled, unchanged, and blocked counts.

Complexity Analysis:

Time: O(S log S) for S schedules if sorting by next occurrence; O(S) with indexed/paged desired state and keyed projections.
Space: O(P) for one reconciliation page rather than the full catalog.

5. Implementation Guide

5.1 Development Environment Setup

Use WorkManager and its test APIs, AlarmManager, BroadcastReceiver, Project 1 exact-access assessment, Project 4 schedule storage, an injectable clock, and an emulator that can enter idle states.

$ adb shell dumpsys deviceidle force-idle
Now forced in to deep idle mode

$ adb shell dumpsys deviceidle unforce
Light state: ACTIVE, Deep state: ACTIVE

Use destructive device-state commands only on an emulator or a device you explicitly control. These commands test system behavior; they are not part of the application implementation.

5.2 Project Structure

timekeeper/
├── scheduling-domain/
│   ├── contract/
│   ├── mechanism-selection/
│   ├── recurrence/
│   └── reconciliation/
├── scheduling-storage/
│   ├── schedules/
│   ├── registration-ledger/
│   └── delivery-evidence/
├── scheduling-android/
│   ├── workmanager/
│   ├── alarms/
│   ├── receivers/
│   └── restrictions/
├── app/ui/schedules/
├── app/ui/diagnostics/
└── tests/
    ├── clocks-and-zones/
    ├── reconciliation/
    ├── workmanager/
    └── device-scenarios/

5.3 The Core Question You Are Answering

What timing promise can Android honestly keep for this routine, and how will the app prove what actually happened?

State the user promise before selecting an API. If the promise says exact but the use case is ordinary background polling, reject or redesign it.

5.4 Concepts You Must Understand First

Stop and research these before coding:

Persistent work and constraints
- What does WorkManager guarantee after constraints are met?
- Why is enqueue success not execution success?
- Book Reference: Release It!, 2nd Edition — stability and recovery.
Exact and inexact alarms
- Which user-facing functions justify exact delivery?
- How is exact access checked and revoked?
- Official Reference: Schedule alarms.
Foreground services
- What makes work immediate and user-perceptible?
- Which start restrictions and service types apply?
Civil time and duration
- What happens when 02:30 does not exist?
- Which offset wins when 01:30 occurs twice?
- Why should local recurrence store zone policy?
Reconciliation
- Why is a system registration a projection rather than source of truth?
- How do stable identities avoid duplicates?
Force-stop and reboot
- How do ordinary process death, reboot, and force-stop differ?
- Which system signals may legitimately reconstruct work?

5.5 Questions to Guide Your Design

Is the work durable if the user leaves the screen?
Is timing exact, windowed, best effort, or constraint-driven?
Is the effect user-visible and immediate enough for a foreground service?
Can the user accept degraded precision?
What stable identity represents one schedule projection?
Does the Worker reload the latest enabled rule by ID?
How are past-due occurrences handled after a long delay?
Does recurrence follow device timezone or a fixed zone?
What happens in DST gap and overlap?
Which diagnostic reason can the app prove versus infer?

5.6 Thinking Exercise

Choose a Mechanism for Four Jobs

Evaluate:

Upload redacted logs when unmetered and charging.
Show a user reminder at 07:30 local time.
Perform a 30-second export the user started while watching progress.
Poll a sensor every five minutes forever in the background.

Questions to answer:

Which uses WorkManager, AlarmManager, foreground service, or in-process work?
Which requirement should be rejected or redesigned?
What exact timing promise appears in UI?
Which state survives process death?
Which mechanism consumes a scarce resource or special authority?

5.7 The Interview Questions They Will Ask

When should you use WorkManager instead of AlarmManager?
What restrictions apply to exact alarms on modern Android?
Why does a foreground service not guarantee immortality?
How do you restore schedules after reboot without duplicates?
How do you test Doze and App Standby behavior?
How do you model recurrence across DST and timezone changes?

5.8 Hints in Layers

Hint 1: Write the decision table first

Durability, precision, urgency, visibility, and constraints determine the mechanism.

Hint 2: Persist before registration

The OS projection must be reconstructable after loss.

Hint 3: Schedule one wall-clock occurrence

Recompute the next after delivery or time-policy change.

Hint 4: Measure delay

Requested, eligible, and actual are different timestamps.

5.9 Books That Will Help

Topic	Book	Chapter
Reliability	Release It!, 2nd Edition	Stability, timeouts, recovery
Idempotency	Enterprise Integration Patterns	Idempotent Receiver
Time reasoning	Computer Systems: A Programmer’s Perspective	Time measurement sections
Durable state	Patterns of Enterprise Application Architecture	Repository and Unit of Work
Testing	Test Driven Development: By Example	Parts I-II

5.10 Implementation Phases

Phase 1: Timing Contracts and Decision Matrix (5-7 hours)

Goals:

Define honest promises before Android mechanisms.
Persist desired schedules.

Tasks:

Model durability, precision, recurrence, visibility, and constraints.
Build pure mechanism-selection fixtures, including rejected requirements.
Add schedule registry and Compose editor preview.

Checkpoint: Every example schedule receives one mechanism or explicit rejection reason.

Phase 2: Platform Projections and Diagnostics (8-12 hours)

Goals:

Register WorkManager and alarm projections by stable ID.
Record requested-versus-actual evidence.

Tasks:

Implement WorkManager mapping for deferrable constrained demos.
Implement inexact and guarded exact alarm mapping.
Add delivery events, current-rule reload, and diagnostic timeline.

Checkpoint: Two schedules run or delay with truthful trace evidence and no duplicate projection.

Phase 3: Reconciliation, Time Edges, and Restrictions (7-11 hours)

Goals:

Recover projections and handle civil-time edges.
Test revocation and idle behavior.

Tasks:

Add app-start, boot, time, zone, and exact-access reconciliation signals.
Add DST gap/overlap and past-due policies.
Run Doze, retry, process-death, reboot, and repeated-reconcile tests.

Checkpoint: Reconciliation repeated three times yields one correct future projection per schedule.

5.11 Key Implementation Decisions

Decision	Options	Recommendation	Rationale
Persistent deferrable work	Service loop; WorkManager	WorkManager	System-managed durability and constraints
Calendar wakeup	Periodic work; one next alarm	One next alarm	Recompute zone and DST semantics
Precision	Always exact; explicit policy	Explicit policy	Battery and access honesty
Source of truth	OS registration; database intent	Database intent	Reconstructable and editable
Worker input	Full rule blob; stable ID	Stable ID	Loads current enabled revision
DST	Implicit library default; stored policy	Stored policy	Predictable recurrence

6. Testing Strategy

6.1 Test Categories

Category	Purpose	Examples
Decision tests	Select or reject mechanism	Exact reminder versus deferrable upload
Recurrence tests	Prove time semantics	Gap, overlap, timezone movement
Reconciliation tests	Prove convergence	Repeat startup and boot signal
WorkManager tests	Prove constraints and retries	Charging plus unmetered
Alarm tests	Prove stable identity and access	Revoked exact capability
Device tests	Prove real restrictions	Doze, reboot, process death
UI tests	Prove truthful contract	Best effort and degraded precision copy

6.2 Critical Test Cases

Constraint wait: Work remains pending until required test constraints are satisfied.
Current rule load: Disabled or edited rule is rechecked at delivery.
Repeated reconciliation: Three invocations yield one logical future registration.
Obsolete cancellation: Disabling a schedule removes its platform projection.
Reboot: Enabled schedules reconstruct exactly once.
Timezone change: Follow-device recurrence moves to preserve local time.
DST gap: Nonexistent time follows configured shift or skip policy.
DST overlap: Repeated time runs once at configured offset.
Exact revocation: Exact schedule becomes degraded and does not throw.
Doze delay: Diagnostic evidence distinguishes delay from missing trigger.
Retry: Retryable demo error backs off; permanent error terminates.
Past due: Long-delayed recurrence follows skip, run-once, or catch-up policy without storming.
Force-stop documentation: Test expectations do not claim normal reboot recovery overrides user force-stop behavior.

6.3 Test Data

schedule A
  kind: local recurrence
  local_time: 07:30
  zone_policy: follow device
  precision: best effort
  expected_mechanism: inexact alarm

schedule B
  kind: durable deferred
  constraints: charging + unmetered
  expected_mechanism: WorkManager

DST gap fixture
  local_time: 02:30 nonexistent
  policy: SHIFT_FORWARD
  expected: one occurrence at first valid local time

DST overlap fixture
  local_time: 01:30 repeated
  policy: EARLIER_OFFSET_ONCE
  expected_occurrences: 1

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall	Symptom	Solution
WorkManager as alarm	User expects exact time	Expose best-effort contract
Blind boot enqueue	Duplicate future work	Reconcile stable identities
Full rule in worker	Edited rule still executes old copy	Pass ID and reload
Repeating wall alarm	DST duplicate or drift	Compute one next occurrence
Exact without check	Security exception or silent disable	Capability gate and degrade
FGS as daemon	Policy failure and battery drain	Use only for qualified visible work
API success metric	UI says ran when only registered	Record actual delivery stages

7.2 Debugging Strategies

Inspect the decision: Confirm requirements selected the expected mechanism.
Inspect durable intent: Verify current rule and next logical occurrence in Room.
Inspect platform work: Use Background Task Inspector and system diagnostics.
Compare timestamps: Requested, registered, eligible, started, and completed locate delay.
Reconcile repeatedly: Idempotency defects appear as duplicate ledger or platform entries.
Change one restriction: Test Doze, network, charging, or access separately before combining.
Inject clocks: Reproduce DST and timezone edges without waiting for real dates.

7.3 Performance Traps

Avoid one alarm per tiny polling interval and avoid synchronized fleet network calls at a single wall time. Add jitter to non-user-facing server work. Page schedule reconciliation. Do not wake the device to refresh diagnostics. Keep receivers short. Bound retries and catch-up so a long offline period does not create a thundering herd.

8. Extensions & Challenges

8.1 Beginner Extensions

Add a human-readable timing-contract glossary.
Add next-run preview in multiple timezones.
Add a diagnostic filter for delayed and blocked runs.

8.2 Intermediate Extensions

Add jitter policy for server-facing deferred work.
Add a schedule-health summary card to Project 1.
Add user-selected catch-up policy for missed recurrences.

8.3 Advanced Extensions

Build a reconciliation property test over random desired/registered sets.
Add an OEM behavior evidence matrix from physical devices.
Measure wakeups and battery impact of exact versus batched demo schedules.
Model schedule SLOs without claiming hard real-time guarantees.

9. Real-World Connections

9.1 Industry Applications

Backup and sync: Durable constrained uploads use WorkManager.
Calendar and alarm products: User-facing clock intent may justify alarm APIs.
Fitness and health: Background limits shape sampling and foreground disclosure.
IoT companions: Reconcile schedules and network availability after restart.
Enterprise agents: Combine policy, maintenance windows, and observable retries.

WorkManager samples: https://github.com/android/architecture-components-samples/tree/main/WorkManagerSample — official scheduling examples.
Android Platform Samples: https://github.com/android/platform-samples — current alarm and background patterns.
Now in Android: https://github.com/android/nowinandroid — production Android background synchronization architecture.

9.3 Interview Relevance

API selection tests platform judgment rather than memorization.
Reconciliation demonstrates desired-state architecture and idempotency.
DST handling exposes mature time reasoning.
Requested-versus-actual evidence shows operational thinking.
Exact-alarm and foreground-service boundaries reveal policy awareness.

10. Resources

10.1 Essential Reading

Background tasks overview: https://developer.android.com/develop/background-work/background-tasks — choose the correct mechanism.
Task scheduling: https://developer.android.com/develop/background-work/background-tasks/persistent — WorkManager guidance.
WorkManager guide: https://developer.android.com/develop/background-work/background-tasks/persistent/getting-started — durable work fundamentals.
Schedule alarms: https://developer.android.com/develop/background-work/services/alarms — exact and inexact contracts.
Foreground services overview: https://developer.android.com/develop/background-work/services/fgs — visible immediate work.
Optimize for Doze and standby: https://developer.android.com/training/monitoring-device-state/doze-standby — idle restrictions.
Android 12 behavior changes: https://developer.android.com/about/versions/12/behavior-changes-12 — foreground-service and exact-alarm changes.

10.2 Video Resources

WorkManager MAD Skills and Android background-work sessions: https://www.youtube.com/@AndroidDevelopers
Background work learning material: https://developer.android.com/develop/background-work

10.3 Tools & Documentation

Background Task Inspector: https://developer.android.com/studio/inspect/task — inspect workers, jobs, alarms, and wakelocks.
Test WorkManager: https://developer.android.com/develop/background-work/background-tasks/testing/persistent — deterministic worker testing.
ADB: https://developer.android.com/tools/adb — idle, process, and device scenarios.
WorkManager API: https://developer.android.com/reference/androidx/work/WorkManager — persistent work contract.

Project 1: Capability Navigator: Supplies exact-access and degraded-state assessment.
Project 3: RuleForge Core: Receives delivery as canonical events and plans current actions.
Project 4: Durable Automation Library: Stores desired schedules and timing evidence.
Next — Project 6: Notification Router: Uses persistent work for bounded digest processing.
Project 14: Automation Observatory: Expands delay and restriction diagnostics.

11. Self-Assessment Checklist

Before considering this project complete, verify:

11.1 Understanding

I can explain when to use WorkManager, AlarmManager, in-process work, or a foreground service.
I can state what WorkManager does not guarantee.
I understand exact-alarm access and battery trade-offs.
I can distinguish wall time, monotonic duration, eligibility, and delivery.
I can explain one DST gap and overlap policy.
I understand why platform registrations are projections.

11.2 Implementation

The decision matrix selects or rejects mechanisms explicitly.
Desired schedules commit before registration.
Workers and alarms reference stable IDs and reload current rules.
Reconciliation is idempotent across app start, boot, time, zone, and access signals.
Requested and actual timing evidence is visible.
Doze, process death, retry, and exact-access revocation tests pass.
Duplicate and DST recurrence tests pass exactly once.
No unjustified high-frequency polling or hidden service loop exists.

11.3 Growth

I documented one timing promise I had to weaken honestly.
I can defend a mechanism choice in an interview.
I measured one actual delivery delay rather than only enqueue success.
I wrote a retrospective about battery versus precision.

12. Submission / Completion Criteria

Minimum Viable Completion:

A pure decision matrix handles at least four scheduling scenarios.
One WorkManager constraint schedule and one wall-clock schedule are registered by stable ID.
Desired schedule state persists before registration.
Diagnostics show requested and actual timing.
Repeated reconciliation creates no duplicate logical work.

Full Completion:

All minimum criteria plus:
App start, reboot, time, timezone, and exact-access signals reconcile idempotently.
Doze, retry, process death, and revocation scenarios have typed evidence.
DST gap and overlap policies run exactly once as documented.
Current rule revisions are reloaded at delivery.
Unsupported or unjustified timing requirements degrade or reject clearly.

Excellence — Going Above & Beyond:

Produce an emulator/physical-device timing evidence report.
Add a property test proving reconciliation convergence over random states.
Measure wakeups and battery behavior for a controlled exact-versus-inexact comparison.
Define and validate user-facing schedule SLO categories without real-time overclaims.

This guide was generated from ANDROID_AUTOMATION_APPS_MASTERY.md. For the complete learning path, see the parent guide and directory README.

Project 5: Timekeeper Constraint-Aware Scheduler

Quick Reference

1. Learning Objectives

2. Theoretical Foundation

2.1 Core Concepts

2.2 Why This Matters

2.3 Historical Context / Background

2.4 Common Misconceptions

3. Project Specification

3.1 What You Will Build

3.2 Functional Requirements

3.3 Non-Functional Requirements

3.4 Example Usage / Output

3.5 Real World Outcome

4. Solution Architecture

4.1 High-Level Design

4.2 Key Components

4.3 Data Structures

4.4 Algorithm Overview

5. Implementation Guide

5.1 Development Environment Setup

5.2 Project Structure

5.3 The Core Question You Are Answering

5.4 Concepts You Must Understand First

5.5 Questions to Guide Your Design

5.6 Thinking Exercise

5.7 The Interview Questions They Will Ask

5.8 Hints in Layers

5.9 Books That Will Help

5.10 Implementation Phases

Phase 1: Timing Contracts and Decision Matrix (5-7 hours)

Phase 2: Platform Projections and Diagnostics (8-12 hours)

Phase 3: Reconciliation, Time Edges, and Restrictions (7-11 hours)

5.11 Key Implementation Decisions

6. Testing Strategy

6.1 Test Categories

6.2 Critical Test Cases

6.3 Test Data

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

7.2 Debugging Strategies

7.3 Performance Traps

8. Extensions & Challenges

8.1 Beginner Extensions

8.2 Intermediate Extensions

8.3 Advanced Extensions

9. Real-World Connections

9.1 Industry Applications

9.2 Related Open Source Projects

9.3 Interview Relevance

10. Resources

10.1 Essential Reading

10.2 Video Resources

10.3 Tools & Documentation

10.4 Related Projects in This Series

11. Self-Assessment Checklist

11.1 Understanding

11.2 Implementation

11.3 Growth

12. Submission / Completion Criteria