That is where FCM Deck comes in. FCM Deck is a tool that you can use in your browser to send Firebase push notifications. You do not need to write any code or set up any backend. Whether you are a developer testing a feature or a product manager doing a quick test FCM Deck makes the whole process a lot easier.

So what is FCM Deck? FCM Deck is a web console for sending Firebase Cloud Messaging notifications. It is like the Firebase Consoles notification composer. It is faster and more flexible. The best part is that your keys never leave your browser. Your Firebase service account JSON is stored locally in your browser only. It is never uploaded to any server, never logged, never shared.

To get started with FCM Deck you need two things. First you need a Firebase Service Account JSON file. You can get this by going to your Firebase project then Project Settings, Service Accounts and finally Generate new private key. Download the JSON file. Second you need a device token or topic name. This is the FCM registration token of the device you want to send the notification to.

Once you have these two things you can start using FCM Deck. Here is how you do it.

• First go to fcmdeck.web.app. Click Add Project.
• You will be asked for a Project Display Name and your Service Account JSON.
• Hit Save. Your project will appear in the sidebar.

Now you can compose your notification. FCM Deck gives you two modes: Simple Mode and Custom Payload Mode. Simple Mode is perfect for tests. You just need to fill in the Target Type, Priority, Title, Body, Image URL and Data Payload. This mode covers everyday use cases.

Custom Payload Mode is for power users. You can write a raw FCM message JSON yourself giving you control over every field. FCM Deck even provides to-use templates. You can. Format your JSON right in the editor before sending.

Once your message is composed, hit Send Notification. FCM Deck will show you the result away. Every notification you send is logged in the History tab so you can review past sends without retyping everything.

FCM Deck is better than the alternatives. The Firebase Console has a built-in notification composer. It is limited in flexibility and does not support sending to a raw device token easily.. Curl work fine, but they require you to manually construct the Authorization header and manage OAuth tokens.

FCM Deck is simple, flexible and private. It is free. You do not need to sign up for an account. You can clear your history anytime if you are working with tokens.

So who is FCM Deck for? It is for developers who are testing push notification flows during feature development. It is for QA engineers who are verifying notification behavior across device types. It is for product managers who need to trigger a test notification without asking a developer. It is for teams that do not want to build an internal notification tool from scratch.

FCM Deck is an useful tool that makes sending Firebase push notifications easy. It is free. It respects your privacy. Give it a try at fcmdeck.web.app. You will probably have your notification sent within five minutes.

Have you used FCM Deck or a similar tool, in your workflow? I would love to hear how you are handling push notification testing.

Open Source & Contributions

FCM Deck is also an open-source project. If you want to improve it, suggest features, or contribute, you can check out the code on GitHub:
https://github.com/praveenkumarytc/fcmDeck

Contributions, issues, and feedback are always welcome

📌 Why CI/CD for Flutter?

CI/CD (Continuous Integration / Continuous Deployment) helps you:

• Automatically build your app on every push
• Run tests and ensure code quality
• Distribute builds to testers without manual effort
• Speed up your development workflow

🧰 Prerequisites

Before starting, make sure you have:

• A Flutter project pushed to GitHub
• Firebase project created
• Firebase App Distribution enabled
• Firebase CLI installed locally

npm install -g firebase-tools

• Logged in to Firebase:

firebase login

🔥 Step 1: Setup Firebase App Distribution

1. Go to Firebase Console
2. Select your project
3. Navigate to App Distribution
4. Add your Android/iOS app
5. Download google-services.json (for Android)

🔑 Step 2: Generate Firebase Token

Run the following command:

firebase login:ci

This will generate a CI token.

👉 Copy this token — we’ll use it in GitHub Secrets.

🔐 Step 3: Add GitHub Secrets

Go to your GitHub repo:

👉 Settings → Secrets → Actions → New Repository Secret

Add the following:

• FIREBASE_TOKEN → paste your Firebase CI token
• APP_ID → Firebase App ID (from Firebase Console)

⚙️ Step 4: Create GitHub Action Workflow

Create a file:

.github/workflows/flutter_ci_cd.yml

Add the following configuration:

name: Flutter CI/CD

on:
  push:
    branches:
      - main

jobs:
  build:
    name: Build & Distribute
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Repo
        uses: actions/checkout@v3

      - name: Setup Flutter
        uses: subosito/flutter-action@v2
        with:
          flutter-version: '3.22.0'

      - name: Install Dependencies
        run: flutter pub get

      - name: Run Tests
        run: flutter test

      - name: Build APK
        run: flutter build apk --release

      - name: Install Firebase CLI
        run: npm install -g firebase-tools

      - name: Distribute to Firebase
        run: |
          firebase appdistribution:distribute build/app/outputs/flutter-apk/app-release.apk \
          --app ${{ secrets.APP_ID }} \
          --groups "testers" \
          --token ${{ secrets.FIREBASE_TOKEN }}

📦 Step 5: Push and Trigger CI/CD

Now just push your code:

git add .
git commit -m "Setup CI/CD"
git push origin main

🎉 GitHub Actions will automatically:

• Install Flutter
• Run tests
• Build APK
• Upload to Firebase App Distribution

👥 Managing Testers

In Firebase Console:

• Add testers (emails)
• Create groups (e.g., testers, qa-team)
• Use --groups flag in workflow

🛠 Optional Enhancements

You can improve your pipeline by:

• Adding Flutter analyze:

- run: flutter analyze

• Building AAB instead of APK:

flutter build appbundle

• Adding iOS build support (macOS runner)

🚨 Common Issues

IssueSolutionFirebase auth errorRegenerate tokenBuild failsCheck Flutter versionApp not uploadedVerify App ID

🎯 Conclusion

With GitHub Actions + Firebase App Distribution, you now have a fully automated CI/CD pipeline for your Flutter app. This setup ensures faster releases, better testing, and a smoother development workflow.

💬 Final Thoughts

CI/CD is not just for big teams — even solo developers can benefit massively. Once you set this up, you’ll never want to go back to manual builds again.

In this article, you’ll learn how to use the flutter_bg_location plugin to track location continuously in foreground and background on Android and iOS.

✨ Why Use flutter_bg_location?

This plugin is built with a developer-first mindset, focusing on:

• Reliable background execution on Android & iOS
• Battery-efficient tracking
• Clean and minimal Flutter API
• Platform-compliant implementation

Ideal for production-grade Flutter apps that need dependable location updates even when the app is not visible.

📦 Step 1: Add the Plugin

Add the dependency to your pubspec.yaml:

dependencies:
  flutter_bg_location: ^1.0.0

Run:

flutter pub get

🔐 Step 2: Platform Configuration

🤖 Android Setup

Open android/app/src/main/AndroidManifest.xml and add:

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/>
<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION"/>
<uses-permission android:name="android.permission.FOREGROUND_SERVICE"/>

🔹 Notes:

• Background location requires explicit user approval on Android 10+
• The plugin uses a foreground service to ensure reliability
• Do not forget to request runtime permissions

🍎 iOS Setup

Enable Background Modes

In Xcode:

• Select Runner
• Go to Signing & Capabilities
• Enable Background Modes
• Check Location updates

Update Info.plist

<key>NSLocationWhenInUseUsageDescription</key>
<string>This app requires location access to track user activity.</string>

<key>NSLocationAlwaysAndWhenInUseUsageDescription</key>
<string>This app requires background location access.</string>

<key>UIBackgroundModes</key>
<array>
  <string>location</string>
</array>

🔹 Notes:

• Apple reviews background location usage carefully
• Always explain why background access is needed

🚀 Step 3: Start Background Location Tracking

import 'package:flutter_bg_location/flutter_bg_location.dart';

void startTracking() {
  FlutterBgLocation.startLocationService(
    distanceFilter: 10,     // meters
    updateInterval: 5000,   // milliseconds
  );

  FlutterBgLocation.onLocation((location) {
    print('Latitude: ${location.latitude}');
    print('Longitude: ${location.longitude}');
    print('Accuracy: ${location.accuracy}');
    print('Altitude: ${location.altitude}');
  });
}

✅ Works in:

• Foreground
• Background
• Screen-locked state (platform dependent)

🛑 Step 4: Stop Location Tracking

Always stop tracking when not required:

void stopTracking() {
  FlutterBgLocation.stopLocationService();
}

This helps conserve battery and aligns with platform best practices.

⚙️ Configuration Options

You can fine-tune tracking behavior:

• Update Interval — control how often updates are received
• Distance Filter — receive updates only after movement
• Accuracy Settings — balance precision vs battery usage

This flexibility makes the plugin suitable for both high-precision and low-power use cases.

🔋 Battery Optimization Tips

• Increase update interval when high accuracy is not required
• Stop tracking when the user logs out or completes a task
• Avoid unnecessary background listeners

The plugin is optimized for long-running sessions, but smart configuration is key.

🧪 Common Use Cases

• Fitness & health tracking
• Delivery & logistics
• Attendance & workforce tracking
• Ride-sharing apps
• Safety & emergency tracking

🧠 Final Thoughts

Handling background location in Flutter doesn’t need to be complex.

With flutter_bg_location, you get:

• A clean Flutter API
• Android & iOS-compliant background execution
• Reliable performance for real-world production apps

👉 View the plugin on pub.dev:
https://pub.dev/packages/flutter_bg_location

Feedback, suggestions, and contributions are always welcome 💙
Happy building with Flutter 🚀

If you’ve ever shared a Flutter app publicly — whether on Play Store, App Store, or GitHub — you’ve probably wondered:

“How do I secure my API keys and endpoints so nobody can misuse them?”

This is an important question because Flutter apps are client-side, meaning any code shipped inside your APK/IPA can be reverse-engineered. Hardcoding secrets directly inside your Dart files can expose APIs, private endpoints, and paid services.

The truth is:
You cannot fully hide secrets in a Flutter client.
But you can make it extremely hard to extract them — and more importantly, design your architecture so leaking keys doesn’t expose anything harmful.

This guide covers everything you need to know to secure API keys and endpoints in Flutter, including recommended patterns for 2025.

🧨 Why You Should Never Hardcode API Keys in Flutter

APK/IPA files can be decompiled using tools like:

• jadx (for Android)
• Hopper or Ghidra (for iOS)
• Flutter Decompiler tools

If your API key is in your code like this:

const apiKey = "ABCD-12345-SECRET";

Anyone can extract it in minutes.

This can lead to:

• Unauthorized API usage
• Exhausted API quotas
• Billing charges
• Compromised backend security

So let’s explore safer ways.

✅ Option 1: Use a Backend Proxy (Best & Recommended)

This is the only real secure method.

Instead of calling the external API directly from Flutter:

Flutter App → Your Backend → Third-party API

Benefits

✔ API key lives on server only
✔ You can enforce authentication (JWT sessions, OAuth, Firebase Auth)
✔ You can rate-limit & block suspicious activity
✔ Allows rotating API keys easily

Example Setup

1. Flutter calls your backend

final response =
    await http.get(Uri.parse("https://yourserver.com/weather?city=Delhi"));

2. Backend adds API key internally

const result = await axios.get(
  `https://api.openweathermap.org/data/2.5/weather?q=${city}&appid=${process.env.API_KEY}`
);

With this approach, your API key is never shipped inside the app.

🔐 Option 2: Use Flutter Environment Variables (obfuscation only)

Flutter supports flavors & env variables.

Add .env file (do NOT commit)

API_URL=https://example.com
API_KEY=xxxxxx

Use flutter_dotenv

dependencies:
  flutter_dotenv: ^5.1.0

Load it:

await dotenv.load();

final key = dotenv.env["API_KEY"];

⚠ Warning

This is not secure.
Env variables still get bundled inside your build → can be extracted.

Use this only for:

• Non-sensitive constants
• Dev/staging flags

🔐 Option 3: Platform-specific Secret Storage (better but not perfect)

Store secrets in:

Android — local.properties + NDK

iOS — Config.xcconfig

Example:

android/local.properties

API_KEY=xxxxx

Access using BuildConfig:

String key = BuildConfig.API_KEY;

Pros

✔ Harder to extract than Dart code
✔ Obfuscation + Native layers

Cons

❌ Still extractable via reverse engineering
❌ Maintenance overhead

Use this only when backend proxy is not possible.

🔐 Option 4: Flutter Code Obfuscation

Helps hide string literals and method names.

Enable obfuscation:

flutter build apk --obfuscate --split-debug-info=build/debug-info

Pros

✔ Makes reverse engineering harder
✔ Removes readable names

Cons

❌ Does NOT hide secrets
❌ Only slows attackers

Use it as an additional layer, not the main solution.

🛑 What You Should Never Do

❌ Put API keys inside Dart files
❌ Commit API keys to GitHub
❌ Store Firebase service account credentials inside Flutter
❌ Ship private endpoints inside the app
❌ Assume obfuscation = security

🛡 Best Architecture for API Security (Recommended Setup)

Final Stack:

Flutter → Your Secure Backend → Third-Party API
            ↑
         Auth (JWT / Firebase Auth)

Must-have security rules:

1. Use backend proxy for any private API
2. Apply rate limiting (Cloudflare / Nginx / API Gateway)
3. Validate user tokens on the backend
4. Store secrets in environment variables on server
5. Rotate API keys every few months

💡 Example: Secure Weather API in Flutter

❌ Bad (direct, exposed)

const apiKey = "12345-ABCDE";
final url = "https://api.weather.com?apikey=$apiKey";

✅ Good (indirect, protected)

Flutter call

final res = await http.get(Uri.parse("https://myapp.com/weather?c=Delhi"));

Your server

app.get("/weather", async (req, res) => {
  const city = req.query.c;
  const data = await weatherService.fetchWeather(city); // uses API_KEY internally
  res.json(data);
});

🧿 Protecting Endpoints Used by the App

Even your own backend endpoints should be secured.

Use JWT

final token = await FirebaseAuth.instance.currentUser?.getIdToken();

Send with every request:

headers: {"Authorization": "Bearer $token"}

Server verifies token before responding.

Add rate limiting

• Cloudflare Rules
• Nginx limit_req
• Express express-rate-limit

No endpoint should respond without authentication

Especially:

• /getUserData
• /updateProfile
• /admin/**
• /payment/**

🧵 Conclusion

Securing API keys in Flutter isn’t about hiding them — it’s about architecting your app correctly.

✔ What actually works

• Use your own backend
• Store secrets server-side
• Add authentication & rate limiting

✔ What helps but is not full security

• Dotenv
• Obfuscation
• Native secret storage

❌ What never works

• Hardcoding keys inside Flutter

If you follow the recommended structure, you can safely scale your Flutter app without fearing API abuse or key leakage.

TOON is a lightweight, line-oriented serialization format that exposes a token stream as the primary structure. Each value is represented by a token header followed by optional payload fields. It aims to be easy to parse in streaming environments (low memory), friendly to line-oriented tools, and explicit about types so small embedded systems or simple shell scripts can read and produce it reliably.

Motivation

JSON is great for nested structures but requires full-tree parsing for some operations and can be verbose for typed data. YAML is flexible but has complex parsing edge-cases. Binary formats (CBOR, MessagePack) are compact but harder to debug.

TOON sits between human-readable and tokenized/binary formats:

• predictable token-per-line structure for streaming/parsing
• explicit, simple typing (no guessing)
• easy to append to logs or pipes (line-oriented)
• small parser (handwritten) fits tiny runtimes

Think: system logs that carry structured data, CLI tools that emit typed events, or embedded devices that must stream telemetry with minimal CPU.

Syntax overview (short)

• File is a sequence of entries (one per line). Blank lines ignored.
• Each entry begins with an ASCII token name (uppercase letters, digits, _) followed by a colon :.
• After the token header, optional fields separated by pipes | (pipe characters).
• Fields can be:
• k=v pairs (string key with typed value),
• positional values (no key),
• or JSON payload (when the last field starts with { or [).
• Types are indicated with suffixes in values or by token semantics; common scalar types are: s (string), i (integer), f (float), b (boolean), t (timestamp/ISO8601), j (JSON blob), B64 (base64).
• Comments: start with # as first non-space char on a line.

Example single-line entry:

EVT:time=t:2025-11-16T07:18:00Z|level=s:info|msg=s:User logged in|user_id=i:1234

Formalized example and grammar

Token header

<TOKEN> := [A-Z0-9_]+
Entry := TOKEN ':' FieldList?
FieldList := Field ( '|' Field )*
Field := Keyed | Positional | JsonBlob
Keyed := Key ':' TypeTag? Value
Key := [a-zA-Z_][a-zA-Z0-9_-]*
TypeTag := [a-zA-Z0-9]+    # optional, like i, f, b, t, j, B64
Value := <string-with-escaping>
Positional := TypeTag? Value
JsonBlob := 'j:' '{' ... '}' | 'j:' '[' ... ']'

Value encoding rules

• : separates a key/type tag block from the value. Example: age:i:42
• If no TypeTag is given, s (string) is assumed.
• Strings may contain escaped \| (escaped pipe), \\, and \n sequences. Single-line entries are recommended.
• Base64 for binary: photo:B64:/9j/4AAQSkZJRgABAQAAAQABAAD...

Examples

Simple event log

EVT:time:t:2025-11-16T07:18:00Z|level:s:info|msg:s:Connected to server|lat:f:28.6139|lon:f:77.2090

Key-value record

USER:create|id:i:9876|name:s:Ashish Patel|email:s:ashish@example.com|active:b:true

Positional tokens (compact telemetry)

TMP:28.4|23.1|27.9   # interpreted as three floats (if schema known)

Embedded JSON (for complex nested object)

SCHED:j:{"match":"RR vs CSK","start":"2026-04-10T14:30:00Z","venue":"Chennai"}

Binary data (base64)

PHOTO:user_id:i:9876|image:B64:/9j/4AAQSkZJRgABAQAAAQABAAD...

Parsing model & streaming benefits

Because each entry is a token plus a short, parseable set of fields, parsers can:

1. Read line-by-line (no need to buffer nested braces).
2. Switch on TOKEN and decide how to interpret remaining fields.
3. Use minimal lookahead — perfect for embedded devices or streaming log processors.

A tiny pseudo-parser (conceptual):

for each line:
    skip blank/comments
    token, rest = split_at_first(':')
    fields = split_escaped(rest, '|')
    for field in fields:
        if looks_like_json(field): parse_json(field)
        else if has_two_colons(field): key, typ, val = split_first_two(':')
        else if has_one_colon(field): key, val = split_first(':'); typ='s'
        else: treat as positional with optional type prefix
    emit object(token, fields_map, positional_list)

This approach avoids full-document tree building and is straightforward to implement in ≤50 lines in C, Go, Rust, or Python.

Comparison: TOON vs JSON, YAML, MessagePack

• Human readability: JSON > TOON > MessagePack; TOON is intentionally compact and tokenized for humans who read logs.
• Streaming: TOON >> JSON (for nested objects) because TOON is line-oriented.
• Typed values: TOON has explicit simple typing (i, f, b, t, B64) which is friendlier than JSON's implicit typing.
• Binary compactness: MessagePack/CBOR win. TOON is text-first, trading size for readability.
• Parser complexity: TOON parsers are trivial compared to YAML and robust JSON libraries.

Use-cases

• Telemetry and event logging where you want typed, append-only lines.
• CLI tools that produce structured events consumable by awk, jq-like filters (with a lightweight pre-parser).
• Embedded devices that need structured output, but cannot afford a full JSON stack.
• Audit trails where token semantics (e.g., AUTH_SUCCESS, PAYMENT) should be easily grep-able.

Example toolchain: convert TOON → JSON (one-liner idea)

A small script can convert TOON to JSON objects — useful for piping to downstream systems:

• Read line, parse fields into dict, map typed values, print JSON object per line.
• Because TOON is token-first, you can route tokens to different consumers easily.

Pros & Cons

Pros

• Extremely predictable, good for streaming.
• Small parser implementation effort.
• Explicit typing reduces ambiguity.
• Line-oriented — appendable and easy to grep/sed/awk.

Cons

• Not optimized for deeply nested structures (JSON wins there).
• Slightly more verbose than compact binary formats.
• Requires consumers to know type-tags and token semantics (schema).

Suggested Standard Practices

• Use UTC ISO8601 for timestamps and t tag.
• Keep entries one line if you rely on line-oriented tools.
• Define a small token registry for your application domain (token descriptions, field names and types).
• Include a header token (optional) at file start to declare schema version:
• META:ver:s:1.0|created:t:2025-11-16T07:00:00Z

Quick reference (cheat sheet)

TOKEN: <name>  # uppercase
FIELDS: key:TYPE:VALUE  OR  TYPE:VALUE  OR  raw-json -> j:{...}
TYPES: s (string), i (int), f (float), b (bool), t (timestamp), j (json), B64 (binary)
SEPARATOR: |  # escape as \|
COMMENTS: # at start of line

Closing thoughts

TOON is intentionally pragmatic: not a replacement for JSON in every case, but an alternative for scenarios where streaming, tiny parsers, and human-inspectable typed logs matter. If you care about appendable telemetry, low-memory parsing, and readable auditing, TOON might be a fit.

If you like this idea, next steps could include:

• A short reference implementation in Go/Python/C.
• A tiny toon2json CLI that streams conversion.
• A schema registry format (optional) to describe tokens and allowed fields.

Learn how to build a reliable Flutter background location tracking system using a native Kotlin Foreground Service, EventChannel, and AlarmManager — works even when the app is closed or the device restarts.

🧩 Table of Contents

1. Introduction
2. Project Overview
3. Architecture: How it Works
4. Android Setup
5. Flutter → Android Communication (Channels)
6. Foreground Location Service (Kotlin)
7. Flutter Side: Listening to Events
8. Testing the Setup
9. Final Notes and Limitations
10. Full Source

🪐 1. Introduction

Flutter’s built-in location plugins can track your position when the app is open — but when you close or kill the app, updates stop.

In this article, I’ll show you how to create a custom background location system in Flutter using:

• Native Android Foreground Service
• AlarmManager for restart
• BootCompletedReceiver for reboot persistence
• EventChannel & MethodChannel for communication

It updates your location continuously in background — even if Flutter is not running.

⚙️ 2. Project Overview

We’ll build a small system with:

🧠 3. Architecture: How It Works

🛠️ 4. Android Setup

4.1 Permissions in AndroidManifest.xml

Add these above <application>:

<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

4.2 Inside <application>...</application>

<service
    android:name=".LocationService"
    android:exported="false"
    android:foregroundServiceType="location" />

<receiver
    android:name=".RestartReceiver"
    android:exported="false" />

<receiver
    android:name=".BootCompletedReceiver"
    android:enabled="true"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.BOOT_COMPLETED" />
    </intent-filter>
</receiver>

💡 5. Flutter ↔ Android Communication

MainActivity.kt

This connects your Flutter side to the native service.

package com.example.background_location

import android.content.Intent
import android.os.Build
import android.os.Bundle
import android.util.Log
import io.flutter.embedding.android.FlutterActivity
import io.flutter.embedding.engine.FlutterEngine
import io.flutter.plugin.common.EventChannel
import io.flutter.plugin.common.MethodChannel

class MainActivity : FlutterActivity() {

    private val METHOD_CHANNEL = "background_location/methods"
    private val EVENT_CHANNEL = "background_location/events"
    private var eventSink: EventChannel.EventSink? = null

    override fun configureFlutterEngine(flutterEngine: FlutterEngine) {
        super.configureFlutterEngine(flutterEngine)

        // 🔧 Method Channel
        MethodChannel(flutterEngine.dartExecutor.binaryMessenger, METHOD_CHANNEL)
            .setMethodCallHandler { call, result ->
                when (call.method) {
                    "startService" -> {
                        startService()
                        result.success(true)
                    }
                    "stopService" -> {
                        val stopIntent = Intent(this, LocationService::class.java)
                        stopService(stopIntent)
                        result.success(true)
                    }
                    "checkServiceAlive" -> {
                        result.success(LocationService.isRunning)
                    }
                    else -> result.notImplemented()
                }
            }

        // 📡 Event Channel
        EventChannel(flutterEngine.dartExecutor.binaryMessenger, EVENT_CHANNEL)
            .setStreamHandler(object : EventChannel.StreamHandler {
                override fun onListen(arguments: Any?, events: EventChannel.EventSink?) {
                    eventSink = events
                    LocationService.setEventSinkStatic(events)
                }

                override fun onCancel(arguments: Any?) {
                    eventSink = null
                    LocationService.setEventSinkStatic(null)
                }
            })
    }

    private fun startService() {
        val intent = Intent(this, LocationService::class.java)
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O)
            startForegroundService(intent)
        else
            startService(intent)
    }
}

🚀 6. Foreground Location Service (LocationService.kt)

package com.example.background_location

import android.app.*
import android.content.Context
import android.content.Intent
import android.location.Location
import android.os.Build
import android.os.IBinder
import android.os.Looper
import android.util.Log
import androidx.core.app.NotificationCompat
import com.google.android.gms.location.*
import io.flutter.plugin.common.EventChannel

class LocationService : Service() {

    companion object {
        var isRunning = false
        private var staticSink: EventChannel.EventSink? = null

        fun setEventSinkStatic(sink: EventChannel.EventSink?) {
            staticSink = sink
        }
    }

    private lateinit var fusedClient: FusedLocationProviderClient
    private lateinit var locationRequest: LocationRequest
    private var callback: LocationCallback? = null

    override fun onCreate() {
        super.onCreate()
        fusedClient = LocationServices.getFusedLocationProviderClient(this)
        locationRequest = LocationRequest.Builder(
            Priority.PRIORITY_HIGH_ACCURACY, 10_000L
        ).setMinUpdateIntervalMillis(5_000L).build()
        createChannel()
    }

    private fun createChannel() {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            val channel = NotificationChannel(
                "loc_service", "Background Location",
                NotificationManager.IMPORTANCE_LOW
            )
            getSystemService(NotificationManager::class.java).createNotificationChannel(channel)
        }
    }

    private fun startForegroundNotification() {
        val notification = NotificationCompat.Builder(this, "loc_service")
            .setContentTitle("Location Tracking")
            .setContentText("Tracking location in background")
            .setSmallIcon(android.R.drawable.ic_menu_mylocation)
            .build()
        startForeground(1, notification)
    }

    private fun sendUpdate(loc: Location) {
        val map = mapOf(
            "latitude" to loc.latitude,
            "longitude" to loc.longitude,
            "accuracy" to loc.accuracy,
            "timestamp" to System.currentTimeMillis()
        )
        staticSink?.success(map)
        Log.d("LocationService", "📍 $map")
    }

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        startForegroundNotification()
        isRunning = true
        callback = object : LocationCallback() {
            override fun onLocationResult(result: LocationResult) {
                for (loc in result.locations) sendUpdate(loc)
            }
        }
        fusedClient.requestLocationUpdates(locationRequest, callback!!, Looper.getMainLooper())
        return START_STICKY
    }

    override fun onDestroy() {
        super.onDestroy()
        callback?.let { fusedClient.removeLocationUpdates(it) }
        isRunning = false
        staticSink?.endOfStream()
    }

    override fun onBind(intent: Intent?): IBinder? = null
}

🔁 7. Auto Restart After Kill or Reboot

RestartReceiver.kt

package com.example.background_location

import android.content.*
import android.os.Build
import android.util.Log

class RestartReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        Log.d("RestartReceiver", "⏰ Restart alarm triggered")
        val service = Intent(context, LocationService::class.java)
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O)
            context.startForegroundService(service)
        else
            context.startService(service)
    }
}

BootCompletedReceiver.kt

package com.example.background_location

import android.content.*
import android.os.Build
import android.util.Log

class BootCompletedReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == Intent.ACTION_BOOT_COMPLETED) {
            Log.d("BootReceiver", "✅ Device rebooted — starting service")
            val service = Intent(context, LocationService::class.java)
            if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O)
                context.startForegroundService(service)
            else
                context.startService(service)
        }
    }
}

🧩 8. Flutter Side — location_service.dart

import 'dart:async';
import 'package:flutter/services.dart';
import 'package:flutter/foundation.dart';

class LocationService {
  static const _method = MethodChannel('background_location/methods');
  static const _events = EventChannel('background_location/events');

  Stream<Map<String, dynamic>>? _stream;

  Stream<Map<String, dynamic>> get locationStream {
    _stream ??= _events.receiveBroadcastStream().map((e) {
      final map = Map<String, dynamic>.from(e);
      debugPrint('📍 $map');
      return map;
    });
    return _stream!;
  }

  Future<void> start() async {
    await _method.invokeMethod('startService');
  }

  Future<void> stop() async {
    await _method.invokeMethod('stopService');
  }

  Future<bool> isRunning() async {
    return await _method.invokeMethod('checkServiceAlive');
  }
}

Usage Example:

final locationService = LocationService();

await locationService.start();

locationService.locationStream.listen((loc) {
  print("Location: ${loc['latitude']}, ${loc['longitude']}");
});

🧪 9. Testing Checklist

✅ Start service and check logs:

🚀 startLocationService() called
Started location updates
📍 Location update: {latitude: ..., longitude: ...}

✅ Close Flutter app → logs continue

✅ Restart phone → logs show:

✅ Device rebooted — starting service
📍 Location update: ...

✅ Stop manually → no auto restart

📦 11. Full Source Code

👉 https://github.com/ashish8381/custom_location_tracking
(You can upload your final version there.)

✨ 12. Bonus Improvements (optional)

• Store last location in SharedPreferences
• Upload to Firebase in background via WorkManager
• Add iOS support via background_fetch or flutter_background_geolocation

✅ Closing

That’s it! You now have a complete Flutter + Android hybrid background location tracker that works reliably across foreground, background, and reboot.

If you found this useful, share it with your team or star ⭐ the [GitHub repo]!

Tags: flutter, kotlin, android-development, background-services, location-tracking, mobile-development

Tired of switching between terminal logs and emulator screens?
Meet Console Plus, your floating in-app debug console — built for developers, by a developer.

💡 Instantly view, filter, copy, and export logs without leaving your Flutter app.

🎯 Why Console Plus?

Debugging a Flutter app can be frustrating when you have to:

• Keep the emulator and IDE console side by side
• Scroll endlessly to find relevant logs
• Re-run the app to view debug outputs

That’s why I built Console Plus — a lightweight, non-intrusive, floating console overlay that brings your app logs right inside the UI.

⚡ Features

✅ Floating 🪶 Debug Button (draggable)
✅ Real-time Log Updates
✅ Auto-Scroll (smart — only when near bottom)
✅ Filter Logs by Type (Info, Warning, Error)
✅ Keyword Search
✅ Copy / Export Logs (JSON or text)
✅ Adjustable size (resize and drag anywhere)
✅ Works across Android, iOS, and Web
✅ Open-source & developer-friendly

🚀 Installation

Add this line to your pubspec.yaml:

dependencies:
  console_plus: ^1.1.1

Then run:

flutter pub get

🧩 How to Use

1️⃣ Initialize and Show Floating Button

import 'package:console_plus/console_plus.dart';

void main() {
  runApp(const MyApp());
  WidgetsBinding.instance.addPostFrameCallback((_) {
    FloatingDebugButton.show(context);
  });
}

2️⃣ Add Logs

DebugLogConsole.log("App started successfully!");
DebugLogConsole.log("Warning: Missing config file", type: LogType.warning);
DebugLogConsole.log("Error: Invalid API key", type: LogType.error);

3️⃣ Floating Console View

Tap the 🐞 icon on your app, and voilà!
You’ll see a draggable, resizable console window — 
with filters, search bar, and export options.

🧠 Example Output

🟢 INFO → Normal logs
🟡 WARN → Potential issues
🔴 ERROR → Critical problems

[10:45:21.341] [INFO] App started successfully
[10:45:22.892] [WARN] Missing config file
[10:45:23.041] [ERROR] Invalid API key

📦 Export & Copy Logs

Want to share logs with your QA team?
Simply tap 📋 Copy or ⬇️ Export JSON — the console will save your logs as a .json file automatically.

🧰 Under the Hood

Console Plus is built with:

• Flutter’s OverlayEntry for floating UI
• ValueNotifier for efficient log updates
• file_saver for cross-platform file exports
• SelectableText for multi-line text selection
• dropdown_button2 for enhanced filter UI

💻 Code Snippet — Minimal Setup Example

FloatingActionButton(
  onPressed: () {
    FloatingDebugButton.show(context);
  },
  child: const Icon(Icons.bug_report),
);

Once you open the floating panel, all logs you emit via DebugLogConsole.log() will appear instantly.

🖼️ Screenshot Preview :

🧑‍💻 Who Is It For?

• Flutter developers working on complex UIs
• QA testers debugging user-reported issues
• Developers building internal dev tools
• Teams needing in-app debug visibility

🏗️ Roadmap

🔹 Log persistence between sessions
🔹 Collapsible log groups
🔹 Network request tracing
🔹 Remote log streaming

Have a feature idea?
→ Open an issue or PR on GitHub:
github.com/ashish8381/console_plus

📜 License

MIT License © 2025 Ashish
See the full LICENSE file for details.

❤️ Support & Feedback

If you love Console Plus, please:

• ⭐ Star the repo → GitHub Link
• 🗣️ Comment your feedback on pub.dev
• 🔄 Share this article with your Flutter dev friends!

✨ Built with ❤️ by Ashish

“Logs shouldn’t live in the terminal — they should live in your app.”

🧩 Introduction

Flutter is no longer just for hobby projects — it powers production apps used by millions worldwide.
But as your app scales, you’ll quickly run into three challenges: speed, security, and scalability.

In this guide, you’ll learn practical, developer-tested techniques to optimize Flutter apps for 2025 — ensuring your product remains fast, secure, and ready for growth.

⚡ Speed Optimization: Make Your App Feel Native

1. Use Isolates and compute() for Heavy Tasks

Flutter runs UI code on a single thread.
Move CPU-heavy work (like JSON parsing or image processing) to an isolate:

final result = await compute(parseLargeJson, jsonString);

💡 In Flutter 3.24+, isolates have lower memory overhead and faster message passing.

2. Reduce Widget Rebuilds

• Use const constructors wherever possible.
• Use Selector, Consumer, or ValueListenableBuilder to rebuild only what’s needed.

Selector<UserProvider, String>(
  selector: (_, provider) => provider.username,
  builder: (_, username, __) => Text(username),
)

3. Smart Caching = Instant Performance

• Images: cached_network_image
• APIs: dio_cache_interceptor
• Files: flutter_cache_manager

Offline-first apps feel faster and reduce server load.

4. Profile Regularly

Don’t guess. Measure:

• 🧰 Flutter DevTools → Performance tab
• 🔍 flutter run --profile
• 🧹 flutter analyze & dart fix

🔒 Security Optimization: Protect Your Users and APIs

1. Use HTTPS + Certificate Pinning

Add SSL pinning to prevent man-in-the-middle attacks:

final dio = Dio();
(dio.httpClientAdapter as DefaultHttpClientAdapter).onHttpClientCreate = (client) {
  client.badCertificateCallback = (cert, host, port) =>
      cert.pem == myServerCert;
  return client;
};

2. Store Sensitive Data Securely

Use flutter_secure_storage for:

• Access tokens
• API keys
• Session data

Encrypt local databases with sqflite_sqlcipher or Drift.

3. Obfuscate and Shrink Code

Protect your app logic with:

flutter build apk --obfuscate --split-debug-info=build/debug_info/

4. Keep Dependencies Up-to-Date

Outdated packages = security risk.

flutter pub outdated
flutter pub upgrade

Use GitHub Dependabot or Renovate for automated checks.

☁️ Scalability: Build for Growth

1. Modular & Clean Architecture

Structure by features, not screens.

Recommended pattern:

• data/ — API, DB, repositories
• domain/ — use cases
• presentation/ — UI, providers

Use dependency injection via get_it or riverpod for clean scaling.

2. Scalable Backends

For growing apps:

• ☁️ Firebase Functions or Supabase Edge Functions
• 🔗 GraphQL (Hasura/Apollo) for efficient querying
• 🧵 Pub/Sub or RabbitMQ for background processing

3. CI/CD Automation

Continuous delivery = faster updates and safer releases.

GitHub Actions Example:

name: Flutter CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: subosito/flutter-action@v2
      - run: flutter pub get
      - run: flutter test
      - run: flutter build apk --release

4. Monitor Everything

Integrate:

• 🔥 Firebase Crashlytics — crash reports
• 🧠 Sentry — error tracking
• 🧰 Firebase Performance — real user metrics
• 🧾 App Check — prevent abuse and fake traffic

🌟 Bonus: 2025 Flutter Trends to Watch

• 🤖 AI-driven personalization using MLKit and TensorFlow Lite
• ⚡ Flutter Web with WASM rendering for blazing-fast performance
• 🔐 Passkey authentication replacing traditional logins
• 🌍 Edge-deployed APIs for low-latency global access

💡 Final Thoughts

The Flutter ecosystem in 2025 is mature, stable, and production-ready — but only optimized apps survive.
Make your app:

✅ Fast — through isolates, caching, and profiling
✅ Secure — with encryption and obfuscation
✅ Scalable — with clean architecture and CI/CD

“Don’t just build Flutter apps. Build future-proof digital experiences.”

👨‍💻 About the Author

Ashish — Android & Flutter Developer
Helping teams build efficient, secure, and scalable mobile applications.
📱 Follow me for more Flutter, Firebase, and DevOps insights!

#Flutter #MobileDevelopment #AppOptimization #FlutterDev #Performance #Security #Scalability #CleanArchitecture #Firebase #DartLang #MobileAppSecurity #Flutter2025

Starting November 1, 2025, all new apps and updates targeting Android 15 (API level 35) must support 16 KB memory page sizes. If your app is written entirely in Java or Kotlin and doesn’t include native code, you’re already compliant. However, it’s essential to test your app in a 16 KB environment to ensure optimal performance and compatibility.

📌 What Is a 16 KB Memory Page?

A memory page is the smallest unit of data for memory management in an operating system. Traditionally, Android has used 4 KB pages. With Android 15, support for 16 KB pages is introduced, offering potential performance improvements, especially on devices with larger RAM. Android Developers Blog

✅ Who Needs to Migrate?

• Java/Kotlin-Only Apps: If your app uses only Java or Kotlin and doesn’t include native code (C/C++), you’re already compatible with 16 KB page sizes.
• Apps with Native Code: If your app includes native code (e.g., via the Android NDK or third-party SDKs), you’ll need to recompile and align your native libraries to support 16 KB pages. Android Developers

🔧 Steps to Ensure 16 KB Compatibility

1. Update Your Development Environment

• Android Gradle Plugin (AGP): Ensure you’re using AGP 8.5.1 or higher.
• Target SDK Version: Set your targetSdkVersion to 35 or higher in your build.gradle file.
• Android NDK: If your app uses native code, update to NDK r28 or higher, which supports 16 KB alignment by default. Android Developers Blog

2. Check for Native Code Dependencies

Use Android Studio’s APK Analyzer to inspect your APK or AAB:

• Navigate to Build > Analyze APK....
• Open the lib/ folder and check for .so files.
• If present, these are native libraries that may require alignment. Android Developers

3. Recompile Native Libraries for 16 KB Alignment

If your app includes native code:

• Rebuild Native Code: Recompile your native libraries using the updated NDK and ensure they are aligned to 16 KB.
• Update Dependencies: Ensure all third-party SDKs and libraries are compatible with 16 KB page sizes.

4. Remove Hard-Coded PAGE_SIZE Assumptions

Avoid using hard-coded values like 4096 (4 KB) for memory operations. Instead, use system calls to determine the page size:

• Java: int pageSize = sun.misc.VM.getPageSize();
• Kotlin: val pageSize = sun.misc.VM.getPageSize()

This ensures your app dynamically adapts to the system’s page size. Android Developers

5. Test in a 16 KB Environment

To verify your app’s compatibility:

• Use Android Emulator: Set up an emulator with an Android 15 system image that supports 16 KB page sizes.
• On-Device Testing: For real-device testing, use devices like Pixel 8 or 8 Pro running Android 15 QPR1 or higher. Enable the developer option to toggle between 4 KB and 16 KB page sizes. Android Developers Blog

🚀 Why Migrate?

Migrating to support 16 KB page sizes can lead to:

• Improved Performance: Faster app launch times and reduced memory overhead.
• Enhanced Battery Efficiency: Lower power consumption during app startup.
• Better System Responsiveness: Quicker camera launches and improved system boot times. Android Developers Blog

📝 Final Thoughts

While Java and Kotlin-only apps are inherently compatible with 16 KB page sizes, it’s crucial to test your app in a 16 KB environment to ensure optimal performance. For apps with native code, following the steps outlined above will help ensure compliance with Google’s requirements and enhance your app’s performance on supported devices.

Starting November 1, 2025, Google Play mandates that all new apps or updates targeting Android 15 (API level 35) and above must support 16 KB memory page sizes on 64-bit devices. Android Developers Blog+2Android Developers+2

If your Flutter app (or its dependencies) still assumes 4 KB page size, you may run into Play Store rejections, runtime crashes, or alignment issues. In this guide, we’ll walk through:

• What this 16 KB page size change means
• How to check if your app is affected
• Step-by-step migration for a Flutter app
• Testing and verification
• Common pitfalls & tips

🧠 What Is a Memory Page Size & Why It Matters

Operating systems organize memory into “pages” — contiguous blocks the kernel manages. Historically, Android (and many OSes) used 4 KB pages. Starting Android 15, devices may use 16 KB pages for better performance. Ralfiz Technologies+3Android Developers+3Android Developers Blog+3

Benefits of larger page size (per Android docs):

• Lower memory management overhead
• Faster app launch times (improvements vary; in some cases up to 30%) Android Developers+1
• Reduced heap fragmentation
• More efficient battery / power behavior during startup Android Developers Blog+1

However, if your app includes native libraries (.so files) or uses NDK-based code or native plugins, those must be built/packaged to be 16 KB-aligned, otherwise your app may fail to install or run properly on such devices. Ralfiz Technologies+4Android Developers+4Android Developers Blog+4

If your app is pure Dart/Kotlin/Java without any native binaries, you may already be okay — but you still should test. Android Developers+2Android Developers Blog+2

🕵 How to Check If Your App Is Affected

1. Use the Play Console / App Bundle Explorer

In Google Play Console, check your app bundle’s “Memory page size” or compatibility warnings. It may flag missing 16 KB alignment. DEV Community+1

2. Use Android Studio’s APK Analyzer

• Build your .aab or .apk
• Use Build > Analyze APK
• In the lib/ folder, see if .so files exist
• Check “Alignment” column — Android Studio will warn if native libraries aren’t aligned for 16 KB pages Ralfiz Technologies+3Android Developers+3Android Developers Blog+3

3. Use command-line tools / scripts

Android’s docs provide check_elf_alignment.sh to validate ELF segments alignment. Android Developers+2Android Developers Blog+2

Also, use:

adb shell getconf PAGE_SIZE

on a device/emulator to see current page size (should return 16384 if 16 KB mode is enabled). Android Developers+2Android Developers Blog+2

🔧 Migration Steps for a Flutter App

Here’s your checklist and step-by-step migration:

1. Upgrade Flutter & Toolchain Versions

• Use a recent Flutter version that includes 16 KB support in the engine
• Update Android Gradle Plugin (AGP) to 8.5.1 or higher DEV Community+3Android Developers+3Android Developers Blog+3
• Use Gradle wrapper version 8.5+ (or compatible)
• Use Android NDK r28 or above (NDK r28+ builds native libs aligned by default) Ralfiz Technologies+4Android Developers+4Android Developers Blog+4

In android/gradle/wrapper/gradle-wrapper.properties:

distributionUrl = https\://services.gradle.org/distributions/gradle-8.13-all.zip

In android/app/build.gradle (or build.gradle.kts), ensure:

plugins {
    id 'com.android.application' version '8.12.2' apply false
    // etc.
}
android {
    ndkVersion "29.0.13113456"  // or a suitable r28+ variant
}

2. Ensure Native Libraries Are 16 KB Aligned

• If you have custom native / C++ / JNI code, rebuild with linker flags for 16 KB alignment
• If you use plugins that ship .so files, upgrade those plugins to versions that support 16 KB alignment

In Android NDK r28+ this alignment is handled automatically. Medium+4Android Developers+4Android Developers Blog+4

If using older NDK or legacy libraries, you may need:

-Wl,-z,max-page-size=16384

or related flags (see Android docs) Android Developers+1

If your app has .so libraries that are uncompressed in the APK, ensure packaging doesn’t compress them (so zip alignment can be maintained). Android Developers+2Android Developers Blog+2

In Gradle:

android {
  packagingOptions {
    jniLibs {
      useLegacyPackaging true
    }
  }
}

(But using legacy packaging is a fallback — ideally move to a toolchain that automatically aligns) Android Developers+2Android Developers Blog+2

3. Remove Hard-Coded Assumptions About Page Size

Search your native / C / C++ / JNI code for any assumptions or constants using 4096 (the 4 KB page size). Replace with dynamic queries like getpagesize() or sysconf(_SC_PAGESIZE). Android Developers+1

Avoid passing page-size–based constants to mmap() or other memory APIs without verifying alignment. Android Developers+1

4. Clean, Rebuild & Repackage

• ./gradlew clean
• Rebuild release AAB / APK
• Use flutter build appbundle --analyze-size to inspect the result

5. Verify Alignment & Testing

• Run check_elf_alignment.sh (or similar) on your output AAB or APK
• Use zipalign:

zipalign -v -c -P 16 -4 path/to/app.apk

• to verify proper 16 KB alignment. Android Developers+2Android Developers Blog+2
• Test on an emulator configured for Android 15 with 16 KB system image
• Test on physical devices that support toggling 16 KB mode (e.g. some Pixel devices)
• Use:

adb shell getconf PAGE_SIZE

• to confirm the device is running 16 KB mode. Android Developers Blog+1

⚠️ Common Pitfalls & Tips

• Plugin binaries not updated — many 3rd-party Flutter plugins may still use 4 KB builds. You might need to wait for plugin maintainers or fork + update them. Medium+4Medium+4DEV Community+4
• Huawei / OEM SDKs — some vendor SDKs (e.g. Huawei Location) may not support 16 KB yet. Medium+2DEV Community+2
• Back-compat mode — Android supports “page size compat mode” to allow older 4 KB-libraries to run temporarily, but you should not rely on that for production stability. Android Developers+1
• Delayed warnings — alignment issues may only appear when publishing to Play or on certain devices, so you’ll catch surprises late unless you test early
• Binary size changes — aligning native libs to 16 KB may slightly increase APK/AAB size
• Testing coverage — carefully test features that use native code (camera, ML, platform channels) to catch runtime misbehavior

🏁 Conclusion & Call to Action

Migrating to 16 KB page size may seem daunting, especially if your app depends on native plugins. But with the right toolchain version, careful alignment, and testing, it’s entirely manageable.

To recap:

1. Upgrade your Flutter, AGP, Gradle, and NDK
2. Rebuild native libraries with 16 KB alignment
3. Fix code that assumes 4 KB page size
4. Test thoroughly on 16 KB devices / emulators
5. Monitor warnings in Play Console and APK Analyzer

Don’t wait until the deadline — some plugin ecosystems may lag behind. Start auditing your dependencies today so you avoid last-minute surprises.

📎 Further Reading / References

• Android Developers: Support 16 KB page sizes Android Developers
• Android Developers Blog: Prepare your apps for Google Play’s 16 KB requirement Android Developers Blog
• Android Studio & tooling for transition to 16 KB Android Developers Blog
• Community posts about Flutter and 16 KB migration Medium+3DEV Community+3Medium+3