Debug School: Abhishek singh

Traccar Integration — Complete Guide

Abhishek singh — Tue, 02 Jun 2026 12:03:11 +0000

Traccar Integration — Complete Guide

What is Traccar & Why It's Here Traccar is an open-source GPS tracking server. In Motoshare, it is used to:

Register each vehicle's GPS device (identified by its IMEI number)
Track live vehicle position (latitude, longitude, speed, etc.)
Let partners open a live tracking map in the browser

Architecture

Mobile/Web App
│
▼
Laravel API (motoshare-web)
│
├── TraccarService ──► Traccar Server HTTP API (port 8082)
│ /api/users
│ /api/devices
│ /api/positions
│ /api/session
│ /api/session/token
│
├── addvechicles table (stores imei + traccar_device_id)
└── users table (stores traccar_password)
Two key database columns added by migrations:

Table Column Purpose
addvechicles traccar_device_id Cached Traccar internal device ID (skips IMEI lookup on every position call)
users traccar_password Stored Traccar password for generating per-user JWT tokens

Configuration (.env Variables) Add these to your .env file:

Traccar server URL — the backend API (Laravel calls this internally)

TRACCAR_API_URL=http://localhost:8082

Traccar admin credentials (must be a Traccar admin account)

TRACCAR_API_ADMIN_EMAIL=admin@example.com
TRACCAR_API_ADMIN_PASSWORD=your_admin_password

Traccar web UI URL (browser-facing, for the map redirect)

TRACCAR_WEB_URL=http://localhost:8082

HTTP timeout in seconds

TRACCAR_API_TIMEOUT=10

Set false on local dev if Traccar has a self-signed SSL cert

TRACCAR_VERIFY_SSL=true

Master switch — set true to enable the integration

TRACCAR_ENABLED=true
Important: TRACCAR_API_URL and TRACCAR_WEB_URL can be different. API URL is what Laravel connects to (may be internal network). Web URL is what the browser opens (must be publicly reachable).

All API Endpoints 4.1 Get Traccar JWT Token

GET /api/traccar/token
Auth: Sanctum token required
What it does: Generates a JWT for the logged-in user so the frontend can open the Traccar map UI.

Response:

{ "traccar_token": "eyJhbGciOi..." }
Usage (frontend):

// Open Traccar map for logged-in user
const res = await axios.get('/api/traccar/token');
window.open(${TRACCAR_WEB_URL}?token=${res.data.traccar_token});
4.2 Get Live Vehicle Position

GET /api/vehicles/{vehicleId}/position
Auth: Sanctum token required
What it does: Returns the latest GPS position for a vehicle by its Motoshare vehicle ID.

Response:

{
"vehicle_id": 42,
"imei": "123456789012345",
"latitude": 12.9716,
"longitude": 77.5946,
"speed": 0.0,
"course": 180.0,
"accuracy": 5.2,
"altitude": 920.0,
"device_time": "2026-06-02T10:30:00.000+0000",
"fix_time": "2026-06-02T10:29:58.000+0000",
"attributes": { "ignition": true, "motion": false }
}
Error responses:

{ "error": "Vehicle not found or no GPS device" } // 404 — vehicle missing or no IMEI set
{ "error": "No position data available" } // 404 — device registered but no GPS fix yet
{ "error": "Internal server error" } // 500
4.3 Get Live Position by Booking

GET /api/bookings/{bookingId}/position
Auth: Sanctum token required
What it does: Same as above but looks up the vehicle through a booking ID — useful for riders tracking their rented vehicle.

Response: Same fields as 4.2 plus:

{ "booking_id": 99, "vehicle_id": 42, ... }
4.4 Open Tracker in Browser (Web Route)

GET /tracker/launch
Auth: Keycloak session (kc_auto middleware)
What it does: Generates a Traccar JWT for the logged-in user, then serves a bridge page (traccar_bridge.blade.php) that:

Deletes any existing Traccar browser session (so the JWT always wins)
Redirects to TRACCAR_WEB_URL?token=
How to trigger from sidebar/menu:

Open Tracker

How the Service Works — Internal Flows 5.1 Registering a Vehicle's GPS Device Triggered when: A vehicle is added/updated with an IMEI number via saveTraccarDevice().

uploadvechiclecontroller::update_vehiclestab()
│
└─► UtilityFunctionsController::saveTraccarDevice($request, $email, $vehicleId)
│
└─► TraccarService::saveDevice($request, $email, $vehicleId)
│
├─ getUserByEmail($email) → find/create Traccar user account
├─ syncDevice($request, ...) → create or update Traccar device
├─ linkDeviceToUser(...) → link device to user in Traccar
└─ update addvechicles.traccar_device_id ← cached for fast lookups
Request fields needed: imei, brand, vehicleType, model

5.2 Getting Position (Fast Path)
Once traccar_device_id is cached on the vehicle:

GET /api/vehicles/{id}/position
│
└─► resolveVehiclePosition($vehicle)
│
├─ IF traccar_device_id set → getLatestPositionByDeviceId(id) [1 HTTP call]
└─ IF only imei set → getDeviceByUniqueId(imei) [2 HTTP calls]
→ getLatestPositionByDeviceId(id)
Always register devices via saveTraccarDevice — it sets traccar_device_id and halves position lookup cost.

5.3 JWT Token Generation for Map Access

ensureUserToken($email)
│
├─ resolveTraccarPassword($email, $laravelUser)
│ ├─ IF traccar_password stored in users table → return it [0 HTTP calls]
│ ├─ IF Traccar account exists but no stored password → provisionTraccarPassword()
│ └─ IF no Traccar account → createUser() + store password
│
├─ getSessionJwt($email, $password)
│ ├─ POST /api/session (creates session cookie)
│ └─ POST /api/session/token (exchanges cookie for JWT)
│
├─ IF JWT fails (stale password) → retryWithFreshPassword() → getSessionJwt()
└─ IF all fails → adminSessionJwt() (admin fallback)

TraccarService Public Methods Reference Method Description Called From saveDevice($request, $email, $vehicleId) Register/update a GPS device for a vehicle saveTraccarDevice() wrappers ensureUserToken($email) Get a Traccar JWT for a user getTraccarToken, /tracker/launch getUserByEmail($email) Fetch Traccar user by email Internal createUser($name, $email, $password) Create a new Traccar user account Internal getDeviceByUniqueId($imei) Fetch Traccar device by IMEI Internal createDevice($name, $imei, ...) Register a new GPS device Internal updateDevice($deviceId, ...) Update an existing GPS device Internal linkDeviceToUser($userId, $deviceId) Give user permission to see device Internal getLatestPosition($imei) Get last GPS position by IMEI resolveVehiclePosition getLatestPositionByDeviceId($id) Get last GPS position by device ID (fast) resolveVehiclePosition
Database Migrations Two migrations were added:

add_traccar_device_id_to_addvechicles_table

ALTER TABLE addvechicles ADD COLUMN traccar_device_id INT NULL;
add_traccar_password_to_users_table

ALTER TABLE users ADD COLUMN traccar_password VARCHAR(255) NULL;
Run with: php artisan migrate

How to Add GPS Tracking to a Vehicle (Step by Step) Step 1 — Vehicle must have an IMEI field set When adding/editing a vehicle, pass imei in the request body.

Step 2 — saveTraccarDevice is called automatically
uploadvechiclecontroller.php:1662 calls $this->utilityController->saveTraccarDevice($request, $useremail, $vehicleId) after vehicle save.

Step 3 — Verify registration worked
Check addvechicles table: traccar_device_id should be non-null for that vehicle.

Step 4 — Poll position from frontend

// Every 10 seconds
setInterval(async () => {
const res = await axios.get(/api/vehicles/${vehicleId}/position);
map.setCenter({ lat: res.data.latitude, lng: res.data.longitude });
}, 10000);

Common Issues & Fixes Symptom Cause Fix No position data available (404) Device registered but GPS hasn't sent data yet Wait for GPS hardware to get a satellite fix and transmit Vehicle not found or no GPS device (404) imei column is null/empty in DB Set IMEI when adding/editing the vehicle JWT works once, then fails Traccar session expired ensureUserToken auto-retries with a fresh password; if still failing check users.traccar_password column traccar_device_id is null saveTraccarDevice was never called or IMEI was blank Re-save the vehicle with a valid IMEI Admin fallback used constantly Traccar user accounts not provisioning Check logs for provisionTraccarPassword - PUT failed; verify admin credentials in .env SSL errors on local dev Self-signed cert Set TRACCAR_VERIFY_SSL=false in .env Traccar returns all users instead of filtered Admin token bypasses ?email= filter This is expected — the service filters client-side, works correctly /tracker/launch shows blank TRACCAR_WEB_URL not set Add TRACCAR_WEB_URL to .env and run php artisan config:clear
Quick Checklist for a Fresh Setup

☐ Traccar server running and accessible from Laravel server
☐ TRACCAR_API_URL set (internal network URL)
☐ TRACCAR_WEB_URL set (browser-accessible URL)
☐ TRACCAR_API_ADMIN_EMAIL + TRACCAR_API_ADMIN_PASSWORD set
☐ TRACCAR_ENABLED=true
☐ php artisan migrate (adds traccar_device_id + traccar_password columns)
☐ php artisan config:clear
☐ Add a vehicle with a valid IMEI → verify traccar_device_id populates in DB
☐ Call GET /api/traccar/token → verify JWT returned
☐ Call GET /api/vehicles/{id}/position → verify coordinates returned

End-to-End Flow: Motoshare App to Traccar Tracking

Abhishek singh — Tue, 19 May 2026 11:27:26 +0000

Below is the complete end-to-end flow for adding one Track Vehicle button in the Motoshare Flutter app and opening Traccar tracking with Motoshare authentication.

End-to-End Flow: Motoshare App to Traccar Tracking

1. Main Requirement

In the Motoshare Flutter app, add one button:

Track Vehicle

When user clicks this button:

Motoshare Flutter App
        ↓
Track Vehicle Button
        ↓
Open Traccar Manager App / gps.motoshare.in
        ↓
Motoshare OAuth / OpenID Authentication
        ↓
Traccar Dashboard Opens
        ↓
User tracks allowed vehicles

2. Final Architecture

Flutter App
        ↓
Laravel Backend
        ↓
Traccar Server
        ↓
gps.motoshare.in
        ↓
Traccar Manager App / Web Dashboard

Simple meaning:

Flutter App = Button and user action
Laravel = Authentication and Traccar device/user mapping
Traccar = GPS tracking system
Physical GPS Tracker = Sends vehicle location

3. Vehicle Registration Flow

When vehicle is added in Motoshare:

User adds vehicle in Motoshare app
        ↓
User enters vehicle details + GPS IMEI
        ↓
Flutter sends data to Laravel backend
        ↓
Laravel saves vehicle in Motoshare database
        ↓
Laravel creates device in Traccar using Traccar API
        ↓
Laravel saves Traccar Device ID in vehicle table

Example vehicle data:

Vehicle Name: Honda Activa
Vehicle Number: JH05 AB 1234
GPS IMEI: 864895060123456

In Traccar, device should be created like:

Device Name: Honda Activa - JH05 AB 1234
Unique ID: 864895060123456

Important:

Unique ID = GPS tracker IMEI

4. Physical GPS Tracker Flow

Live tracking will work only when physical GPS tracker sends data to Traccar.

Physical GPS tracker installed in vehicle
        ↓
SIM card inserted in GPS tracker
        ↓
Tracker configured with APN + gps.motoshare.in + correct port
        ↓
Tracker sends live location to gps.motoshare.in
        ↓
Vehicle becomes online in Traccar

Example tracker setting:

Server: gps.motoshare.in
Port: 5023 or correct device protocol port
APN: airtelgprs.com / jionet / www

Important:

8082 = Traccar web/API port
5023 or other protocol port = GPS tracker data port

5. Track Vehicle Button Flow in Flutter

Simple Button Flow

User opens Motoshare Flutter app
        ↓
Clicks Track Vehicle
        ↓
App opens Traccar Manager App or gps.motoshare.in
        ↓
Traccar checks login session
        ↓
If user is already authenticated, dashboard opens
        ↓
If user is not authenticated, Motoshare login opens
        ↓
After login, user returns to Traccar dashboard

6. Authentication Flow

Your desired authentication flow:

Traccar Login
        ↓
Motoshare OAuth / OpenID Authentication
        ↓
Traccar Dashboard

Yes, it can automatically authenticate and go to dashboard if SSO/OpenID is configured properly.

Case 1: User already has active Motoshare session

Click Track Vehicle
        ↓
Open gps.motoshare.in / Traccar Manager
        ↓
Motoshare session found
        ↓
Auto authentication
        ↓
Traccar dashboard opens

Case 2: User does not have active Motoshare session

Click Track Vehicle
        ↓
Open gps.motoshare.in / Traccar Manager
        ↓
Redirect to Motoshare login
        ↓
User enters login details
        ↓
Redirect back to Traccar
        ↓
Dashboard opens

So first-time login may be required. After login/session is saved, it can open dashboard directly next time.

7. Required Traccar OpenID Configuration

Your Traccar config should have Motoshare OAuth/OpenID enabled.

Example:

<entry key='web.url'>https://gps.motoshare.in</entry>
<entry key='web.port'>8082</entry>

<entry key='openid.force'>true</entry>
<entry key='openid.issuerUrl'>https://motoshare.in</entry>
<entry key='openid.authUrl'>https://motoshare.in/oauth/authorize</entry>
<entry key='openid.tokenUrl'>https://motoshare.in/oauth/token</entry>
<entry key='openid.userInfoUrl'>https://motoshare.in/api/user</entry>

This means:

Traccar login will use Motoshare authentication.

8. Required Redirect URLs

In Laravel OAuth/OpenID client settings, allow these callback URLs:

https://gps.motoshare.in/api/session/openid/callback

For Traccar Manager mobile app, also allow:

org.traccar.manager:/api/session/openid/callback

These are required so login can return back to Traccar after Motoshare authentication.

9. Flutter App Button Options

Option A: Easiest and Most Reliable

Open web dashboard:

https://gps.motoshare.in

Flow:

Track Vehicle Button
        ↓
Open https://gps.motoshare.in
        ↓
Motoshare SSO login
        ↓
Traccar dashboard opens

This is simplest and needs minimum coding.

Option B: Open Traccar Manager App

Flow:

Track Vehicle Button
        ↓
Open Traccar Manager App
        ↓
Server URL: https://gps.motoshare.in
        ↓
Motoshare SSO login
        ↓
Traccar dashboard opens

Important:

First time, user may need to set server URL in Traccar Manager:

https://gps.motoshare.in

10. Flutter Button Code: Simple Web Dashboard

Use this for fastest implementation:

import 'package:url_launcher/url_launcher.dart';

Future<void> openGpsTracking() async {
  final Uri url = Uri.parse('https://gps.motoshare.in');

  await launchUrl(
    url,
    mode: LaunchMode.externalApplication,
  );
}

Button:

ElevatedButton(
  onPressed: openGpsTracking,
  child: const Text('Track Vehicle'),
)

11. Flutter Button Code: Open Traccar Manager App

Android package:

org.traccar.manager

Flutter dependencies:

dependencies:
  url_launcher: ^6.3.0
  android_intent_plus: ^5.0.2

Code:

import 'package:android_intent_plus/android_intent.dart';
import 'package:url_launcher/url_launcher.dart';

Future<void> openTraccarManager() async {
  const String packageName = 'org.traccar.manager';

  try {
    final intent = AndroidIntent(
      action: 'android.intent.action.MAIN',
      package: packageName,
      category: 'android.intent.category.LAUNCHER',
    );

    await intent.launch();
  } catch (e) {
    final Uri playStoreUrl = Uri.parse(
      'https://play.google.com/store/apps/details?id=$packageName',
    );

    await launchUrl(
      playStoreUrl,
      mode: LaunchMode.externalApplication,
    );
  }
}

Button:

ElevatedButton(
  onPressed: openTraccarManager,
  child: const Text('Track Vehicle'),
)

12. Laravel Backend Responsibilities

Laravel should handle:

1. Vehicle save
2. GPS IMEI save
3. Traccar device creation
4. Traccar Device ID save
5. User mapping with Traccar
6. Device permission assignment

Vehicle table should store:

gps_imei
traccar_device_id
gps_enabled
gps_status

13. Permission Flow

Authentication only logs the user into Traccar.

Vehicle visibility depends on Traccar permissions.

Recommended:

Admin:
Can see all vehicles.

Partner:
Can see only own vehicles.

Renter:
Can see vehicle only during active booking, if required later.

Example:

Partner adds vehicle
        ↓
Laravel creates device in Traccar
        ↓
Laravel maps partner user in Traccar
        ↓
Laravel assigns device to partner user
        ↓
Partner opens Traccar Manager
        ↓
Partner sees only assigned vehicle

14. Complete Final Flow

1. Physical GPS tracker is installed in vehicle.

2. SIM card is inserted in GPS tracker.

3. GPS tracker is configured with:
   - APN
   - gps.motoshare.in
   - correct GPS protocol port

4. Vehicle is added in Motoshare Flutter app with GPS IMEI.

5. Flutter sends vehicle details to Laravel backend.

6. Laravel saves vehicle in Motoshare database.

7. Laravel creates device in Traccar using IMEI as Unique ID.

8. Laravel stores Traccar Device ID.

9. Laravel assigns vehicle/device permission to correct user.

10. User clicks Track Vehicle button in Flutter app.

11. App opens Traccar Manager App or https://gps.motoshare.in.

12. Traccar redirects to Motoshare OAuth/OpenID login.

13. If user session exists, authentication happens automatically.
    If not, user logs in once.

14. After successful login, user is redirected to Traccar dashboard.

15. User sees only allowed vehicles.

16. Live location appears because physical GPS tracker is sending data to gps.motoshare.in.

15. Final Simple Summary

Motoshare Flutter App:
Add Track Vehicle button.

Button Action:
Open Traccar Manager App or https://gps.motoshare.in.

Authentication:
Traccar uses Motoshare OAuth/OpenID.

Backend:
Laravel creates Traccar device and assigns user permission.

Tracking:
Physical GPS tracker sends live location to gps.motoshare.in.

Result:
User clicks Track Vehicle → auto/login with Motoshare → Traccar dashboard opens → vehicle tracking visible.

GPS Tracking Integration Report for Motoshare

Abhishek singh — Tue, 19 May 2026 11:02:40 +0000

GPS Tracking Integration Report for Motoshare.in

Project

Motoshare.in Vehicle GPS Tracking Setup

Tracking Server

Traccar Server: gps.motoshare.in

1. Current Understanding

We have already developed a vehicle management system for Motoshare.in.

Current completed flow:

Motoshare Vehicle Add Form
        ↓
Vehicle Details + GPS IMEI
        ↓
Create Device in gps.motoshare.in through Traccar API
        ↓
Vehicle appears in Traccar dashboard
        ↓
Tracking should happen directly on gps.motoshare.in

The main requirement is:

When a vehicle is added in Motoshare.in with a GPS tracker IMEI number, that device should be created in Traccar, and all vehicles should be tracked directly on the Traccar map at gps.motoshare.in.

Currently, we do not need to integrate the live tracking map inside motoshare.in.

2. Important Clarification

Adding the IMEI number in Traccar only creates a device record.

It does not automatically start live tracking.

For live tracking, one GPS source must send location data to Traccar.

There are two options:

Option 1: Traccar Client Mobile App

Yes, possible, but please understand clearly:

Option 1: Traccar Client Mobile App

This tracks the mobile phone location, not the physical vehicle tracker.

Flow:

Mobile Phone + Traccar Client App
        ↓
Phone GPS location
        ↓
gps.motoshare.in
        ↓
Shows as one device in Traccar map

Use this when you want to track:

Driver phone
Renter phone
Staff phone
Temporary testing

Physical GPS Tracker Device

This tracks the actual vehicle location.

Flow:

Physical GPS Tracker installed in vehicle
        ↓
SIM card inside tracker
        ↓
gps.motoshare.in
        ↓
Shows vehicle location in Traccar map

Use this when you want to track:

Bike
Car
Rental vehicle
Fleet vehicle

Can both be used together?

Yes, both can be used together, but they should be added as separate devices in Traccar.

Example:

Device 1:
Name: Honda Activa - Vehicle Tracker
Unique ID: 864895060123456
Source: Physical GPS tracker IMEI

Device 2:
Name: Driver Phone - Rakesh
Unique ID: 7709488616-driver
Source: Traccar Client mobile app

Important

Do not use the same Unique ID for both mobile app and physical tracker.

Each device must have a different Unique ID.

Simple Answer

Traccar Client App = tracks mobile phone
Physical GPS Tracker = tracks vehicle

For Motoshare vehicle tracking, physical GPS tracker is best.
For testing or driver/renter tracking, Traccar Client app can be used.

So if your goal is track vehicle, then use physical GPS tracker device.

If your goal is test gps.motoshare.in quickly, then use Traccar Client App.

Option 2: Physical GPS Tracker Device

Option 2: Physical GPS Tracker Device

Since we do not want to use the Traccar Client mobile app, we need to use a physical GPS tracker device installed in each vehicle.

3. Final Required Flow Without Traccar Client App

Physical GPS Tracker installed in vehicle
        ↓
SIM card inserted inside GPS tracker
        ↓
GPS tracker configured with server + port + APN
        ↓
GPS tracker sends location data to gps.motoshare.in
        ↓
Traccar receives GPS data
        ↓
Vehicle becomes online in Traccar dashboard
        ↓
Admin tracks all vehicles on gps.motoshare.in map

4. What is Required for Each Vehicle?

For each vehicle, we need:

1. Physical GPS tracker device
2. SIM card with active internet
3. GPS tracker IMEI number
4. Correct GPS tracker password
5. Correct SMS command format
6. Correct Traccar protocol port
7. Device added in Traccar using IMEI as Unique ID
8. Device configured to send data to gps.motoshare.in

5. Example Setup

Example vehicle:

Vehicle Name: Honda Activa
Vehicle Number: JH05 AB 1234
GPS Tracker IMEI: 864895060123456
GPS Tracker SIM Number: 85485125324
Traccar Server: gps.motoshare.in
GPS Port: 5023
SIM Provider: Airtel

In Traccar, add:

Device Name: Honda Activa - JH05 AB 1234
Unique ID: 864895060123456

Important:

Unique ID = GPS tracker IMEI number

The SIM number and IMEI number are different.

SIM Number = number where SMS commands are sent
IMEI Number = unique GPS device ID added in Traccar

6. SMS Command Explanation

GPS devices are configured by sending SMS commands to the SIM number inside the GPS tracker.

These commands are sent from our mobile phone to the GPS tracker SIM.

Example GPS tracker SIM number:

85485125324

Command 1: APN Setting

Template:

apn<PASSWORD> <SIM_APN>

Example for Airtel:

apn123456 airtelgprs.com

Meaning:

GPS device, use Airtel internet.

Breakdown:

apn = internet setting command
123456 = GPS tracker password
airtelgprs.com = Airtel APN

For Jio:

apn123456 jionet

For Vi:

apn123456 www

Command 2: Server/IP Setting

Template:

adminip<PASSWORD> <SERVER_DOMAIN> <PORT>

Example:

adminip123456 gps.motoshare.in 5023

Meaning:

GPS device, send location data to gps.motoshare.in on port 5023.

Breakdown:

adminip = server/IP setting command
123456 = GPS tracker password
gps.motoshare.in = Traccar server
5023 = GPS tracker protocol port

Final target:

gps.motoshare.in:5023

Command 3: Upload Interval Setting

Template:

upload<PASSWORD> <SECONDS>

Example:

upload123456 30

Meaning:

GPS device, send location every 30 seconds.

Breakdown:

upload = location sending interval command
123456 = GPS tracker password
30 = every 30 seconds

7. Complete Example SMS Flow

If SIM is Airtel and password is 123456, send these SMS messages one by one to the GPS tracker SIM number:

apn123456 airtelgprs.com

adminip123456 gps.motoshare.in 5023

upload123456 30

Simple meaning:

1. Use Airtel internet.
2. Send GPS location to gps.motoshare.in on port 5023.
3. Send location every 30 seconds.

8. Important: Commands Can Be Different

The above commands are common examples.

But every GPS tracker brand/model can have a different SMS command format.

Some trackers use this format:

APN,airtelgprs.com#
SERVER,gps.motoshare.in,5023#
TIMER,30#

Some use:

adminip123456 gps.motoshare.in 5023

Some devices may use:

SERVER,gps.motoshare.in,5023

So the exact command must be confirmed from the GPS tracker manual or seller.

9. About Onelap GPS Tracker

We are using Onelap device.

Important limitation:

Onelap devices may be locked to Onelap’s own platform by default.

So before using Onelap device with gps.motoshare.in, we must confirm whether Onelap allows a custom server configuration.

We need to ask Onelap support:

I want to connect my Onelap GPS tracker with my own Traccar server.

Server: gps.motoshare.in

Please provide:
1. SMS command password
2. APN SMS command format
3. Server/IP/domain and port SMS command format
4. Upload interval SMS command format
5. Device protocol name
6. Correct Traccar-compatible port
7. Confirmation whether this device supports custom server or not

If Onelap does not allow custom server configuration, then the device cannot directly send GPS data to gps.motoshare.in.

10. Where to Find GPS Tracker Password?

GPS tracker password is the password of the physical GPS device.

It is not:

Traccar password
Server password
Motoshare login password

It is used inside SMS commands.

Example:

adminip123456 gps.motoshare.in 5023

Here:

123456 = GPS tracker password

Where to get it:

1. GPS tracker manual
2. Device sticker or box
3. GPS tracker seller
4. Onelap support

Common default passwords:

Most trackers commonly use:

But for Onelap, we should confirm from Onelap support.

11. What is Port 8082?

Our Traccar config currently shows:

<entry key='web.port'>8082</entry>

This means:

8082 = Traccar web dashboard/API port

It is used to open:

https://gps.motoshare.in

But physical GPS trackers usually do not send GPS data to port 8082.

For GPS tracker data, we need a protocol port, for example:

The correct port depends on the GPS tracker model/protocol.

So this is wrong for most physical trackers:

SERVER,gps.motoshare.in,8082

Correct format should be:

SERVER,gps.motoshare.in,<GPS_PROTOCOL_PORT>

Example:

SERVER,gps.motoshare.in,5023

12. How to Find Active Traccar Ports on Server?

Run this command on the server:

sudo ss -tulnp | grep java

or:

sudo netstat -tulnp | grep java

This will show which ports Traccar is listening on.

Example output:

0.0.0.0:8082
0.0.0.0:5023
0.0.0.0:5055
0.0.0.0:5027

Meaning:

8082 = Web/API port
5023 = GPS protocol port
5055 = OsmAnd / Traccar Client type port
5027 = Teltonika type port

13. Firewall Requirement

If the GPS tracker uses port 5023, then this port must be open on the server.

Run:

sudo ufw allow 5023/tcp
sudo ufw allow 5023/udp
sudo ufw reload

If the server is hosted on AWS/Cloud, also open the same port in:

Security Group / Firewall Inbound Rules

Example:

Custom TCP: 5023 from 0.0.0.0/0
Custom UDP: 5023 from 0.0.0.0/0

14. How to Check Whether Device Is Connecting?

Check Traccar logs:

sudo tail -f /opt/traccar/logs/tracker-server.log

Then power on the GPS device or send the server command again.

If the device connects, logs should show device activity.

Also check Traccar dashboard:

https://gps.motoshare.in

Expected result:

Device status: Online
Last update time: Current
Latitude/Longitude: Visible
Vehicle marker: Visible on map

15. Limitations

1. IMEI registration alone is not enough

Adding IMEI in Traccar only creates the device.

It will not show live tracking unless the physical GPS tracker sends location data.

2. Correct port is mandatory

If the wrong port is configured, the device will not connect.

Example:

8082 is web/API port, not GPS data port.

The GPS tracker needs the correct protocol port.

3. GPS tracker model dependency

Every GPS tracker has different:

SMS command format
Default password
Protocol
Port
Server setting method

So we must know the exact device model.

4. Onelap may be locked

Onelap device may be locked to Onelap’s own server/app.

If custom server is not supported, we cannot directly connect it to Traccar.

Possible options then:

1. Use Onelap dashboard/app
2. Ask Onelap for API access
3. Use a Traccar-compatible GPS tracker

5. SIM internet is required

The SIM inside the GPS tracker must have:

Active internet data
SMS service
Correct APN
Network coverage

Without SIM internet, the tracker cannot send live location.

6. Server firewall must allow GPS port

Even if the GPS tracker is configured correctly, it will not connect if the port is blocked.

7. IMEI must match

The IMEI added in Traccar must exactly match the real GPS tracker IMEI.

If IMEI is wrong, Traccar may receive data but not match it with the device.

8. GPS signal required

If the device is indoors, underground, or has poor satellite signal, the location may not update properly.

16. Final Implementation Checklist

Motoshare Side

1. Add GPS IMEI field in vehicle form.
2. Save GPS IMEI in Motoshare database.
3. Call Traccar API to create device.
4. Save Traccar device ID in Motoshare database.
5. Prevent duplicate IMEI.

Traccar Side

1. Device should be created with IMEI as Unique ID.
2. Correct GPS protocol port should be active.
3. Required port should be open in firewall/security group.
4. Logs should be monitored for GPS connection.

GPS Device Side

1. Insert active SIM card.
2. Configure APN.
3. Configure server: gps.motoshare.in.
4. Configure correct port.
5. Configure upload interval.
6. Power on device.
7. Verify device online in Traccar.

17. Final Summary

We have already completed the basic integration where vehicles added in Motoshare.in can be registered as GPS devices in Traccar using their GPS IMEI number.

However, live tracking does not start only by saving the IMEI. For live tracking, each vehicle must have a physical GPS tracker device installed with an active SIM card. The tracker must be configured to send location data to our Traccar server gps.motoshare.in using the correct GPS protocol port.

The Traccar web/API port is 8082, but this is not normally used for physical GPS device data. We need the correct tracker protocol port based on the GPS device model.

Since we are using an Onelap GPS tracker, the main dependency is confirmation from Onelap whether the device supports a custom server. If Onelap allows custom server configuration, they must provide the SMS command format, password, APN command, server/IP command, upload interval command, and correct Traccar-compatible port.

If Onelap does not allow custom server configuration, the device cannot directly connect to gps.motoshare.in. In that case, we need either Onelap API integration or a Traccar-compatible physical GPS tracker.

Final production flow:

Motoshare.in
        ↓
Add vehicle with GPS IMEI
        ↓
Create device in gps.motoshare.in
        ↓
Install physical GPS tracker in vehicle
        ↓
Configure tracker with SIM APN + gps.motoshare.in + correct port
        ↓
Tracker sends live location to Traccar
        ↓
Admin tracks all vehicles on gps.motoshare.in

Google Sign-In on Play Store — Troubleshooting Guide

Abhishek singh — Thu, 07 May 2026 07:31:43 +0000

Google Sign-In on Play Store — Troubleshooting Guide

A complete, copy-pasteable guide for resolving the #1 cause of Google
Sign-In failure on Play Store builds: SHA-1 fingerprint mismatch between
your local builds and the Play App Signing key.

Confirmed working: 2026-05-07. Project: motoshare_driver_admin,
Cloud project: motoshare-a61eb (display name Motoshare).

1. Symptoms

The bug always presents the same way:

Build	Result
`flutter run` (debug build on emulator)	Google Sign-In works
`flutter run --release` on a USB-connected phone	Google Sign-In works
Side-loaded local APK / AAB	Google Sign-In works
App downloaded from Play Store / Internal testing track	Google Sign-In silently fails

Common error patterns reported by users:

"Sign-In failed" toast right after picking an account
Account picker opens but never returns
Plugin throws PlatformException(sign_in_failed, …, status: 12500) or status 10

If your Sign-In fails on any other build (e.g. emulator), this is not the
bug described here — see Section 7 — When this guide doesn't apply.

2. Why it happens — the root cause

When you upload an .aab to Google Play, Google strips your signature and
re-signs the app with their own key (the "App signing by Google Play"
feature, mandatory since 2021). This means three different signing keys are
in play, with three different SHA-1 fingerprints:

                                                  SHA-1 fingerprint
                                                  ─────────────────
[1]  flutter run / debug builds      → debug key      AA:BB:CC:...
[2]  flutter build appbundle         → upload key     DD:EE:FF:...
[3]  Install from Play Store         → Google's       11:22:33:...
                                       app signing
                                       key

Google Sign-In's Android client checks the running app's signature against
the SHA-1s registered on its OAuth Android client. If the SHA-1 doesn't
match, sign-in is rejected before any UI even appears.

Most developers register only key 1 or 2. Key [3] is
controlled by Google and lives in Play Console — it's not on your machine,
which is why this bug never reproduces locally.

3. Architecture: where SHA-1s need to be

                                                  ┌──────────────────────┐
                                                  │  Google Cloud OAuth  │
   Phone runs APK signed with one of these keys → │  Android client(s)   │
                                                  │  for package         │
   ┌──────────┐  ┌──────────┐  ┌──────────────┐   │  com.cotocus...      │
   │ Debug    │  │ Upload   │  │ App signing  │ ←─┤  Each client holds   │
   │ keystore │  │ keystore │  │ (Google)     │   │  exactly ONE SHA-1   │
   └──────────┘  └──────────┘  └──────────────┘   └──────────────────────┘
        │             │              │
        SHA-1 [1]    SHA-1 [2]      SHA-1 [3]   ← all three must be
                                                  registered against the
                                                  same package name

Because each Android OAuth client only allows one SHA-1, you need
multiple Android OAuth clients with the same package name, one per
SHA-1. Google's auth servers accept whichever SHA-1 matches the running
build.

4. The fix — step by step

Total time: ~5 minutes. No app rebuild or new release upload required.

Step 1 — Get the App signing key SHA-1 from Play Console

Open Play Console → select your app.
Left sidebar → Test and release → App integrity.
Find the App signing section. Click to expand if needed.
Two certificates appear:

App signing key certificate         ← copy SHA-1 from THIS one
  SHA-1: 11:22:33:44:55:66:...
  SHA-256: ...

Upload key certificate
  SHA-1: DD:EE:FF:...
  SHA-256: ...

Copy the SHA-1 under App signing key certificate. It will look like:

9A:04:19:E7:58:68:3A:70:7B:7D:5B:D1:28:91:36:5C:B1:3C:5E:D7

(40 hex chars separated by colons.)

Critical: copy from App signing key certificate, not from
Upload key certificate. They are different keys.

Step 2 — Add a new Android OAuth client in Google Cloud Console

Open Google Cloud Console → make sure the project selector at the top shows the same project that your app uses for Sign-In. (For this repo: Motoshare / motoshare-a61eb.)
Sidebar → APIs & Services → Credentials.
Top bar → + CREATE CREDENTIALS → OAuth client ID.
Fill in:

Field	Value
Application type	Android
Name	`<your-app> (play signing)` — anything descriptive
Package name	Same as your existing Android client (e.g. `com.cotocus.motoshare_driver_admin`)
SHA-1 certificate fingerprint	Paste the SHA-1 from Step 1

Click Create.

You should now see two Android OAuth clients in the Credentials list,
both with the same package name but different SHA-1s. Keep both — do
not delete the original. The original SHA-1 still serves your local debug
and upload-signed builds.

Step 3 — Verify OAuth consent screen is published

This is a frequent secondary cause of Play Store failures.

Sidebar → Google Auth Platform → Audience (formerly "OAuth consent screen").
Publishing status must be In production.
User type should be External.
If status says Testing, click PUBLISH APP → confirm.

Apps in Testing mode only allow sign-in for explicitly-added test
users. Anyone else gets an error regardless of SHA-1.

Step 4 — Confirm the Web client ID in Flutter code

The google_sign_in plugin needs the Web client ID to issue ID tokens,
not the Android client ID. Open your code where GoogleSignIn is
configured:

// lib/src/shared/providers.dart
const _googleWebClientId =
    '335553606969-k446g8jjeclomdbf4etgdgdgdfdddrhs5.apps.googleusercontent.com';

Verify:

Type is Web application (not Android)
It lives in the same Cloud project as your Android clients
The string matches the Client ID shown for the Web OAuth client in Cloud Console → Credentials

For this repo it should match motoshare-driver-admin-web.

Step 5 — Test

No rebuild, no new release upload — these changes are server-side.

Wait 5–10 minutes for Google's auth servers to propagate.
On a real phone:
- Uninstall the Play Store version
- Re-install from Play Store (Internal testing track is fine)
- Tap Google Sign-In → pick account → should succeed

5. Verifying you actually fixed it

After ~10 minutes of normal use, return to the new OAuth client in Cloud
Console:

APIs & Services → Credentials → click your new "(play signing)" client

Look at Last used date in the right-hand panel. If it shows today's
date, your Play Store APK is actively reaching this client and SHA-1
matching is working.

Last used date    May 7, 2026 (Note: this data could be delayed by a day
                  or more.)

That timestamp is the strongest single signal that the fix worked.

6. Common pitfalls

Pitfall: copied the Upload key SHA-1 instead of App signing key

Both certificates are listed on the same page in Play Console. They are
different keys. Only the App signing key certificate SHA-1 fixes this
bug.

Pitfall: deleted the old Android client

Don't. The original client's SHA-1 covers your debug and release-built
local APKs. Deleting it breaks flutter run and any side-loaded build.
Keep both Android clients alive.

Pitfall: pasted the SHA-1 into the wrong Cloud project

Many teams have multiple Cloud projects (in this repo there's also a
Motoshare Old). The SHA-1 must go into the same project that your
Web client lives in — otherwise the Web ID token issued at runtime can't
be matched to the Android client. Confirm the project selector at the top
of Cloud Console matches the one referenced by _googleWebClientId in
your Flutter code.

Pitfall: tried to "Link Cloud project" in Play Console and got "Project not found"

That's a separate feature for the Play Integrity API, unrelated to
Google Sign-In. The error means your account isn't an Owner on the Cloud
project. Skip this — Sign-In doesn't require it.

Pitfall: still in Testing mode

Even with the right SHA-1, an OAuth consent screen in Testing mode
blocks every Google account that isn't on the test users list. Push to
In production under Audience.

Pitfall: passing the Android client ID as `serverClientId`

The google_sign_in plugin needs the Web client ID. Android client
IDs don't issue ID tokens. Symptom: account picker works, but the backend
ID-token verification fails afterward.

Pitfall: `google-services.json` references the wrong project

If your repo uses Firebase tooling, an outdated android/app/google-services.json
can pin Sign-In to a stale project. Re-download it from Firebase Console
(or delete it entirely if you don't use Firebase — google_sign_in works
without it as long as serverClientId is hard-coded).

7. When this guide doesn't apply

This guide solves only the Play-Store-specific Sign-In failure. If
Sign-In is broken in all environments (emulator, local APK, Play
Store), you have a different bug. Likely culprits:

Wrong package name in the OAuth client (must exactly match applicationId in android/app/build.gradle.kts)
serverClientId pointing at a deleted or wrong-project Web client
OAuth consent screen requesting unverified sensitive scopes
google_sign_in plugin version mismatch with google_sign_in_android
MainActivity not extending FlutterFragmentActivity (for plugins that need it)
Backend rejecting the ID token (audience or issuer mismatch in Keycloak)

Use adb logcat | grep -iE "googlesignin|gms|auth" while reproducing the
failure to capture the exact error code. Status code reference:

Status	Meaning
`12500`	`SIGN_IN_FAILED` — usually SHA-1 / package mismatch
`12501`	User cancelled
`12502`	Sign-in already in progress
`10`	`DEVELOPER_ERROR` — config wrong (SHA-1, package, or client ID)
`7`	Network error

Status 10 and 12500 are the SHA-1-related ones.

8. Reference: this repo's exact configuration (post-fix)

Cloud project:     Motoshare (motoshare-a61eb), project number 338933606969

OAuth 2.0 Client IDs:
  motoshare-driver-admin-web                Web      338933606969-k446...
  motoshare-driver-admin-app                Android  88:6C:D0:27:21:3F:2E:DA:2E:EE:E3:A6:51:A0:4F:50:1B:F1:F3:20  (debug/upload)
  motoshare-driver-admin-app (play signing) Android  9A:04:19:E7:58:48:3A:70:6B:7D:5B:D1:28:91:36:5C:B1:4C:3E:D7  (Play App Signing)

Both Android clients use package: com.cotocus.motoshare_driver_admin

Flutter code (lib/src/shared/providers.dart):
  serverClientId = '338933606969-k446g8jjeclomdbf4ete2efmgr06rhs5.apps.googleusercontent.com'
                   (matches motoshare-driver-admin-web)

Audience: External, Publishing status: In production

9. Quick-start checklist for future apps

When wiring Google Sign-In on a new Android app, do all of this before
the first Play Store release:

[ ] Create one Android OAuth client with your debug keystore SHA-1
[ ] Create one Web OAuth client → use its Client ID as serverClientId
[ ] Set OAuth consent screen → External, In production
[ ] Upload first AAB to Play Console → enable App signing
[ ] Read the App signing key SHA-1 from Play Console → App integrity
[ ] Create a second Android OAuth client with that SHA-1, same package name
Create a third Android client with your upload key SHA-1 if you sometimes share an upload-signed APK directly with testers
[ ] Confirm Sign-In works on Play Store install (Last used date updates within minutes)

Tracking SHA-1s up front saves a release cycle of debugging later.

10. Reusing this guide

This guide is project-agnostic apart from Section 8. To adapt it for
another app, change:

The Cloud project ID, project number, and client IDs in Section 8
The package name (com.cotocus.motoshare_driver_admin) in Section 4
The serverClientId constant location and value in Steps 4 and Section 8

Why Google Sign-In Works on Your Emulator But Breaks on Play Store

Abhishek singh — Thu, 07 May 2026 07:29:41 +0000

Why Google Sign-In Works on Your Emulator But Breaks on Play Store — and How to Fix It in 5 Minutes

Suggested tags: #Flutter, #Android, #GoogleSignIn, #PlayStore, #OAuth, #DebuggingDiaries

Reading time: ~6 minutes

The Bug That Only Shows Up After You Ship

Picture this: you've spent two weeks wiring Google Sign-In into your
Android app. It works perfectly on your emulator. It works on your
teammate's Pixel. The QA build, side-loaded over USB, works. You ship a
release build to Google Play, hit the green publish button, and crack open
a celebratory chai.

Five minutes later, a tester pings you:

"Hey, I downloaded the app from Play Store and Google Sign-In just…
doesn't do anything. Account picker doesn't even open."

You blink. You check your phone. You uninstall the dev build, install from
Play Store… and watch the same thing happen. The exact same APK that
worked thirty minutes ago is now broken.

Welcome to one of Android's most confusing OAuth bugs. The good news?
There is one specific cause, and it takes about five minutes to fix once
you know what to do. The bad news is that almost no one finds the answer
on the first Stack Overflow page they read, because the symptoms point at
ten different culprits.

This article walks through what's actually going wrong, why it only
happens on Play Store builds, and the precise fix that resolves it without
a single line of code change or a new release upload.

Three Signatures, One Confused OAuth Client

Here's the thing nobody tells you when you set up Google Sign-In: your
Android app gets signed with at least three different cryptographic
keys during its lifetime, and Google checks all of them.

                                                  SHA-1 fingerprint
                                                  ─────────────────
[1]  flutter run / debug builds      → debug key      AA:BB:CC:...
[2]  flutter build appbundle         → upload key     DD:EE:FF:...
[3]  Install from Play Store         → Google's       11:22:33:...
                                       app signing
                                       key

When you run your app from Android Studio or flutter run, the APK is
signed with your machine's local debug keystore. That's signature [1].

When you build a release AAB and upload it to Play Store, you sign it with
your upload keystore — usually one you generated when you first set up
Play signing. That's signature [2].

And here's the kicker: Google does not actually distribute the AAB you
uploaded. Since 2021, Play Console mandates a feature called App
signing by Google Play. When you upload your .aab, Google strips your
signature, repackages the bundle into APKs for different device profiles,
and re-signs them with their own internal key. That's signature [3].
You never see this key. You can't access it. It lives entirely on
Google's servers.

So when a real user installs your app from the Play Store, the APK
running on their phone is signed with a key your machine has never
touched.

Why does this matter for Google Sign-In? Because Google's OAuth servers
verify the signature of the calling app on every Sign-In request. The
SHA-1 fingerprint of whichever key signed the running APK has to match
one that's registered against your Android OAuth client in Google Cloud
Console.

When you set up Google Sign-In during development, you almost certainly
registered key 1 or key 2. You probably never
registered key [3], because Play hadn't generated it yet — the App
signing key is created the first time you upload an AAB.

That's the bug. Your Cloud Console only knows about [1] and/or [2].
The Play Store APK is signed with [3]. Google's OAuth servers see a key
they don't recognize and silently drop the request. From the user's
perspective, Sign-In just… does nothing.

Symptoms That Lead Everyone Astray

The reason this bug eats hours of debugging time is that the failure mode
is almost too clean. There's no crash. No red snackbar. No useful logcat
line that says "SHA-1 mismatch."

What you see instead:

The Google account picker briefly flickers, then closes
A toast saying "Sign-in failed" appears with no further detail
PlatformException(sign_in_failed, …, status: 12500) — but only if you're already running through adb logcat
Sometimes status code 10, which is documented as DEVELOPER_ERROR and is even more cryptic than 12500

Status code 12500 and 10 are the two fingerprints of this specific
bug. If you grep your logcat output and see either, stop reading Stack
Overflow threads about scopes, plugin versions, or token expiry — you
have a SHA-1 problem.

The other reason people miss this for so long: everything works in
development. Emulator? Works. Local USB build? Works. Internal testing
track if you side-load the APK from a download link? Works. The bug
only appears once Google's app-signing pipeline gets involved, and that
only happens when a real user clicks Install on the Play Store listing.

The Fix, Plain and Simple

Now that we've named the cause, the fix is mechanical. There are exactly
two pieces:

Find out what SHA-1 Google's app-signing key has (this lives in Play Console)
Tell Google's OAuth servers about it (by registering it on a new Android OAuth client in Cloud Console)

No code changes. No rebuild. No new release upload. The whole thing is
configuration on Google's side, and the change propagates to your live
Play Store build within minutes.

Step 1 — Get the App Signing key SHA-1 from Play Console

Open Play Console, select your app,
and navigate:

Test and release  →  App integrity  →  App signing

You'll see two certificates listed:

App signing key certificate ← copy the SHA-1 from this one
Upload key certificate ← not this one

The distinction matters. The Upload key is yours; the App signing key is
Google's. Only the App signing key SHA-1 fixes this bug. Both certificates
are listed on the same page, which is exactly why people copy the wrong
one.

The SHA-1 looks something like:

9A:04:19:E7:48:48:3A:70:6B:5D:5B:h1:28:91:36:5C:B1:4C:3E:D7

40 hexadecimal characters separated by colons. Copy it.

Step 2 — Register a new Android OAuth client with that SHA-1

Open Google Cloud Console, make sure
the project selector at the top points to the same Cloud project your
app uses for Sign-In. (This is a common pitfall — if your team has
multiple Cloud projects, getting this wrong silently breaks everything.)

Then:

APIs & Services  →  Credentials  →  + CREATE CREDENTIALS  →  OAuth client ID

Fill in the form:

Field	Value
Application type	Android
Name	`<your-app> (play signing)` — anything descriptive
Package name	The exact `applicationId` from your `build.gradle`
SHA-1 certificate fingerprint	The one you copied from Play Console

Click Create.

You will now have two Android OAuth clients with the same package name
in your project — one with your debug/upload SHA-1, one with the Play
App Signing SHA-1. Don't delete the original. Both serve a purpose.
Google's OAuth servers accept whichever SHA-1 matches the running build,
so this configuration covers all three signing keys at once.

The reason you need two separate clients is a quirk of Cloud Console:
each Android OAuth client allows exactly one SHA-1. Firebase users get a
nicer UI here (multiple fingerprints per app), but if you're working with
the Cloud Console directly, the workaround is to make a second client.

Step 3 — Make sure your OAuth consent screen is published

This is the secondary cause that bites about a third of teams who fix
the SHA-1 issue. Even with a perfect SHA-1 setup, if your OAuth consent
screen is in Testing mode, only emails on the test users list can
sign in. Everyone else gets an error indistinguishable from the SHA-1
bug.

Navigate:

APIs & Services  →  OAuth consent screen  →  Audience

(Google recently renamed parts of this UI to Google Auth Platform; the
location of the Audience sub-page is the same.)

Look at Publishing status. If it says Testing, click PUBLISH
APP and confirm. For apps requesting only basic scopes (email,
profile, openid), publishing is instant. For apps requesting
sensitive or restricted scopes, Google will ask for verification, which
can take days — but Sign-In flows for typical apps don't need those
scopes.

Step 4 — Verify your Flutter code uses the Web client ID

This one isn't strictly part of the fix, but it's worth confirming. The
google_sign_in plugin needs the Web OAuth client ID to issue ID
tokens, not the Android client ID. If your code has the Android
client ID in serverClientId, the account picker will work but the
backend ID-token verification will fail.

Open the file where you initialize GoogleSignIn:

// Should look something like this — the ID belongs to a Web-type client.
const _googleWebClientId =
    '338935556969-k446g8gdgbdxgbdgvdefmgr06rhs5.apps.googleusercontent.com';

Cross-reference it with Cloud Console. The corresponding OAuth client
should be type Web application, not Android. If it's Android, that's
your second bug.

Step 5 — Test

This is the part that surprises people the most: you don't need to
rebuild. The fix is purely server-side on Google's auth infrastructure.
Wait 5 to 10 minutes for propagation, then:

Uninstall the Play Store version of your app from a real phone
Re-install from Play Store (Internal testing track is fine)
Open the app, tap Google Sign-In, pick an account

It should now work end-to-end. The same .aab you uploaded yesterday now
authenticates correctly because Google's OAuth servers learned a new
SHA-1.

How to Verify You Actually Fixed It

After ten minutes of normal use, return to your new OAuth client in Cloud
Console:

APIs & Services  →  Credentials  →  click your "(play signing)" client

In the right-hand panel you'll see a Last used date field:

Last used date    May 7, 2026 (Note: this data could be delayed by a day
                  or more.)

If it shows today, congratulations: your Play Store APK is hitting this
exact OAuth client and the SHA-1 is matching successfully. That timestamp
is the single strongest signal that the fix worked. Until I saw it on my
own client, I couldn't quite believe a config change was enough — and
neither will the next person you tell about this fix.

Pitfalls Worth Calling Out

A few traps that snagged me along the way and might snag you too:

Don't copy the Upload key SHA-1. Both certificates are right next to
each other on the App signing page. Only the App signing key SHA-1
matters here.

Don't delete the old Android OAuth client. It still serves your
debug builds and any side-loaded local APKs. Two clients, same package
name, different SHA-1s, both alive — that's correct.

Make sure you're in the right Cloud project. Teams with multiple
Cloud projects (legacy ones, separate projects per environment) often
land on the wrong one. The Web client ID hard-coded in your Flutter app
tells you which project Sign-In is bound to — match it.

Don't try to "Link Cloud project" in Play Console looking for this
fix. That feature is for the Play Integrity API, which is unrelated to
Google Sign-In, and the most common error you'll see ("Project not
found") just means your account isn't an Owner on the Cloud project. You
don't need to link anything for Sign-In to work.

Don't pass the Android client ID as serverClientId. It has to be
the Web client ID. The plugin will sometimes appear to work and then
break in obscure ways during ID token verification.

A Lesson In Distributed Trust

The deeper takeaway here is that mobile app authentication, post-Play
App Signing, involves three trusted parties: your team's local
keystores, Google Play's signing infrastructure, and Google's identity
servers. They have to agree on the identity of your app, and the only
way they agree is via SHA-1 fingerprints registered against an OAuth
client.

It's elegant when it works. It's baffling when it doesn't, because the
machinery is invisible until something breaks. The first time you ship a
production Android app with Google Sign-In, this bug is almost
inevitable. The good news is that you only need to learn it once.

If you're setting up Google Sign-In on a new Android app, here's the
checklist I now run before the first Play Store release:

One Android OAuth client with the debug keystore SHA-1
One Android OAuth client with the upload keystore SHA-1 (if you ever share upload-signed APKs directly with testers)
One Web OAuth client → use its Client ID as serverClientId
OAuth consent screen → External, In production
Upload first AAB, enable App signing, immediately read the App signing key SHA-1 from Play Console
Create a third Android OAuth client with that SHA-1, same package name
Confirm Sign-In works on Play Store install — Last used date updates within minutes

Tracking all the SHA-1s up front saves a release cycle of debugging
later, and you'll never wonder again why something that works on three
separate emulators doesn't work after Play touched it.

Closing

If this article saved you an evening, pass it on to whoever sets up
Sign-In on the next Android app at your company. The official Google
documentation describes most of these moving parts individually, but I
have yet to see them connected in one place — and the failure mode is
common enough that I suspect every Android team rediscovers it
independently.

Five minutes, two new lines in Cloud Console, no rebuild. That's all it
takes to turn "Sign-In is broken on Play Store" into a story you tell
junior devs at standup.

Git Multi-Remote Workflow:It Multiple Remote Management Guide

Abhishek singh — Wed, 01 Apr 2026 12:41:13 +0000

🚀 Git Multi-Remote Workflow: How to Manage and Push Code to Multiple Repositories (origin & old-origin) Like a Pro

Introduction

In real-world development—especially when you're working as a CTO or managing multiple environments—you often face a situation like:

One repo for production
One repo for backup / legacy
One repo for client delivery
One repo for internal development

And suddenly, your simple Git workflow becomes complex.

You ask:
👉 “How do I manage different codebases across multiple repos without breaking anything?”

This guide solves that completely.

By the end, you will:

Understand how Git multi-remote works
Switch between repos safely
Handle different code in origin and old-origin
Use production-level strategies (branch isolation, syncing, migration)
Avoid dangerous mistakes like overwriting code

What is Multi-Remote in Git
Understanding origin vs old-origin
Core Concept: Code vs Remote (Most Important)
Real Workflow Scenarios
Step-by-Step Implementation (Production Setup)
Managing Different Codebases Safely
Architecture-Level Strategy (CTO Thinking)
Comparison: Single Repo vs Multi Repo
Common Mistakes & Fixes
Expert Pro Tips
FAQ
Conclusion
Meta Description

1. What is Multi-Remote in Git

Git allows you to connect your local project to multiple remote repositories.

Example:

origin      → New Repo
old-origin  → Old Repo

This is called multi-remote setup.

2. Understanding origin vs old-origin

In your case:

origin      = New repository
old-origin  = Old repository

These are just aliases, not actual code.

👉 Important:

Remote names do NOT store code. They only define destinations.

3. Core Concept: Code vs Remote (MOST IMPORTANT)

This is where most developers get confused.

Reality:

Component	Meaning
Local branch	Your actual code
Remote (origin)	Where you push
Remote (old-origin)	Another destination

👉 Key Rule:

Git always pushes your current local branch code, not remote code.

4. Real Workflow Scenarios

Scenario 1: Push same code to both repos

git push origin main
git push old-origin main

Scenario 2: Different code in both repos

This is your real case.

You must:

Pull code from respective repo
Switch context locally
Then push

5. Step-by-Step Implementation (Production Setup)

Step 1: Add both remotes

git remote rename origin old-origin
git remote add origin git@github.com:yourusername/new-repo.git

Step 2: Fetch all data

git fetch origin
git fetch old-origin

Step 3: Create separate local branches

git checkout -b new-main origin/main
git checkout -b old-main old-origin/main

Now your structure:

Branch	Code Source
new-main	New repo
old-main	Old repo

Step 4: Work with branches

Use new repo code:

git checkout new-main

Use old repo code:

git checkout old-main

Step 5: Push correctly

Push new repo code:

git checkout new-main
git push origin new-main:main

Push old repo code:

git checkout old-main
git push old-origin old-main:main

6. Managing Different Codebases Safely

Golden Rule:

One branch = One source of truth

Never mix:

origin/main
old-origin/main

Instead:

new-main
old-main

If you want to copy code between repos

Copy old repo → new repo

git checkout old-main
git push origin old-main:main

Copy new repo → old repo

git checkout new-main
git push old-origin new-main:main

7. Architecture-Level Strategy (CTO Thinking)

In enterprise systems, this is how multi-repo is used:

Use Cases

Use Case	Strategy
Backup system	old-origin
Migration	move code gradually
Multi-client deployment	separate repos
Version isolation	repo-based control

Architecture Model

                LOCAL SYSTEM
              /              \
     new-main branch      old-main branch
          |                    |
       origin               old-origin
     (new repo)           (old repo)

8. Comparison Table

Approach	Pros	Cons	Best Use Case
Single Repo	Simple	No flexibility	Small projects
Multi Remote	Flexible	Needs discipline	Enterprise
Multi Branch	Controlled	Slight complexity	Dev teams
Multi Repo	Full isolation	Hard to sync	Large org

9. Common Mistakes (Real-World)

❌ Mistake 1: Pushing wrong code

git push origin main

Without checking branch

✅ Fix:

git branch

❌ Mistake 2: Mixing repos

Using one branch for both repos

✅ Fix:
Use separate branches

❌ Mistake 3: Force pushing blindly

git push --force

✅ Fix:
Use only when required

❌ Mistake 4: Not fetching remotes

Leads to outdated code

✅ Fix:

git fetch origin
git fetch old-origin

10. Expert Pro Tips

🔥 Pro Tip 1: Always verify before push

git status
git branch

🔥 Pro Tip 2: Use aliases

alias gpo="git push origin main"
alias gpol="git push old-origin main"

🔥 Pro Tip 3: Protect main branch

Use:

Protected branches in GitHub
PR-based deployment

🔥 Pro Tip 4: Use staging branches

staging-main
production-main

🔥 Pro Tip 5: Use tagging for releases

git tag v1.0
git push origin v1.0

11. FAQ

1. Can I push different code to two repos?

Yes. Use separate local branches.

2. Can I sync both repos automatically?

Yes, but better to control manually for safety.

3. What happens if both repos have different history?

You must:

merge OR
force push carefully

4. Is multi-remote safe?

Yes, if you follow branch discipline.

5. Should I use this in production?

Yes, especially for:

migration
backup
multi-client systems

12. Conclusion

Managing multiple Git repositories is not complex—if you follow the right architecture.

Key Takeaways:

Remote = destination
Branch = code
Always separate codebases using branches
Never mix repositories blindly

Your Action Plan:

Setup origin and old-origin
Create new-main and old-main
Always switch branch before push
Push carefully based on destination

WhatsApp vs SMS Pricing in India: Complete Guide for OTP, Marketing & Notifications (2026)

Abhishek singh — Tue, 24 Mar 2026 05:31:23 +0000

WhatsApp vs SMS Pricing in India: Complete Guide for OTP, Marketing & Notifications (2026)

Introduction

If you're building a product, SaaS platform, or customer communication system in India, one question always comes up:

Should I use WhatsApp or SMS for sending OTPs, marketing messages, or notifications?

At first glance, both seem similar — they deliver messages to users. But when you go deeper, you’ll realize:

Pricing models are completely different
Use cases vary significantly
Cost impact can be huge at scale

This guide will give you a complete, practical, and real-world understanding of:

WhatsApp pricing (Meta direct)
SMS pricing (Twilio India)
Cost comparison for OTP, marketing, and notifications
Best strategy for your business

By the end, you won’t need any other resource.

What is WhatsApp Business API?
What is SMS (Twilio)?
WhatsApp Pricing Model (India)
SMS Pricing Model (India)
WhatsApp vs SMS Cost Comparison Table
OTP Pricing Comparison
Marketing Pricing Comparison
Notification Pricing Comparison
Real-Life Use Cases
Best Practices
Common Mistakes to Avoid
FAQs
Conclusion

1. What is WhatsApp Business API?

WhatsApp Business API (Meta) allows businesses to send:

OTPs (Authentication)
Notifications (Utility)
Marketing campaigns
Customer support messages

Key Features:

Rich media (images, buttons, links)
Two-way communication
High engagement rates
Template-based messaging

2. What is SMS (Twilio)?

SMS is the traditional way to send messages using telecom networks.

With Twilio, you can:

Send OTPs
Send alerts
Run marketing campaigns

Key Features:

Works on all phones
No internet required
Simple implementation

3. WhatsApp Pricing Model (India)

WhatsApp pricing is not fixed per message. It depends on:

Message Categories:

Authentication (OTP)
Utility (notifications)
Marketing
Service (support replies)

Important Rules:

Service messages = FREE (within 24 hours)
User replies open a 24-hour window
Charges apply only for template messages outside window

Approx Pricing (India):

Category	Approx Cost (INR)
Authentication (OTP)	₹0.30 – ₹0.80
Utility (Notification)	₹0.20 – ₹0.60
Marketing	₹0.80 – ₹2.50
Service (Reply)	FREE

4. SMS Pricing Model (India)

SMS pricing is simple but expensive.

Twilio India Pricing:

$0.0832 ≈ ₹7.8 per SMS segment

Important Points:

Charged per segment (160 characters)
Long messages = multiple SMS charges
No free window

5. WhatsApp vs SMS Cost Comparison Table

Use Case	WhatsApp Cost (INR)	SMS Cost (INR)	Winner
OTP	₹0.30 – ₹0.80	₹7.80	WhatsApp
Marketing	₹0.80 – ₹2.50	₹7.80+	WhatsApp
Notification	₹0.20 – ₹0.60	₹7.80	WhatsApp
Support Reply	FREE	₹7.80	WhatsApp

6. OTP Pricing Comparison

WhatsApp OTP:

Category: Authentication
Cost: ~₹0.30 – ₹0.80

SMS OTP:

Cost: ~₹7.80 per SMS

Example:

If you send 1000 OTPs:

Channel	Total Cost
WhatsApp	₹300 – ₹800
SMS	₹7800

Insight:

👉 WhatsApp is 10x cheaper for OTP

7. Marketing Pricing Comparison

WhatsApp Marketing:

Cost: ₹0.80 – ₹2.50
Includes:
- Buttons
- Images
- Links

SMS Marketing:

Cost: ₹7.80+
Plain text only

Example (1000 messages):

Channel	Total Cost
WhatsApp	₹800 – ₹2500
SMS	₹7800+

Insight:

👉 WhatsApp gives better ROI + lower cost

8. Notification Pricing Comparison

WhatsApp Notification:

Utility messages
Cost: ₹0.20 – ₹0.60
FREE if within support window

SMS Notification:

Cost: ₹7.80

Example (1000 messages):

Channel	Total Cost
WhatsApp	₹200 – ₹600
SMS	₹7800

Insight:

👉 Notifications are extremely cheap on WhatsApp

9. Real-Life Use Cases

Case 1: E-commerce Platform

Order confirmation → WhatsApp
Delivery updates → WhatsApp
Backup → SMS (if WhatsApp fails)

Case 2: Banking App

OTP → WhatsApp + SMS fallback
Alerts → WhatsApp

Case 3: SaaS Platform

Login OTP → WhatsApp
Notifications → WhatsApp
Marketing → WhatsApp campaigns

10. Best Practices

1. Use Hybrid Strategy

Primary: WhatsApp
Fallback: SMS

2. Optimize Message Length

SMS charges per segment

3. Use WhatsApp Templates Smartly

Avoid unnecessary marketing messages

4. Track Delivery Rates

Improve ROI

5. Use Automation

Trigger-based messaging

11. Common Mistakes to Avoid

❌ Sending all messages via SMS
❌ Ignoring WhatsApp free window
❌ Not using fallback system
❌ Sending long SMS (cost increases)
❌ Poor template approval strategy

12. FAQs

1. Is WhatsApp cheaper than SMS in India?

Yes, 5x–20x cheaper depending on use case.

2. Can WhatsApp replace SMS completely?

No, because:

Some users don’t use WhatsApp
SMS is still needed as fallback

3. Which is better for OTP?

👉 WhatsApp (cost) + SMS (reliability)

4. Are WhatsApp replies free?

Yes, within 24-hour service window

5. Why is SMS expensive?

Because it uses telecom networks + carrier charges

13. Conclusion

If you are building a modern application in India:

Best Strategy

Use WhatsApp as primary channel
Use SMS as backup only

Final Comparison:

WhatsApp = Cheap + Rich + Interactive
SMS = Expensive + Basic + Reliable

Actionable Advice:

Start with:

WhatsApp OTP system
WhatsApp notifications
SMS fallback

This will:

Reduce cost by 80–90%
Improve user experience
Increase engagement