Skip to content

Commit e92f6ea

Browse files
jjoonleojjoonleo
authored
Merge branch 'main' into codexd/459-pre-launch-report
2 parents 359423f + 2566c36 commit e92f6ea

9 files changed

Lines changed: 673 additions & 17 deletions

‎docs/Google-Play-Release-Screenshots.md‎

Lines changed: 93 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,93 @@
1+
# Google Play Release Screenshots
2+
3+
Use this checklist to capture the Play Store screenshots for issue #449. The
4+
final screenshots must come from a release-like app build on a real device or
5+
release-equivalent emulator; do not use mock-only screens, Widgetbook states, or
6+
debug-only data.
7+
8+
Last checked against Google Play Console Help on 2026-05-10:
9+
10+
- [Add preview assets to showcase your app](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en-EN)
11+
- [Store listing practices](https://support.google.com/googleplay/android-developer/answer/13393723?hl=en)
12+
13+
## Capture Setup
14+
15+
- Build and install the release candidate that will be submitted, or an
16+
equivalent signed build from the same commit and environment.
17+
- Use the shipped localization that the screenshot will represent. If the
18+
listing has Korean and English localized screenshots, capture each language
19+
separately.
20+
- Use realistic but non-sensitive sample data. Do not show personal names,
21+
private addresses, phone numbers, access tokens, backend IDs, or real user
22+
accounts.
23+
- Clear unrelated system notifications before capture. Keep the device status
24+
bar clean and plausible.
25+
- Keep the app name, icon, and visible copy consistent with `OnTime` and
26+
`docs/Google-Play-Listing-Copy.md`.
27+
28+
## Play Asset Constraints
29+
30+
Confirm current Play Console requirements again at upload time. As of the last
31+
check above, screenshots must satisfy:
32+
33+
- At least 2 screenshots across device types are required to publish the store
34+
listing.
35+
- Up to 8 screenshots can be uploaded for each supported device type.
36+
- Accepted formats are JPEG or 24-bit PNG with no alpha channel.
37+
- Each screenshot must have a minimum dimension of 320 px and a maximum
38+
dimension of 3840 px.
39+
- The longest side cannot be more than twice the shortest side.
40+
- For app recommendation eligibility, provide at least 4 app screenshots at
41+
minimum 1080 px resolution. Portrait screenshots should be 9:16, with
42+
1080 x 1920 px or higher.
43+
44+
## Required Capture Set
45+
46+
Capture at least these five app states. If the Play Console or product/design
47+
owner wants fewer uploads, keep these as the source set and select the best
48+
ordered subset after review.
49+
50+
| Order | App state | Route or flow | Capture requirements |
51+
| --- | --- | --- | --- |
52+
| 1 | Onboarding or permission request | `/onboarding/start`, `/onboarding`, or `/allowNotification` | Show the actual first-run setup or notification permission explanation. The text must match shipped localization. |
53+
| 2 | Schedule creation | `/scheduleCreate` | Show a realistic appointment being created with date, time, place, travel time, spare time, and preparation steps where possible. |
54+
| 3 | Alarm and preparation flow | `/scheduleStart` and `/alarmScreen` | Show the early-start prompt or active preparation checklist/timer for a real schedule. Do not fake alarm state with debug-only overlays. |
55+
| 4 | Calendar or Home | `/home` or `/calendar` | Show upcoming schedules on Home or the monthly calendar with realistic non-sensitive schedule names. |
56+
| 5 | My Page and account controls | `/myPage` | Show account/settings controls, including notification or default preparation settings if available. Avoid exposing a real email address. |
57+
58+
Optional additional screenshots:
59+
60+
- Preparation completion or early/late result at `/earlyLate`.
61+
- Default preparation and spare time settings at
62+
`/defaultPreparationSpareTimeEdit`.
63+
- Schedule edit flow at `/scheduleEdit/:scheduleId`.
64+
65+
## Quality Review
66+
67+
- Confirm every screenshot reflects the release candidate behavior.
68+
- Confirm text, dates, and labels match the shipped localization.
69+
- Confirm screenshots do not imply unsupported sharing, collaboration,
70+
location-tracking, map navigation, or other features not present in the app.
71+
- Confirm screenshots do not contain debugging UI, emulator overlays, test
72+
banners, unfinished placeholders, or mock-only copy.
73+
- Confirm image dimensions and file formats are accepted by Play Console before
74+
marking issue #449 complete.
75+
- Record the build commit, build variant, device model, OS version, locale,
76+
screenshot filenames, and reviewer in the evidence log below.
77+
78+
## Evidence Log
79+
80+
Complete this table when screenshots are captured.
81+
82+
| Field | Value |
83+
| --- | --- |
84+
| Build commit | |
85+
| Build variant | |
86+
| Device or emulator | |
87+
| Android version | |
88+
| Locale(s) | |
89+
| Screenshot filenames | |
90+
| Dimension check result | |
91+
| Product/design reviewer | |
92+
| Play Console upload result | |
93+
| Notes or follow-up issues | |

‎docs/Home.md‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -8,11 +8,14 @@ Welcome to the OnTime-front project documentation! This wiki contains everything
88
- [Wiki Management Guide](./Wiki-Management.md) - How to modify and upload wiki content
99
- [Project Architecture](./Architecture.md) - Understanding the project structure
1010
- [Git Workflow](./Git.md) - Git strategy and commit message formats
11+
- [Release Checklist](./Release-Checklist.md) - Reusable release gates,
12+
verification commands, store checks, and rollout handoff
1113
- [Android Release Signing](./Android-Release-Signing.md) - Required keystore inputs and release signing validation
1214
- [iOS Release Configuration](./iOS-Release-Configuration.md) - Required Dart defines and archive validation
1315
- [Play Pre-Launch Report](./Play-Pre-Launch-Report.md) - Google Play report runbook, triage gate, and evidence template
1416
- [Release Rollout Monitoring](./Release-Rollout-Monitoring.md) - Release ownership, staged rollout gates, and post-launch monitoring
1517
- [Play Review Rejection Playbook](./Play-Review-Rejection-Playbook.md) - How to triage, fix, resubmit, or appeal Google Play review rejections
18+
- [Google Play Release Screenshots](./Google-Play-Release-Screenshots.md) - Capture checklist and evidence log for real release screenshots
1619

1720
### Technical Deep Dives
1821
- [Error Handling System](./Error-Handling-Result-System.md) - Result-based error handling architecture

‎docs/Privacy-Policy-Draft.md‎

Lines changed: 185 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,185 @@
1+
# OnTime Privacy Policy Draft
2+
3+
Draft status: not approved for publication. Prepared for issue #434 under
4+
parent track #464 on 2026-05-10.
5+
6+
Do not publish this document until every `TODO` is resolved and a product/legal
7+
owner approves the final text. Backend account and data deletion behavior is
8+
still pending verification in #439, so the retention and deletion language below
9+
is intentionally incomplete.
10+
11+
## Approval Blockers
12+
13+
- TODO: Replace `[Developer legal entity]` with the exact developer or company
14+
name used in the Google Play listing.
15+
- TODO: Replace `[privacy contact]` with the support email, contact form, or
16+
other privacy inquiry mechanism approved by the release owner.
17+
- TODO: Replace `[effective date]` with the final publication date.
18+
- TODO: Complete the account deletion and retained-data sections after #439
19+
confirms backend behavior by auth provider and data type.
20+
- TODO: Product/legal owner must approve the final text before #434 can close.
21+
22+
## Draft Policy Text
23+
24+
### Privacy Policy
25+
26+
Effective date: `[effective date]`
27+
28+
OnTime is provided by `[Developer legal entity]`. This Privacy Policy explains
29+
how OnTime collects, uses, shares, protects, retains, and deletes data when you
30+
use the OnTime app.
31+
32+
For privacy questions or requests, contact `[privacy contact]`.
33+
34+
### Data OnTime Collects Or Accesses
35+
36+
OnTime collects or accesses the following data to provide accounts, schedules,
37+
preparation reminders, alarms, and support features:
38+
39+
| Data | Examples | Purpose |
40+
| --- | --- | --- |
41+
| Account data | Email address, display name, password for email sign-up, Google sign-in token, Apple identity token, Apple authorization code, Apple-provided name or email when available | Create and authenticate accounts, keep users signed in, support social sign-in, and load user profile information |
42+
| Schedule data | Schedule ID, schedule name, schedule time, place name, place ID, movement time, spare time, notes, started/changed state, lateness time | Create, update, display, finish, and delete schedules |
43+
| Preparation data | Default preparation steps, schedule-specific preparation steps, preparation names, preparation durations, step order, spare time | Help users plan preparation steps and reminders before schedules |
44+
| Alarm and notification data | Alarm settings, notification permission state, device ID, FCM token, platform, app version, OS version, supported alarm providers, alarm status reports, armed or skipped schedule IDs, alarm failure reason | Deliver schedule reminders and alarm notifications, register the current device, restore alarms after device restart, and diagnose alarm coverage |
45+
| Feedback data | Optional account deletion feedback or other feedback message | Process user feedback and account deletion requests |
46+
| Local app data | Cached user, schedule, place, preparation, alarm, and token data stored on the device | Keep app state available locally and support app operation |
47+
| Technical data | Network request metadata, server logs, error metadata, and security-related operational records | Operate, secure, debug, and maintain the service |
48+
49+
OnTime does not request app-owned access to location, contacts, camera,
50+
microphone, phone, SMS, storage, calendar, nearby-device, or Bluetooth
51+
permissions in the current Android release manifest. OnTime uses notification,
52+
exact alarm, full-screen intent, boot completion, vibration, Firebase messaging,
53+
and network-related permissions to provide schedule reminders and alarm
54+
functionality.
55+
56+
### How OnTime Uses Data
57+
58+
OnTime uses collected data to:
59+
60+
- Create, authenticate, and manage user accounts.
61+
- Support email/password, Google, and Apple sign-in.
62+
- Create, update, finish, delete, and display schedules.
63+
- Create and update default and schedule-specific preparation steps.
64+
- Send schedule reminders, preparation notifications, and alarm notifications.
65+
- Register and unregister the current device for alarm and notification
66+
delivery.
67+
- Process optional feedback and account deletion feedback.
68+
- Maintain security, prevent abuse, debug failures, and operate the service.
69+
70+
### Third-Party Services And Processors
71+
72+
OnTime uses third-party services and SDKs where needed for core app behavior:
73+
74+
| Service or SDK | Purpose | Data involved |
75+
| --- | --- | --- |
76+
| Google Sign-In | Google account authentication | Google account authentication data, including ID token and profile scopes for email/profile |
77+
| Apple Sign-In | Apple account authentication | Apple identity token, authorization code, and Apple-provided name or email when available |
78+
| Firebase Core and Firebase Cloud Messaging | App initialization and push notification delivery | Firebase installation or messaging identifiers, FCM token, notification delivery data, and device-related messaging metadata |
79+
| OnTime backend/API infrastructure | Account, schedule, preparation, alarm, notification, feedback, and deletion request processing | The account, schedule, preparation, alarm, notification, feedback, and technical data listed above |
80+
81+
TODO: Confirm whether Kakao SDK is present only as an unused dependency for this
82+
release. If Kakao sign-in or Kakao SDK data processing is active in the release
83+
build, add Kakao to this table and update the Data safety form accordingly.
84+
85+
TODO: Confirm the backend hosting, database, logging, monitoring, analytics, and
86+
crash-reporting providers used outside this frontend repository, then add each
87+
approved provider to this table if it processes personal or sensitive user data.
88+
89+
### Data Sharing
90+
91+
OnTime shares data with service providers only as needed to provide app
92+
functionality, authentication, notifications, hosting, security, operations, and
93+
support. OnTime does not use in-app advertising in the current release build.
94+
95+
TODO: Product/legal owner must confirm whether any backend, analytics,
96+
monitoring, support, or legal/compliance sharing occurs outside the app code
97+
reviewed here.
98+
99+
### Secure Data Handling
100+
101+
OnTime uses HTTPS API communication, token-based authentication, local secure
102+
token storage, release-log restrictions, and redaction practices to protect
103+
personal and sensitive data. Release builds must not log tokens, authorization
104+
headers, request bodies, response bodies, personal schedule payloads, full alarm
105+
payloads, OAuth values, or FCM tokens.
106+
107+
TODO: Backend owner must confirm server-side encryption, access controls,
108+
backup handling, production logging controls, incident response, and retention
109+
controls.
110+
111+
### Data Retention
112+
113+
OnTime keeps account, schedule, preparation, alarm, notification, feedback, and
114+
technical data for as long as needed to provide the service, maintain security,
115+
meet legal obligations, resolve disputes, and enforce agreements.
116+
117+
TODO: Replace this general language with exact retention periods after #439
118+
confirms:
119+
120+
- Whether user account records are deleted immediately, soft-deleted, anonymized,
121+
or retained for a period after deletion.
122+
- Whether schedule, place, preparation, alarm settings, device registrations,
123+
FCM tokens, alarm status reports, and feedback are deleted with the account.
124+
- Whether server logs, backups, audit records, abuse-prevention records, or
125+
legal/compliance records are retained after account deletion.
126+
- The retention period and reason for each retained data type.
127+
128+
### Account And Data Deletion
129+
130+
Users can request account deletion from within the OnTime app. The current
131+
frontend routes deletion requests through separate backend endpoints for normal,
132+
Google, and Apple account types, and supports optional deletion feedback. On
133+
successful deletion, the app signs the user out.
134+
135+
TODO: Finalize this section only after #439 verifies backend behavior. The final
136+
policy must clearly state:
137+
138+
- How users request deletion in the app.
139+
- How users request deletion outside the app after #440 creates the public
140+
deletion request URL.
141+
- Which account data and associated user data are deleted.
142+
- Which data, if any, is retained after deletion.
143+
- Why retained data is kept and for how long.
144+
- Whether deletion covers Google and Apple social account paths consistently.
145+
146+
### Children
147+
148+
TODO: Product/legal owner must confirm the intended audience and Google Play
149+
target age settings before publication. If OnTime is not directed to children,
150+
state that clearly. If children may use the app, complete the required child
151+
privacy and Play Families review before publication.
152+
153+
### Changes To This Policy
154+
155+
OnTime may update this Privacy Policy to reflect changes in app behavior, legal
156+
requirements, or service providers. The effective date above will be updated
157+
when the policy changes.
158+
159+
## Release Owner Checklist
160+
161+
- [ ] Developer/entity name matches the Google Play listing.
162+
- [ ] Privacy contact method is approved and monitored.
163+
- [ ] #439 backend deletion and retention behavior is verified by data type.
164+
- [ ] #440 external account deletion request URL exists or the policy links to
165+
the approved deletion request path when available.
166+
- [ ] All active third-party SDKs and backend processors are listed.
167+
- [ ] Data categories match the shipped app and the Play Console Data safety
168+
form.
169+
- [ ] Retention and deletion language matches backend behavior.
170+
- [ ] Product/legal owner approves the final text.
171+
- [ ] Approved policy is handed to #435 for public HTTPS hosting.
172+
- [ ] Hosted policy URL is entered in Play Console in #437.
173+
174+
## References
175+
176+
- Google Play User Data policy:
177+
https://support.google.com/googleplay/android-developer/answer/10144311
178+
- Google Play app account deletion requirements:
179+
https://support.google.com/googleplay/android-developer/answer/13327111
180+
- Google Play Data safety form guidance:
181+
https://support.google.com/googleplay/android-developer/answer/10787469
182+
- Local app data-flow review sources: `lib/data/data_sources/`,
183+
`lib/core/constants/endpoint.dart`, `lib/data/tables/`,
184+
`android/app/src/main/AndroidManifest.xml`, `docs/Android-Manifest-Permissions.md`,
185+
and `docs/Logging-Policy.md`.

0 commit comments

Comments
 (0)