87 lines
5.4 KiB
Markdown
87 lines
5.4 KiB
Markdown
Beta Testing | Documentation
|
||
|
||
|
||
|
||
-
|
||
|
||
-
|
||
|
||
|
||
|
||
-
|
||
|
||
-
|
||
|
||
-
|
||
|
||
-
|
||
|
||
|
||
|
||
|
||
Skip to contentDocumentationSearch⌘CtrlK Main Navigation PortalThemeMenuReturn to top Sidebar Navigation
|
||
## Get Started
|
||
Overview
|
||
### Quickstart
|
||
Sign inHardwareInstall Node.js & npmInstall Even Hub toolingYour First AppTemplatesArchitecture
|
||
## Build
|
||
Page LifecycleDisplay & UI SystemUI/UX Design GuidelinesDevice APIsContextual MenuNetworkingBackground & Lifecycle
|
||
## Test
|
||
SimulatorLocal TestingPrivate TestingBeta Testing
|
||
## Ship
|
||
Packaging & DeploymentApp Submission & QA Guidelines
|
||
## Reference
|
||
GlossaryCLIVersioning PolicyChangelogFAQ
|
||
## AI Tooling
|
||
Claude CodeOn this pageLast updated: 2026-06-04Beta Testing is the only mode that behaves identically to a Released app on a real user's phone. You pack the .ehpk exactly as you would for submission, push it to a Beta group containing yourself (and optionally teammates), and install it from the phone app's Beta tester section. The OS, the lifecycle, the lock-screen behavior, the system exit dialog - all of it matches what an end user (and a QA reviewer) sees.If you're heading into review, this is the gate. Skip it and you'll fail.See Test for how Beta Testing compares to the simulator, local sideload, and private builds.
|
||
## The flow
|
||
bash
|
||
```
|
||
# 1. Build and pack
|
||
npm run build
|
||
evenhub pack app.json dist -o myapp.ehpk
|
||
```
|
||
Then in the dev portal:
|
||
- Open hub.evenrealities.com/login, go to your project.
|
||
- Beta groups tab - create a group (e.g., self-test) and add your own account email. Add teammates' emails if you want them to test the same build.
|
||
- Builds tab - upload myapp.ehpk.
|
||
- Push the build to your self-test group.On your phone (and any teammate's phone):
|
||
- Open the Even Realities App.
|
||
- Me → Beta tester lists the build.
|
||
- Tap Install.From here on, the build behaves exactly as if it were Released. Launch from glasses home, full OS lifecycle, real backgrounding.
|
||
## What only Beta Testing validates
|
||
The things you can't test anywhere else:
|
||
### The 5-minute locked-phone test
|
||
Open your app, put it in a steady state (something visible on glasses), lock the phone, wait 5 minutes, unlock. The app should still be where you left it. This is the exact test the QA reviewer runs. Private builds survive briefly but not 5 minutes; Local Testing dies the second the phone locks.
|
||
### shutDownPageContainer(1) system exit dialog
|
||
The system exit-confirmation dialog only renders for a real install. Root-page double-tap must call bridge.shutDownPageContainer(1). Apps using 0 (immediate exit) or a custom in-app exit UI on the root page are auto-rejected at review.
|
||
### Real permission denial paths
|
||
What does your app do when the user denies a permission? Beta Testing is where you actually exercise that branch. Local Testing skips some prompts; Private Testing fires them but the reviewer's denial path is a Beta-equivalent install.
|
||
## What still requires care
|
||
|
||
- Console logs are visible in the phone app's Developer Mode console. Handy for debugging, but don't log secrets - that install path is reviewer-visible too.
|
||
- Crashes don't auto-report in beta yet. If your app vanishes, the console buffer is your only signal - check it immediately.
|
||
- Beta install is a real install. localStorage, IndexedDB, everything persists exactly as it would for an end user. Reset between test rounds when you need a clean state.
|
||
## The pre-submission checklist
|
||
Walk through each of these on the beta build before promoting to Submitted: |
|
||
| | # | Check | Pass criteria
|
||
| | 1 | 5-minute locked-phone test | Open the app, lock the phone for 5 minutes, unlock - state preserved, no spinner, no black screen.
|
||
| | 2 | Root double-tap fires the system exit dialog | Visible confirmation; WebView closes on confirm.
|
||
| | 3 | Permission denial paths handled | Deny each declared permission once - app degrades gracefully or surfaces a clear next-step message.
|
||
| | 4 | Re-launch a first-party app (Conversate, Navigate) after exit | Launches cleanly without restarting glasses.
|
||
| | 5 | No console errors at boot | Console buffer is clean immediately after launch.The full reviewer rubric: App Submission & QA Guidelines.
|
||
## Common failure modes
|
||
|
|
||
| | Symptom | Likely cause | Fix
|
||
| | Beta tester section doesn't list the build | Account not in the group, or build not pushed to group | Re-check the portal: group membership + build assignment
|
||
| | Install succeeds, app vanishes on lock | Backgrounding kills the WebView, no resume handler | Background & Lifecycle - persist eagerly to localStorage and rebuild on relaunch
|
||
| | Double-tap exits silently | shutDownPageContainer(0) or no exit handler | Use shutDownPageContainer(1) on the root page
|
||
| | Permission prompt copy is wrong | Edit app.json permission desc, repack, re-upload | Old beta still has old copy until reinstalled
|
||
| | Build updates don't propagate | Higher min_sdk_version than tester's firmware | Tester needs firmware update first, or you need to lower min_sdk_version
|
||
## When you're done
|
||
The .ehpk that passed every box above is the one you submit. Move the build from Test to Submitted in the portal. The reviewer installs from your beta build's lineage - if your beta passes the 5-minute test, the reviewer almost certainly will too.→ Next: App Submission & QA Guidelines
|
||
## Related
|
||
|
||
- Packaging & Deployment - the build path
|
||
- App Submission & QA Guidelines - the reviewer rubric
|
||
- Background & Lifecycle - what survives the 5-minute lockPagerPrevious pagePrivate TestingNext pageShip |