DEV Community: Wasey Jamal

I upgraded Flutter and lost 6 hours. Here's the fix that takes 10 minutes.

Wasey Jamal — Mon, 25 May 2026 14:54:43 +0000

I upgraded Flutter from 3.29 to 3.41.9 for my production app — DramaHub, an OTT streaming platform with 7,500+ downloads and 2,500+ daily active users. My ad SDK (CAS) required it. What followed was 6 hours of cascading errors that all had simple fixes — if you know where to look.

This article documents every error, every root cause, and every fix in the exact order they happened. If you are upgrading Flutter on Windows, bookmark this.

My Setup

App: Flutter Android app with Firebase, Appodeal ads, CAS SDK
Old Flutter: 3.29 (1.5 years stable)
Target Flutter: 3.41.9
OS: Windows 10, PowerShell

- Old SDK location: C:\flutter (wrong — more on this below)

Error 1: BaseApplicationNameHandler

unable to resolve class 
com.flutter.gradle.BaseApplicationNameHandler
@ line 7, column 1.
import com.flutter.gradle.BaseApplicationNameHandler

Root cause: android/settings.gradle.kts was missing the entire pluginManagement block including the includeBuild line. Without it, Gradle cannot find Flutter's own Gradle plugin classes.

Fix: Your settings.gradle.kts must contain this complete block:

pluginManagement {
    val flutterSdkPath = run {
        val properties = java.util.Properties()
        file("local.properties").inputStream().use { properties.load(it) }
        val flutterSdkPath = properties.getProperty("flutter.sdk")
        require(flutterSdkPath != null) { "flutter.sdk not set in local.properties" }
        flutterSdkPath
    }
    includeBuild("$flutterSdkPath/packages/flutter_tools/gradle")
    repositories {
        google()
        mavenCentral()
        gradlePluginPortal()
    }
}
plugins {
    id("dev.flutter.flutter-plugin-loader") version "1.0.0"
    id("com.android.application") version "8.11.1" apply false
    id("org.jetbrains.kotlin.android") version "2.1.0" apply false
    id("com.google.gms.google-services") version "4.4.4" apply false
}
include(":app")

Error 2: Flutter SDK Ownership (Windows Only)

fatal: detected dubious ownership in repository at 'C:/flutter'
Unable to determine engine version

Root cause: Flutter was installed at C:\flutter by an Administrator account. Your regular user account does not own it. Flutter uses Git internally and Git blocks operations on directories owned by a different user.

Fix — do this properly, once, permanently:

Download Flutter zip from https://docs.flutter.dev/install/archive
Extract to C:\Users\yourname\flutter — NOT C:\ root
Add to PATH: C:\Users\yourname\flutter\bin
Run: git config --global --add safe.directory C:/Users/yourname/flutter
Update android/local.properties: flutter.sdk=C:\\Users\\yourname\\flutter Rule: Never install Flutter at C:\flutter. Always install in your user folder. Your user owns it, no permission issues ever again.

Error 3: Gradle Build Failed to Produce an APK

This was the hardest one. Build says BUILD SUCCESSFUL. Flutter says it cannot find the APK.

Running Gradle task 'assembleDebug'... BUILD SUCCESSFUL
Error: Gradle build failed to produce an .apk file. 
It's likely that this file was generated under 
C:\Projects\myapp\build, but the tool couldn't find it.

The APK was actually at:

android/app/build/outputs/flutter-apk/app-debug.apk

But Flutter expected it at:

build/app/outputs/flutter-apk/app-debug.apk

Root cause: The root android/build.gradle.kts was missing the build directory redirect block that Flutter's own project template includes. Without it, Gradle outputs to the default Android location instead of the location Flutter's tooling looks in.

Fix — add this to android/build.gradle.kts:

allprojects {
    repositories {
        google()
        mavenCentral()
    }
}

val newBuildDir: Directory =
    rootProject.layout.buildDirectory
        .dir("../../build")
        .get()
rootProject.layout.buildDirectory.value(newBuildDir)

subprojects {
    val newSubprojectBuildDir: Directory = newBuildDir.dir(project.name)
    project.layout.buildDirectory.value(newSubprojectBuildDir)
}

subprojects {
    project.evaluationDependsOn(":app")
}

tasks.register<Delete>("clean") {
    delete(rootProject.layout.buildDirectory)
}

This is directly from Flutter's official project template at:
flutter/packages/flutter_tools/templates/app/android-kotlin.tmpl/build.gradle.kts.tmpl

If your project was created with an older Flutter version, this block may be missing entirely.

Error 4: OutOfMemoryError — Java Heap Space

ERROR: D8: java.lang.OutOfMemoryError: Java heap space
Execution failed for task ':app:mergeExtDexDebug'

Root cause: Large ad SDKs (Appodeal, Unity Ads, AppLovin, etc.) require more JVM memory than the default 4GB during DEX merging.

Fix — update android/gradle.properties:

org.gradle.jvmargs=-Xmx8192m -XX:MaxMetaspaceSize=512m

Change 4096m to 8192m. If you have many ad network adapters, 8GB is the minimum.

Final Working Configuration

Here is the complete verified working setup:

What	Value
Flutter	3.41.9
Flutter location	C:\Users\yourname\flutter
Gradle	8.14.1
Android Gradle Plugin	8.11.1
Kotlin	2.1.0
JVM heap	8192m
build.gradle.kts	newBuildDir block present

Why Not Flutter 3.44?

Flutter 3.44 was released 9 days before I wrote this. It has a confirmed Windows bug where the APK path issue persists even with the correct build.gradle.kts. I verified this personally. Until that is patched, 3.41.9 is the recommended stable version for production Android apps on Windows.

The Build Command That Finally Worked

flutter clean
flutter pub get
flutter build apk --debug
# √ Built build\app\outputs\flutter-apk\app-debug.apk

Six hours. Four errors. All fixable. Hope this saves you time.

I build DramaHub solo — a production OTT streaming app with 7,500+ downloads and 2,500+ daily active users running at ₹0/month infrastructure cost. Follow @waseybuilds for more real production stories.

GitHub: github.com/waseyjamal

I had 1000+ unread user reports in my live Flutter app — here is how I fixed the whole system

Wasey Jamal — Sat, 23 May 2026 19:42:54 +0000

DramaHub has been live on the Google Play Store since March 2026. 7,000+ downloads. 3,000+ daily active users. Built solo. ₹0/month infrastructure cost.

Today I found out I had been completely ignoring my users for 2 months.

The original setup

Both the "Suggest a Drama" and "Report a Problem" screens were Google Forms embedded in a Flutter WebView. Simple, fast to build, works on day one.

_controller = WebViewController()
  ..setJavaScriptMode(JavaScriptMode.unrestricted)
  ..setBackgroundColor(Colors.white)
  ..loadRequest(Uri.parse(_formUrl));

Responses went to a Google Sheet I never opened. No notification. No push alert. Nothing.

I had 1000+ drama suggestions and 1000+ problem reports sitting there completely unread.

Users were putting in effort to give me feedback. I was not receiving any of it.

The problems with the WebView approach

1. White background in a dark app
Google Forms load with a white background. My entire app is dark themed — #0D0D0D background. Every time a user opened these screens they got a jarring white flash. Unprofessional.

2. Zero notification
Responses go to a Google Sheet. Unless you manually open the sheet, you never know a submission happened.

3. No communication path
Users had no way to leave contact info. I had no way to follow up. Completely one-way.

4. No offline handling
If the form failed to load, users saw a blank white screen with no error message.

What I built instead

I replaced both screens with native Flutter forms — dark themed, matching the rest of the app exactly.

On submit, the form data is sent directly to a Telegram bot via the Telegram Bot API. The bot posts a formatted message to my private Telegram group instantly.

The Telegram message format

🚨 Problem Report                    🕐 23 May 2026, 14:32
─────────────────────────────
⚠️ Type: Video not playing
🎥 Drama / Episode: Arafta Episode 56
📝 Description: Video not loading on wifi at all
─────────────────────────────
👤 Contact: @username
📱 App Version: 1.0.7
🌍 Country: IN

Full detail. Instant. Every time.

The TelegramService

class TelegramService {
  TelegramService._();
  static final TelegramService instance = TelegramService._();

  String get _botToken => AppConfigService.instance.config.telegramBotToken;
  String get _chatId => AppConfigService.instance.config.telegramChatId;

  Future<bool> sendMessage(String message) async {
    final uri = Uri.parse(
      'https://api.telegram.org/bot$_botToken/sendMessage',
    );
    final response = await http.post(
      uri,
      headers: {'Content-Type': 'application/json'},
      body: jsonEncode({
        'chat_id': _chatId,
        'text': message,
        'parse_mode': 'HTML',
      }),
    ).timeout(const Duration(seconds: 10));

    return response.statusCode == 200;
  }
}

Key design decisions:

Bot token and chat ID are never hardcoded — fetched from app_config.json via Cloudflare Worker at runtime
Admin can rotate the token anytime from the config — zero app update needed
Uses existing http package — no new dependency

Silent data attached to every submission

The user never sees these — they just appear in the Telegram message:

// App version — reads from pubspec.yaml automatically
final info = await PackageInfo.fromPlatform();
final appVersion = info.version; // "1.0.7"

// Country — from device locale, no permission needed
final locale = WidgetsBinding.instance.platformDispatcher.locale;
final country = locale.countryCode ?? 'Unknown'; // "IN"

Spam protection

// 1 hour cooldown between submissions per user
static const String _cooldownKey = 'report_problem_last_submit';
static const int _cooldownMinutes = 60;

Future<bool> _isCoolingDown() async {
  final prefs = await SharedPreferences.getInstance();
  final lastSubmit = prefs.getInt(_cooldownKey);
  if (lastSubmit == null) return false;
  final diff = DateTime.now().millisecondsSinceEpoch - lastSubmit;
  return diff < Duration(minutes: _cooldownMinutes).inMilliseconds;
}

The security mistake I made

While setting this up, I made a mistake — I added the Telegram bot token directly to app_config.json in my public GitHub repository.

GitHub sent me a secret exposure alert within minutes.

{
  "telegram_bot_token": "8940932851:XX",
  "telegram_chat_id": "-51505959XX"
}

Anyone with read access to the repo could see the token and control the bot.

How I fixed it

Step 1 — Revoke immediately
Went to @botfather → /mybots → API Token → Revoke. New token generated in 10 seconds.

Step 2 — Make repo private
But wait — my Cloudflare Worker fetches from this GitHub repo to serve data to the app. Making it private would break everything.

The fix: add a GitHub PAT as an encrypted environment variable in Cloudflare Worker.

// In Cloudflare Worker — before:
githubResponse = await fetch(githubUrl, {
  headers: { 'User-Agent': 'DramaHub-CDN/1.0' },
});

// After:
githubResponse = await fetch(githubUrl, {
  headers: {
    'User-Agent': 'DramaHub-CDN/1.0',
    'Authorization': `token ${env.GITHUB_TOKEN}`,
  },
});

env.GITHUB_TOKEN is stored as an encrypted secret in Cloudflare Worker settings — never in code, never visible.

Step 3 — Make repo private
With the Worker authenticated, the repo can be private. The full pipeline:

Flutter App
→ Cloudflare Worker (authenticated with GITHUB_TOKEN)
→ Private GitHub repo
→ Returns app_config.json with telegram_bot_token and telegram_chat_id
→ AppConfigService loads them at runtime
→ TelegramService uses them to send messages

Zero hardcoding anywhere. Admin panel can update the token via app_config.json — no app update needed.

The form UI

Both screens follow the same pattern — native Flutter, fully dark themed:

TextFormField(
  style: AppTypography.body.copyWith(color: AppColors.white),
  cursorColor: AppColors.primaryRed,
  decoration: InputDecoration(
    filled: true,
    fillColor: AppColors.cardBackground, // #1C1C1C
    focusedBorder: OutlineInputBorder(
      borderSide: BorderSide(color: AppColors.primaryRed, width: 1.5),
    ),
  ),
)

Success state replaces the form entirely after submission — no snackbar, no dismissable toast:

// After successful submit:
setState(() => _submitted = true);

// Build method:
body: _submitted ? _buildSuccessState() : _buildForm(),

What changed for users

Before	After
White Google Form in dark app	Native dark themed form
Submissions silently disappear	Instant Telegram notification
No contact option	Optional Telegram/email field
No error handling	Proper offline error state
No success feedback	Full success screen

The real lesson

I was so focused on building new features that I never went back to check if existing ones were actually working.

A 3,000 DAU app is not a side project. Real people use it every day. They deserve to be heard.

Now they are.

DramaHub is live on Google Play Store. Built solo. ₹0/month infrastructure.
Architecture: Flutter + GitHub as database + Cloudflare Workers CDN + Firebase

I built a streaming app with 7,000+ downloads at ₹0/month — here's the exact architecture

Wasey Jamal — Fri, 22 May 2026 05:50:31 +0000

I'm Wasey, a solo developer from Varanasi, India. I built DramaHub —
a fully live OTT streaming app on Google Play Store. 7,000+ downloads,
1,000+ daily active users, sub-1% crash rate, ₹0/month infrastructure.

Here's the exact architecture that makes it possible.

The Problem

I had zero budget for servers. A typical OTT backend needs:

A backend server (₹3,000–15,000/month)
A database (₹1,500+/month)
A CDN (₹500+/month)

I had ₹0. So I had to think differently.

GitHub as the Database

All drama content, episode metadata, and app config live as JSON files
in a public GitHub repository. Free. Unlimited. Versioned automatically.

Every drama looks like this in JSON:

{
"id": "drama_001",
"title": "Drama Title",
"thumbnail": "https://cdn.jsdelivr.net/...",
"episodes": [
{
"ep": 1,
"title": "Episode 1",
"source": "youtube_id_here"
}
]
}

The app fetches this JSON on launch, caches it locally, and serves
content instantly on subsequent opens.

Cloudflare Workers as the CDN Proxy

Hitting GitHub raw URLs directly has rate limits. So I built a
Cloudflare Worker that sits in front of GitHub:

Caches all JSON responses at the edge globally
Handles unlimited traffic
Auto-invalidates when content version changes
Cost: ₹0

Architecture: Flutter app → Cloudflare Worker → GitHub raw JSON

The Dual Player System

DramaHub runs two video players:

Primary — YouTube WebView player
Most content is sourced from YouTube. The app uses a WebView-based
player with custom controls and a URL whitelist for security.

Secondary — Custom video player with Cloudflare R2
For self-hosted content, I use a custom player backed by
Cloudflare R2 storage.

Both players are switchable instantly from the admin panel via
remote JSON config. No APK update needed — ever.

The Admin Panel

This is the most important part of the architecture.

The admin panel is a Flutter Web app that communicates directly
with the GitHub REST API using Base64 encoding and SHA-based
conflict detection. From the admin panel I can:

Add/edit/delete dramas and episodes
Toggle ads per screen with cooldown timers
Switch between YouTube and custom player instantly
Change CDN URLs without any release
Force update all users
Control app config globally

Everything is remote. Everything is instant. No app store review cycle.

The Crash That Taught Me Everything

One day the app went completely down. Every user got a crash on launch.

The reason: my Cloudflare Worker wasn't caching properly. Every request
was hitting GitHub directly and I burned through the API rate limit
in minutes.

I fixed the Worker caching. Then I built a full backup system:

Direct GitHub raw URL as fallback
Backup Worker as secondary fallback
Switchable from admin panel in under 60 seconds

No APK release needed. I built that entire system in one night.

Firebase Integration

Even with zero backend cost, I use Firebase for:

Anonymous Auth
FCM push notifications with deep links
Crashlytics for real-time crash monitoring
Analytics with 7 custom tracked events
Atomic view counter increments via Firestore REST API

Results After 18 Months

📦 7,000+ downloads
👥 1,000+ daily active users

💥 Sub-1% crash rate
💰 ₹0/month infrastructure cost
📱 Live on Google Play Store

Key Lesson

Build your admin panel first. Remote config is not a feature —
it's survival. The ability to change anything without a new release
has saved me dozens of times.

GitHub as a database works at production scale if you architect
the caching layer correctly.

GitHub: github.com/waseyjamal/dramahub
Play Store: https://play.google.com/store/apps/details?id=com.dramahub.drama_hub
Twitter: @waseybuilds

Happy to answer any questions about the architecture.