You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today the app is built with VVG/VIPR branding applied by the branding:vipr step (scripts/apply_branding.sh vipr, sourcing branding/vipr/). We'd eventually like to also produce a public build — a plain APK without the VIPR logo/name/splash — so OpenBoxes can distribute a generic build that isn't tied to a single customer.
Background / how branding works today
yarn branding:vipr → scripts/apply_branding.sh vipr copies launcher icons, splash, and in-app logo from branding/vipr/, and rewrites app_name in android/app/src/main/res/values/strings.xml from branding/vipr/settings.json ("app_name": "VIPR").
In CI, the bundle::branding step runs before the release assemble in the android-only / UAT workflows (.bitrise/bitrise.yml).
So "flavor" is currently a build-time asset/name swap, not a Gradle product flavor.
Proposed approach (to refine)
Add a public/default branding target (e.g. branding/default/ + branding:default script, or a no-op/neutral branding) that applies OpenBoxes-generic assets and name.
Add a dedicated android-public workflow in .bitrise/bitrise.yml that reuses the shared setup/release bundles but applies the public branding instead of branding:vipr (and likely a distinct app id / variant so branded and public builds can coexist on a device and in stores).
Package name / application id for the public flavor (needed for store listings and side-by-side installs).
Signing keys for the public build (separate keystore?).
What "public branding" is (neutral OpenBoxes logo/name/splash assets).
Distribution target (Play Store listing? internal only?).
Context
Split out of the OBLS-837 work (#430), which added the discrete-picking feature plus PR → Appetize preview CI plumbing. This is intentionally deferred and has product decisions attached, so it deserves its own ticket.
Summary
Today the app is built with VVG/VIPR branding applied by the
branding:viprstep (scripts/apply_branding.sh vipr, sourcingbranding/vipr/). We'd eventually like to also produce a public build — a plain APK without the VIPR logo/name/splash — so OpenBoxes can distribute a generic build that isn't tied to a single customer.Background / how branding works today
yarn branding:vipr→scripts/apply_branding.sh viprcopies launcher icons, splash, and in-app logo frombranding/vipr/, and rewritesapp_nameinandroid/app/src/main/res/values/strings.xmlfrombranding/vipr/settings.json("app_name": "VIPR").bundle::brandingstep runs before the release assemble in theandroid-only/ UAT workflows (.bitrise/bitrise.yml).Proposed approach (to refine)
branding/default/+branding:defaultscript, or a no-op/neutral branding) that applies OpenBoxes-generic assets and name.android-publicworkflow in.bitrise/bitrise.ymlthat reuses the shared setup/release bundles but applies the public branding instead ofbranding:vipr(and likely a distinct app id / variant so branded and public builds can coexist on a device and in stores).APPETIZE_*_PUBLIC_KEY, so flavors never collide.Open questions / decisions
Context
Split out of the OBLS-837 work (#430), which added the discrete-picking feature plus PR → Appetize preview CI plumbing. This is intentionally deferred and has product decisions attached, so it deserves its own ticket.