Introducing flet-practical, a unified, production-ready Flet extension suite bundling 7 essential device and system capabilities

[Twilight0]

Flet Practical Extension Suite

A unified, production-ready Flet extension suite bundling 7 essential device and system capabilities for Mobile (Android & iOS), Desktop (Linux, Windows, macOS), and Web:

1. 📋 Clipboard: Full cross-platform clipboard support (Text, HTML, raw images, and file paths).
2. 🔔 Local & Persistent Notifications: Trigger local and ongoing status bar notifications.
3. 💡 Screen WakeLock: Prevent the device display from sleeping during long tasks or audio playback.
4. 🎙️ Edge Neural TTS: High-quality speech synthesis using Microsoft's Edge neural voice engine (300+ voices).
5. 🚀 Auto-Start on Boot: Configure automatic app startup on device boot and system launch.
6. 💳 In-App Purchases: Manage Google Play & Apple App Store in-app billing, consumables, and subscriptions.
7. 📤 Native Share Intent: Open the native OS Share Sheet (Android ACTION_SEND, iOS UIActivityViewController, Web Share API).

Examples

Run any demo independently:

uv run python examples/main.py             # Main Hub (All 7 Features)
uv run python examples/01_clipboard.py     # Clipboard demo
uv run python examples/02_notifications.py # Notifications demo
uv run python examples/03_wakelock.py      # WakeLock demo
uv run python examples/04_tts.py           # TTS demo
uv run python examples/05_autostart.py     # AutoStart demo
uv run python examples/06_iap.py           # In-App Purchases demo
uv run python examples/07_share.py         # Native Share Intent demo

Github repo:

https://github.com/Twilight0/flet-practical

License

MIT License.

[yst-one]

How do you implement background running for an APK? I noticed that the Python thread stops when returning to the Android desktop.

[Twilight0]

Flet is running in an event-loop, isn't it? So not static apparently. To answer your question in detail I am still investigating how it's going to work because it's necessary for my walkertracker app.

[Twilight0]

So, after investigating, here's the verdict:

Why does the Python thread stop when returning to Android desktop?

On an APK the Python isolate lives inside the Activity process.
Home → onPause() → onStop() — without a ForegroundService Android (12+, especially Xiaomi/Samsung with battery optimization) kills the FlutterEngine and thus
the Python bridge in seconds.

Wakelock (wakelock_plus) alone only prevents screen sleep while the app is in the foreground — it does not keep you alive in background.

Fixed in flet-practical 0.2.0

BackgroundService wraps flutter_foreground_task 11.0.1 as a ForegroundService with an ongoing notification. flet-practical also adds battery-optimization
helpers on the same class.

Install

pip install "flet-practical @ git+https://github.com/Twilight0/flet-practical.git@v0.2.0"
# flutter side: flutter_foreground_task 11.0.1 is already in flet_practical/pubspec.yaml

Usage

from flet_practical import BackgroundService

bg = BackgroundService(page)

# 1. One-time: disable battery optimization (otherwise Xiaomi/Samsung still kills)
if not await bg.is_ignoring_battery_optimizations():
   await bg.request_ignore_battery_optimization()
   # fallback: await bg.open_ignore_battery_optimization_settings()

# 2. Keep Python alive after Home
await bg.start(title="InstaSave", text="Upscaling in background…")
# ... your asyncio Thread / download queue / upscale_worker keeps running ...
# await bg.is_running() -> bool
# await bg.restart()
await bg.stop()

Battery helper

All three helpers live on BackgroundService:

• await bg.is_ignoring_battery_optimizations() -> bool
• await bg.request_ignore_battery_optimization() -> bool — shows system ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS dialog
• await bg.open_ignore_battery_optimization_settings() -> bool — fallback to settings

Call from SettingsView as a one-time Switch / Banner (Background execution — Disable battery optimization), or auto-prompt before bg.start() in download_view.py /
upscaler_view.py.

Example

See examples/08_background.py — start/stop buttons + battery buttons + a counter that keeps ticking after Home → return after 10s to verify.

Manifest (auto via flet build apk when flutter_foreground_task is present):

<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_DATA_SYNC" />
<uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />

Without this the Activity is STOPPED and the Python thread/asyncio is suspended — this is expected Android behavior, not a Flet bug.

[yst-one]

I’m a bit confused. Your extension passes page when creating a new class. What is the purpose of this page parameter? I can’t quite figure it out.

notifications = Notifications(page=page)

[Twilight0]

Great question! Here is why page is involved:

In Flet, Python does not talk to Android or Flutter plugins in a vacuum — all communication between Python and native device APIs happens over Flet's Page Session bridge (page.session.invoke_method(...)).

Specifically, page is used for:

1. The Native RPC Bridge: Calling Flutter plugins (like flutter_local_notifications or pasteboard) requires sending method calls through page.session. Without page, there is no active channel to reach Flutter.
2. Mobile Service Registration: On Android/iOS, services must be attached to page.services so the Flutter engine registers their control IDs.
3. Automatic Platform Routing: flet-practical inspects page.platform to automatically route between Android platform channels, desktop OS tools (notify-send, xclip), and Web APIs.

Note: In flet-practical, passing page is actually optional! If you don't pass it, the extension automatically discovers the active page from Flet's context:

# You can just do this:
notifications = Notifications()
await notifications.show("Title", "Body")

# Explicitly passing page is supported if you have multiple pages or prefer explicit DI:
notifications = Notifications(page=page)

Additionally, regarding Android builds: because certain Android-specific files (like AndroidManifest.xml permissions and service entries) need to be configured for features like persistent background tasks to work seamlessly on this platform, I am planning to either support loading another cookiecutter template during the build or submit a PR upstream to flet-cli — whichever results in the best developer experience.