diff --git a/website/docs/publish/android.md b/website/docs/publish/android.md index 1ba4f4168c..b10838c063 100644 --- a/website/docs/publish/android.md +++ b/website/docs/publish/android.md @@ -8,11 +8,6 @@ import Tabs from '@theme/Tabs'; Instructions for packaging a Flet app into an Android APK and Android App Bundle (AAB). -:::tip[Build in Flet Studio] -Don't want to set up the Android SDK? [Flet Studio](../studio/publishing/android.md) -builds APKs and app bundles in the cloud and publishes them to Google Play. -::: - :::tip[Info] This guide provides detailed Android-specific information. Complementary and more general information is available [here](index.md). diff --git a/website/docs/studio/index.md b/website/docs/studio/index.md index 73aaf4a22b..b51c9af9a7 100644 --- a/website/docs/studio/index.md +++ b/website/docs/studio/index.md @@ -24,9 +24,8 @@ installation is required. - **Sharing.** Share public apps with a link so others can run them and explore the code. - **Private projects.** Keep your apps and source code private while you work. -- **Cloud packaging and publishing.** Build your app for Windows, macOS, Linux, - Android, iOS and the web in the cloud, without a local build environment, and - publish Android apps to Google Play. See [Publishing](publishing/index.md). +- **Cloud packaging and publishing — coming soon.** Build app packages and + publish them from Studio without a local build environment. See [what's new](whats-new.md) for the latest improvements. diff --git a/website/docs/studio/publishing/android.md b/website/docs/studio/publishing/android.md deleted file mode 100644 index 1e24dc0754..0000000000 --- a/website/docs/studio/publishing/android.md +++ /dev/null @@ -1,137 +0,0 @@ ---- -title: "Android apps (APK and app bundle)" ---- - -# Android apps: APK and app bundle - -The Android section of **Publish** has three actions: - -| Action | What you get | For | -|---|---|---| -| **Create an APK** | An `.apk` file | Installing directly on a phone or tablet | -| **Create an app bundle (.aab)** | A signed `.aab` file | Uploading to Google Play yourself, e.g. an app's first release | -| **Publish to Google Play** | A release on a Google Play track | See [Publishing to Google Play](google-play.md) | - -All three use the app's **Android signing key** when one is selected — the same key -for APKs and app bundles. - -## Create an APK - -Run **Create an APK** and **Download** the `.apk` when the run finishes. - -To install it, open the file on the phone (download it there, or copy it over). -Android asks you to allow installing apps from that source — the browser or the -Files app — the first time: **Settings › Apps › Special app access › Install -unknown apps** if you need to change it later. - -### Test-signed APKs - -Without a signing key, the APK is signed with a **test key** and the run says so. -That's fine for trying the app, but Android only installs an update over an app -signed with the same key: a later APK signed with a different key (yours, or -another test key) won't install over it, and you have to uninstall the old one -first — which deletes the app's data on the phone. - -Select a signing key as soon as you plan to keep the app installed: later APKs then -install over earlier ones as updates. - -### Install over an earlier build - -An APK installs over the copy on the phone when it's signed with the same key and -its **build number** isn't lower. Studio's build numbers always go up, so a newer run -installs over an older one. - -## Create an app bundle (.aab) - -An app bundle is what Google Play takes: Google builds the APKs for each device -from it. Studio always signs a bundle with the app's key, so the action needs one -selected. - -Use **Create an app bundle (.aab)** to upload a release to Google Play yourself — -mainly an app's **first release**, which Google requires to be uploaded in Play -Console. After that, [Publish to Google Play](google-play.md) uploads for you. - -A phone can't install an `.aab` directly. - -## Signing key - -A signing key proves your app's updates come from you. Select one in the -action screen's **Signing** section, in **Publish › Settings › Android › Signing & -accounts**, or manage your keys in **Settings › Signing keys**. Keys are saved to -your Studio account, so your other apps can use them too. - -{/* SCREENSHOT: /img/docs/studio/publishing/signing-section.png — the action screen's Signing section with a key selected */} - -### Create a key - -**Add signing key › Create a new key** makes an upload key (RSA 2048, valid for -over 27 years, alias `upload`). The name is filled in as "*app name* upload key"; -change it if you like. - -### Back up your key - -When Studio creates a key it offers **Download backup**: a `.zip` with the keystore -file and a text file with its alias and passwords. **Keep it somewhere safe**: - -- Google Play only accepts updates signed with the key the app's first release was - uploaded with. -- A key that's lost (or deleted from Studio without a backup) can only be replaced - by asking Google to reset the app's upload key through Play Console support, - which takes time. -- The backup is also what you'd use to build the app on your own computer with - [`flet build`](../../publish/android.md#signing-an-android-bundle). - -Keys you haven't backed up show **No backup yet** in **Settings › Signing keys**. -You can download a backup there at any time from the key's **⋯** menu. Only the -owner of the Studio account can. - -### Import a key - -**Add signing key › Import a keystore** takes a keystore made with `keytool` or -Android Studio: a `.jks`, `.keystore` or `.p12` file with its **key alias** (optional -if the keystore has one key), **keystore password**, and **key password** (only if -it's different). - -Import the key you already sign the app with to keep updating an app that's on -Google Play. - -Older Java keystore formats (JCEKS, BKS) aren't supported: Studio shows the -`keytool -importkeystore` command that converts one to PKCS12. - -### APKs and Google Play installs - -Google Play re-signs the copies it delivers with **Google's app signing key** -(Play App Signing). Your key is the app's **upload key**: it proves to Google that -an upload is yours. So on a phone: - -- An APK from Studio won't update a copy installed from Google Play, and the other - way round — uninstall one to install the other. -- To give testers the exact build Google Play delivers, use a Google Play testing - track ([install your test build](google-play.md#install-your-test-build-on-a-phone)), - or download a Google-signed universal APK from Play Console's **App bundle - explorer**. - -## Package name - -The app's **package name** (e.g. `com.example.myapp`) identifies it on the phone -and on Google Play. Set it in **Publish › Settings › Android › Package name** -before you publish: it can't be changed after the app's first release on Google -Play — a different package name is a different app. - -## Questions - -### Why is my APK so big? - -An APK holds Python, your app's packages, and native code for every phone -architecture it supports — by default all three (`arm64-v8a`, `armeabi-v7a`, -`x86_64`), so one file runs on any device. To make it smaller, choose fewer in -**Publish › Settings › Android**, under **Advanced settings › Architectures › -Target architectures**: most phones today only need `arm64-v8a`, but the APK then -only installs on those. The setting applies to app bundles too. - -App bundles don't have this problem: Google Play delivers each device only what it -needs. - -### Can I use a different key for APKs? - -Not yet: one key signs both the app's APKs and its app bundles. diff --git a/website/docs/studio/publishing/google-play.md b/website/docs/studio/publishing/google-play.md deleted file mode 100644 index 81fda1e1c7..0000000000 --- a/website/docs/studio/publishing/google-play.md +++ /dev/null @@ -1,278 +0,0 @@ ---- -title: "Publishing to Google Play" ---- - -# Publishing to Google Play - -Flet Studio can build your Android app, sign it with your key and release it on a -Google Play track — Internal testing, Closed testing, Open testing or Production — -in one run. This page covers the one-time setup, publishing, and getting a test -build onto your phone. - -:::tip[In short] -1. Create the app in Play Console and **upload its first release yourself** - (Google requires it) — Studio's **Create an app bundle (.aab)** makes the file. -2. **Connect Google Play**: a Google Cloud service account with release - permissions in Play Console. -3. Run **Publish to Google Play**: Studio builds, signs and uploads every later - release. -::: - -## Before you start - -You need: - -- A **Google Play developer account** ([Play Console](https://play.google.com/console)). -- An **Android signing key** selected for the app in Studio — see - [Android apps](android.md#signing-key). Google Play only accepts updates signed - with the key the app's first release was uploaded with, so keep using the same - one. -- The app's **package name** set in Studio (**Publish › Settings › Android › - Package name**, e.g. `com.example.myapp`). It must be the app's package name in - Play Console, and it can't be changed after the first release. - -## Step 1. Create the app and upload its first release - -Google doesn't let tools create an app or upload its very first release: that has -to happen in Play Console. Do it once per app: - -1. In Play Console, **Create app**: enter its name, language and type, and accept - the declarations. -2. In Studio, open **Publish** and run **Create an app bundle (.aab)** for the app. - When the run finishes, **Download** the `.aab`. -3. In Play Console, go to **Test and release › Testing › Internal testing** and - **Create new release**. Upload the `.aab` and roll the release out. - -Google Play now knows the app and remembers the key it was signed with as the -app's **upload key**. Google re-signs the copies it delivers with its own key -(Play App Signing), which is why your key must never change — see -[Android apps](android.md#apks-and-google-play-installs). - -{/* SCREENSHOT: /img/docs/studio/publishing/play-console-first-release.png — Play Console › Internal testing › Create new release, with the .aab uploaded */} - -## Step 2. Connect Google Play - -Studio uploads your releases with a **service account**: a Google Cloud robot user -you give release permissions to in Play Console. You set it up once and can use it -for all your apps. - -### In Google Cloud - -1. Open a project in the [Google Cloud console](https://console.cloud.google.com/). - **Any project works** — an existing one, or a new one just for publishing (the - project picker at the top › **New project**). It doesn't have to be linked to - your Play Console account, and it costs nothing: the Google Play Android - Developer API is free, and no billing account is needed. -2. Enable the **Google Play Android Developer API** for it - (**APIs & Services › Library**, search for "Google Play Android Developer"). -3. Go to **IAM & Admin › Service accounts** and **Create service account**. Give - it a name, e.g. `my-app-google-play`. - - **No role is needed**: skip the optional "Grant this service account access - to project" step. Permissions come from Play Console, not Google Cloud. -4. Open the service account, then **Keys › Add key › Create new key › JSON**. A - `.json` key file downloads. Keep it private: anyone with it can publish as the - service account. - -### In Play Console - -1. Open **Users and permissions**: it's an account-level page, not an app's. From - the [Play Console](https://play.google.com/console) home, click the developer - account icon at the top right (next to **Notifications**) › **Manage developer - account** › **Users and permissions**. Then **Invite new users**. -2. Enter the service account's email (`…@….iam.gserviceaccount.com`, also in the - JSON key as `client_email`). -3. On the **App permissions** tab, **Add app** and choose your app. In - **Permissions for *your app***, tick: - - under **App access**: **View app information (read-only)**. Play Console ticks - the permissions that come with it (such as *View app quality information*) - for you; - - under **Releases**: **Release apps to testing tracks**; - - under **Releases**, only if you'll submit to Production from Studio: - **Release to production, exclude devices, and use Play App Signing**. - - Leave the rest unticked: Studio doesn't need **Admin**, financial data, store - presence or tester lists. -4. **Invite user**. A service account doesn't have to accept anything. - -Permission changes can take a few minutes to apply. - -### In Studio - -On the **Publish to Google Play** action screen (or **Publish › Settings › -Android › Signing & accounts**, or **Settings › Store accounts**), click **Connect -Google Play**, choose the JSON key file and **Connect**. The name is filled in from -the service account's email; change it if you like. - -The account is saved to your Studio account, so your other apps can use it too, and -selected for this app. Studio checks access straight away: under the account the -action screen shows **Connected · com.example.myapp · latest build 28**, or what's -wrong and how to fix it. - -{/* SCREENSHOT: /img/docs/studio/publishing/connect-google-play.png — the Connect Google Play dialog with a key chosen */} - -## Step 3. Publish - -Open **Publish**, then **Publish to Google Play** in the Android section. - -{/* SCREENSHOT: /img/docs/studio/publishing/google-play-action.png — the Publish to Google Play screen: Release section, Signing & accounts with the Connected line, and the footer button */} - -- **Track**: where the build goes. - - | Track | Who gets it | Button | - |---|---|---| - | Internal testing | Up to 100 testers you list in Play Console; available within minutes | Upload to Internal testing | - | Closed testing | Testers you invite (lists or Google Groups) | Upload to Closed testing | - | Open testing | Anyone who joins from your store listing | Upload to Open testing | - | Production | Everyone, after Google's review | Submit for review | - -- **What's new**: optional release notes (up to 500 characters) shown on Google - Play, in the **Language** you enter (default `en-US`). They belong to this - release only and aren't remembered for the next one. -- **Version and build number**: the build number becomes the release's version - code. Studio starts it above the highest one Google Play already has, so it never - clashes. - -Then click the track's button. - -### What happens during a run - -1. **The build.** Studio builds a signed `.aab` in the cloud, as for any action. - This part costs credits, for the time it takes. -2. **The upload.** When the build is done, the run shows **Uploading to Google - Play** while Studio's servers upload the bundle, release it on the track and - send the change to Google Play. This part doesn't cost credits. - -Your service account's key is only used by Studio's servers for the upload: it's -never sent to the machine that builds your app. - -### Where your build is - -Once the run succeeds, the Google Play row on **Overview** says where the build is: - -| Status | Meaning | What to do | -|---|---|---| -| **On Internal testing** (or another testing track) | Released on the track | Testers get it through the Play Store — on Closed and Open testing once Google's review passes | -| **In review** | Submitted to Production | Wait for Google's review; Play Console shows its progress | -| **Draft in Play Console** | The app's setup in Play Console isn't finished, so Google only accepts draft releases | Finish the app's setup, then roll the draft out in Play Console | -| **Not sent for review** | The app uses managed publishing | Send the changes for review in Play Console | - -**Play Console** on the row and in the run's details opens Play Console. - -## When an upload fails - -If the build succeeded but the upload didn't, the run fails with what Google Play -said and how to fix it. Many of these are fixed in Play Console and then -**Retry upload** (on Overview and in the run's details): it uploads the same build -again, without building it again or charging credits. Studio first checks whether -Google Play already has the build, so a retry never submits it twice. - -| Error | Fix | -|---|---| -| Google Play has no app *package* yet | Create the app and upload its first release yourself ([step 1](#step-1-create-the-app-and-upload-its-first-release)), then **Retry upload** | -| *Service account* can't release this app | Give it the app's permissions in Play Console › Users and permissions ([step 2](#in-play-console)), wait a few minutes, then **Retry upload** | -| Enable the Google Play Android Developer API | Enable it in the service account's Google Cloud project, then **Retry upload** | -| Google rejected the service account key | The key was deleted or the account disabled: create a new JSON key and connect it | -| This build number is already on Google Play | Start a new run; leave the build number automatic, or set a higher one | -| Google Play expects a different upload key | Select the key the app's first release was uploaded with. Play Console › Test and release › **App integrity** shows its SHA-1; **Settings › Signing keys** shows yours | -| Google Play rejected a debug build | Select a signing key for the app and start a new run | -| Google Play rejected the target SDK | Raise **Target SDK version** in Publish › Settings › Android (SDK), then start a new run | -| Google Play is busy right now | **Retry upload** in a few minutes | - -If **Retry upload** isn't offered, the run's details say why — usually that a new -run is needed. - -## Install your test build on a phone - -An app on a testing track doesn't show up in Play Store search. Testers get to it -through links. - -### Add testers - -In Play Console, go to **Test and release › Testing › Internal testing › -Testers**. Create an email list, add the **Google accounts** of your testers -(including your own), tick the list and save. - -Google doesn't notify the people on the list: send them the **Join on the web** -link yourself (next step). - -### Join the test - -Each tester does this once: - -1. Open the track's **Join on the web** link — **Copy link** on the Testers tab - (`https://play.google.com/apps/internaltest/…`). Send it to your testers, or - open it yourself. -2. Sign in with the Google account that's on the list and **Accept invite**. The - page then says "You're a tester for …". -3. **Download test app** opens the app's Play Store page: **Install** on the phone, - or on a computer choose **Install** and pick the phone — Google Play installs it - remotely. - -New releases on the track arrive as normal Play Store updates (**Play Store › -your profile icon › Manage apps & device › Updates available** to get one now). - -{/* SCREENSHOT: /img/docs/studio/publishing/play-join-test.png — the "You're a tester" page with Download test app */} - -### "Item not found" - -The Play Store says **Item not found** until the account has joined the test: - -- **Join first** with the Join on the web link — being on the email list isn't - enough. -- Use the link behind **Download test app**: for an internal test it carries an - `ah=…` token, and the plain `…/details?id=` link without it can show - Item not found. -- Check the account the **Play Store app** uses (its profile icon). It can differ - from the phone's or the browser's account. -- Testers' addresses must be **Google accounts**. An address on your own domain - only works if it's the address you sign in to Google with. -- A newly published app can take a few minutes, occasionally longer, to become - available. If it still doesn't show, clear the Play Store's cache (**Settings › - Apps › Google Play Store › Storage › Clear cache**) and try again. - -### "(unreviewed)" in the app's name - -Until the app's store listing is set up and reviewed, testers see a temporary name -such as `com.example.myapp (unreviewed)` on Google Play. Fill in **Grow users › -Store presence › Main store listing** in Play Console (name, descriptions, -graphics) to fix it. The app's name on the phone, under its icon, is already the -right one: it comes from the app itself. - -## Production - -- **Google reviews** releases on Production, and on Closed and Open testing too - (Internal testing isn't reviewed). Reviews usually take from hours to a few days; - Play Console shows their progress. -- **New personal developer accounts** have to run a closed test with at least 12 - testers for 14 days before they can apply for production access. Until then, - Production releases fail with Google's message saying so. Publish to Closed - testing from Studio in the meantime. -- **Managed publishing** (Play Console › Publishing overview) holds approved changes - until you publish them. Studio's uploads then show **Not sent for review**: send - them for review in Play Console. - -## Questions - -### Do I have to use Studio for the first release too? - -No — any `.aab` signed with your key works. Studio's **Create an app bundle (.aab)** -is the easy way to get one signed with the key Studio will keep using. - -### Can I use an app that's already on Google Play? - -Yes. [Import its upload key](android.md#import-a-key) (the keystore you've been -signing with), set the same package name, connect Google Play, and publish. The -build number must be higher than Google Play's latest; Studio starts above it -automatically. - -### Can I install the APK Studio builds instead? - -Yes, but not over a copy installed from Google Play, and the other way round: -Google Play re-signs its copies with Google's key, and Android only updates an app -with one signed by the same key. See -[Android apps](android.md#apks-and-google-play-installs). - -### What can't Studio do on Google Play yet? - -Staged rollouts, custom tracks, release notes in several languages, store listing -and graphics, and in-app products. Use Play Console for those. diff --git a/website/docs/studio/publishing/index.md b/website/docs/studio/publishing/index.md deleted file mode 100644 index 46d21b22c4..0000000000 --- a/website/docs/studio/publishing/index.md +++ /dev/null @@ -1,144 +0,0 @@ ---- -title: "Publishing overview" ---- - -# Publishing your app - -Flet Studio builds your app for Windows, macOS, Linux, Android, iOS and the web in -the cloud, and can deliver it to an app store — no Flutter, Xcode or Android SDK to -install. Open it with the **Publish** button in the app bar. - -{/* SCREENSHOT: /img/docs/studio/publishing/overview.png — Publish › Overview with the Android section and its outputs */} - -## Publish at a glance - -**Publish** has three tabs: - -- **Overview**: one section per platform with its actions, and under them what each - action produced last — with **Download**, or where a store has it. -- **Activity**: every run of the app, newest first, with its status. Open one for - its details. -- **Settings**: the app's build settings — shared ones, plus a scope per platform. - -## Actions - -Each action is one **run** for one platform: - -| Platform | Actions | -|---|---| -| Windows | **Create Windows app (.zip)** | -| macOS | **Create macOS app (.app)** — not signed or notarized: for testing on your own Mac | -| Linux | **Create Linux app (.tar.gz)** | -| Android | **Create an APK**, **Create an app bundle (.aab)**, **Publish to Google Play** — see [Android apps](android.md) and [Google Play](google-play.md) | -| iOS | **Create an iOS Simulator app** — no Apple account needed | -| Web | **Create web app (.zip)** — the files to host yourself | - -Microsoft Store, Mac App Store, TestFlight, App Store and publishing a website show -**Coming soon**. - -## Start a run - -Click an action to open its screen: - -- **The settings it needs**, such as the app's name and package name, open at the - top; the rest of the platform's settings are further down. Changes are saved to - the app as you make them. -- **Version and build** for this run. -- Anything to set up first, such as a [signing key](signing-keys-and-store-accounts.md), - shown in red at the bottom until it's done. -- The **estimated credits** and your balance. - -Then click the action's button. The run's details open and follow it live. - -### Version and build number - -- **Version** (e.g. `1.2.0`) is prefilled from your app's `pyproject.toml`. If you - change it, the new version is saved to `pyproject.toml` when the run starts. -- **Build number** is one counter for the whole app, shared by all platforms, and - Studio assigns the next one to each run. It's what stores use to tell builds - apart (Google Play's *version code*, Apple's *build*). You can override it for - one run with the pencil, but never below the next automatic number. Publishing to - Google Play starts it above the highest one Google Play already has. - -## Credits - -Builds run on cloud machines and use **credits**, the same balance as the AI agent. -The action screen shows an estimate before you start, from how long your app's -earlier builds took. You're charged for the time the build actually takes, with a -per-run minimum. Uploading to a store afterwards is free. - -Runs that fail because of Studio's build machines rather than your app — a machine -that didn't start or stopped answering — aren't charged. See **Settings › Plan & -usage** for your balance, plans and credit packs. - -## Build settings - -Your app's build settings live in its `pyproject.toml`, under `[project]` and -`[tool.flet]` — the same file `flet build` reads. **Publish › Settings** edits them: - -- **Shared** settings apply to every platform: name, version, description, icon, - splash screen, and more. -- **Each platform's** scope adds its own settings (Android's SDK versions and - permissions, iOS's bundle ID, ...) and can **override** a shared one for that - platform only. - -Changes there are written to `pyproject.toml`, and edits you (or the agent) make to -the file show up there. See -[Publishing a Flet app](../../publish/index.md) for every setting. - -Signing keys and store accounts are never stored in your app's files. See -[Signing keys and store accounts](signing-keys-and-store-accounts.md). - -## Run details - -Open a run from Overview or Activity: - -- **Status**, cost, version and duration. A run can be canceled while it waits or - builds. -- **Artifacts**: the files it produced, to download. -- **Errors and warnings**, each linked to the step it came from. -- **Steps**: what the build did, each with its own log. Times are shown in your - local time. **Download log** saves the whole log as a text file, with the steps' - titles as headers and times in UTC. - -{/* SCREENSHOT: /img/docs/studio/publishing/run-details.png — run details with steps expanded */} - -### Downloads expire - -Studio keeps a run's files for **30 days**, and the last three successful runs of -each action. After that, Overview says **Download expired** — start a new run to -get the files again. What's on a store stays there. - -### Queued runs - -Runs wait in a queue when all build machines for a platform are busy, or when your -plan's limit of runs at a time is reached. A run that waits more than an hour is -canceled without charge. - -## When a build fails - -The run's **Errors and warnings** point at the step that failed: open it for its -log. Common causes are code that fails when the app is packaged (it runs before the -first screen), a dependency that has no build for the platform, or a setting the -platform rejects. - -The **AI agent** can help: ask it why the build failed. It reads the run's steps, -errors and log, fixes what's in your app (code, dependencies, settings), and tells -you to start the run again. - -## Questions - -### Does a build work the same as the preview? - -Not always. The preview runs your app in the browser with Pyodide, so it can only -use pure-Python packages and those built for Pyodide. A build packages your app with -real Python for the platform: packages with native code work there if they have a -build for it — see -[Python packages built in Flet](../../reference/binary-packages-android-ios.md) for -Android and iOS. - -### Can I build on my own computer instead? - -Yes. Download the app with **Download app as .zip file** in the app bar, then use -[`flet build`](../../publish/index.md). It reads the same `pyproject.toml` -settings. diff --git a/website/docs/studio/publishing/signing-keys-and-store-accounts.md b/website/docs/studio/publishing/signing-keys-and-store-accounts.md deleted file mode 100644 index 3331ae3e62..0000000000 --- a/website/docs/studio/publishing/signing-keys-and-store-accounts.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: "Signing keys and store accounts" ---- - -# Signing keys and store accounts - -Publishing needs two kinds of secrets, and Studio keeps both for you: - -- **Signing keys** sign your app's builds, proving that updates come from you. - Today: Android signing keys. -- **Store accounts** let Studio publish to a store on your behalf. Today: Google - Play service accounts. - -Both are saved to your **Studio account** — personal or team — and can be used by -all its apps. Each app selects which ones it uses, per platform. - -## Where to manage them - -- **Settings › Signing keys** and **Settings › Store accounts** list what's saved to - each of your Studio accounts, with how many apps use each one. -- **Publish › Settings › Android › Signing & accounts** selects the ones an app - uses on Android. -- An action's screen shows the ones it needs, with **Add signing key** or - **Connect Google Play** when there are none yet. What you add there is saved to - the Studio account and selected for the app. - -{/* SCREENSHOT: /img/docs/studio/publishing/settings-signing-keys.png — Settings › Signing keys with a key and its ⋯ menu */} - -Each one's **⋯** menu has: - -- **Download backup** (signing keys): the keystore and its passwords, as a `.zip`. - Only the Studio account's owner can download it, and each download is recorded. - A key Studio created shows **No backup yet** until you've downloaded one — see - [Back up your key](android.md#back-up-your-key). -- **Rename**: names are for telling them apart in lists, e.g. "Reflex Arcade upload - key". -- **Delete** (signing keys) or **Disconnect** (store accounts). Apps that used it - then show that it was deleted and ask you to select another one before their next - run. Disconnecting a Google Play account only removes it from Studio: the service - account and its permissions stay in Google Cloud and Play Console until you remove - them there. - -## How Studio keeps them safe - -- **Never in your app.** Keys, passwords and store account keys are never written - to your app's files, its version history or `pyproject.toml`, and never shown in - a build's log. Don't put them in your app's files yourself either: anyone who can - see the app's code could read them. -- **Encrypted.** Each one is encrypted on Studio's servers with its own key, which - is itself encrypted with a master key kept outside the database. -- **Signing keys** are handed to the build machine of a run that needs one, once, - for that build only, and deleted with the machine when it ends. Your app's own - code runs on that machine too, as it does when you build on your own computer. -- **Store account keys** never leave Studio's servers: uploads to a store run - there, not on the build machine. - -## Questions - -### Should each app have its own signing key? - -It's common either way. One key per app limits what a leaked key affects and lets -you hand an app over to someone else with its key. One key for all your apps is -simpler to look after. Studio suggests a name per app ("*app name* upload key") but -lets you select any key for any app — just don't change an app's key once it's on -Google Play. - -### Can a team share keys and accounts? - -Yes: keys and accounts saved to a team's Studio account can be used by all the -team's apps. Only the team's owner can download a key's backup. - -### Is my Google Play account shared between apps? - -A connected Google Play account can publish every app its service account has -permissions for in Play Console. Select it for each app that should use it. diff --git a/website/docs/studio/whats-new.md b/website/docs/studio/whats-new.md index 0a4e346d24..6550a76382 100644 --- a/website/docs/studio/whats-new.md +++ b/website/docs/studio/whats-new.md @@ -8,20 +8,6 @@ New features, improvements, and bug fixes in Flet Studio, listed in reverse-chronological order. Flet Studio ships independently of the Flet SDK — see [Flet release notes](../updates/release-notes.md) for SDK changes. -{/* TODO: set the date when Studio publishing ships. */} -## Publishing - -* **Build your app in the cloud.** Publish builds your app for Windows, macOS, - Linux, Android, iOS (Simulator) and the web, with nothing to install, and shows - each step's log as it runs. See [Publishing](publishing/index.md). -* **Publish to Google Play.** Studio signs your Android app with your key and - releases it on Internal, Closed or Open testing, or submits it to Production. If - only the upload fails, **Retry upload** sends the same build again without - charging credits. See [Publishing to Google Play](publishing/google-play.md). -* **Signing keys and store accounts.** Create or import Android signing keys, back - them up, and connect Google Play once for all your apps, in the new **Settings › - Signing keys** and **Settings › Store accounts**. - ## September 29, 2026 * **The agent sees the app it builds.** While working on your request it can run diff --git a/website/sidebars.yml b/website/sidebars.yml index 319c4aff4a..9cbbee77ee 100644 --- a/website/sidebars.yml +++ b/website/sidebars.yml @@ -951,11 +951,6 @@ docs: studio: Introduction: studio/index - Publishing: - _index: studio/publishing/index.md - Android apps: studio/publishing/android.md - Google Play: studio/publishing/google-play.md - Signing keys and store accounts: studio/publishing/signing-keys-and-store-accounts.md What's new: studio/whats-new Terms of Service: studio/terms-of-service Privacy Policy: studio/privacy-policy