android: beta launch checks (upgrade from 1.0.10, free path, release build, local, Auto/Cast, data safety)
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- Over a week
- Newbie friendliness
- 15/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Active
- Domain
- mobile, release, testing-qa
Research direction
This is a pre-release QA checklist, not a code change: each item needs a physical Android device, Play builds and a server account. Start by reading the linked issues (#940, #380, #1031, #1037, #1040) and the existing 1.0.10-vs-main comparison, then the device steps the issue says belong in docs/testing/device-checks.md. Done means every checkbox is run and its result recorded there, with any regressions filed as separate bugs.
Written by the indexing model from the issue text.
Description
These are checks to do before widening the next Android beta beyond internal testing. The 1.0.10-vs-main release comparison only covered a fresh install of a debug build against Emby, so these weren't exercised.
- Upgrade from 1.0.10. Install the Play 1.0.10 build, add playlists, favourites, play counts, a server and a local folder. Then install a release-signed new build over it and check that everything survives (data, settings, server credentials, the legacy restore from #940). Production and about 10k open testers will upgrade, not install fresh.
- Free/trial path. Debug builds are always Pro. On a release build from the internal track, as a non-Pro account, check the trial, paywall copy (#380), limits and the Settings Pro card.
- Release build smoke test. Every capture used a debug build. Run the release build on a real device: browse, play, sign in to a server, download, Cast.
- Local music first run. Folder setup and scan on a device with local files (#1037, #1040).
- Android Auto, Chromecast, home-screen widget, media notification and Quick Settings tile.
- Play data-safety form matches the telemetry defaults (#1031, #1040). (owner)
- Sentry. No new crash clusters from the internal track before widening.
Device steps belong in docs/testing/device-checks.md for the batch run.
Impact U3 (an upgrade or paywall regression would hit every beta user) · Reach R3 (every upgrading user; not yet tested) · Implemented: no · Design fit: fits · Complexity: M
- Dominant language
- Kotlin
- Stars
- 229
- Forks
- 28
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from timusus/Shuttle2
-
enhancement impact:U1 later P3 reach:R2 size:S
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
impact:U1 owner reach:R1 size:S
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
enhancement impact:U1 later P3 reach:R2 size:S
Difficulty 3/5 1-2 days Newbie friendliness 58/100
-
enhancement impact:U2 next-release P2 reach:R2 size:M
Difficulty 3/5 1-2 days Newbie friendliness 65/100
-
bug impact:U1 later P3 reach:R2 size:S
Difficulty 3/5 1-2 days Newbie friendliness 35/100
All issues in timusus/Shuttle2
Similar issues
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
:maddi-inspection-kotlin:test runs out of heap in a full maddi test run; exit 1 with no failing testOpenbuild/ci front-end:kotlin
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
bisq-network/bisq-mobile#1948 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
streetcomplete/StreetComplete#7286 · 2 comments ·
Maintainers usually reply within 1 day