Rastreador (BackgroundService)

Serviço em primeiro plano responsável por capturar posições GPS do motorista e enviá-las via socket TCP para o consumer (socket.monisat.online:6001). Implementa filtro de movimento, cache offline com flush LIFO em socket único, e canal de configuração dinâmica do interval via JSON enviado pelo servidor.

Quando o serviço roda

BackgroundService só inicia se todas as condições abaixo forem verdadeiras (checadas em onStartCommand antes de qualquer chamada a startForeground):

Se algum requisito falhar, o serviço chama startForeground sem o tipo location (FOREGROUND_SERVICE_TYPE_NONE = 0) só para satisfazer o contrato de 5 s do startForegroundService, e em seguida stopSelf().

Filtro de Movimento

Toda posição passa por shouldSendLocation(location, speedInKM, currentTime) antes de qualquer envio ou cache. A regra evita encher o cache de posições redundantes quando o veículo está parado.

Constantes (companion object)

private const val DISTANCIA_MINIMA_METROS         = 10f
private const val VELOCIDADE_PARADO_KMH           = 1.0f
private const val TEMPO_PARA_CONSIDERAR_PARADO_MS = 90_000L  // 90 s

O heartbeat de parado usa o interval dinâmico (em minutos), não uma constante. Default 3 min, configurável remotamente — ver Interval dinâmico.

Caminho de envio (realtime)

Quando o filtro aprova a posição e há rede disponível:

1. formatProtocol monta a linha MONIAPP;cpf;lat;lng;...
2. Atualiza lastSentLocation e lastSentTime antes do launch (evita disparo paralelo se outra posição chegar enquanto o socket está em andamento)
3. serviceScope.launch { connectAndSend(protocol) } abre socket próprio, envia, faz leitura curta, fecha
4. Falha na rede → posição vai para o cache

Cache offline

cacheItens: MutableList<UserLocationData> guarda posições que passaram pelo filtro mas não puderam ser enviadas. Entradas no cache:

• Sem rede: filtro aprovou + _isNetworkAvailable.value == false
• Envio realtime falhou: connectAndSend retornou false

Acesso ao cache é sincronizado via synchronized(cacheItens) em todas as leituras/escritas, pois o callback do GPS roda na main thread e o flush em Dispatchers.IO.

Flush do cache — socket único LIFO

Disparado por networkCallback.onAvailable quando a rede volta. sendCachedLocations abre uma única conexão TCP, dreina o cache do mais novo para o mais antigo, fecha.

Algoritmo

abre 1 socket (timeout 10s)
se falhou → mantém cache intacto, sai

writer = PrintWriter(socket.outputStream, autoFlush=true)
reader = BufferedReader(InputStreamReader(socket.inputStream))

loop:
  item = synchronized(cacheItens) {
      cacheItens.removeAt(size - 1)  // LIFO: mais novo primeiro
  }
  se cache vazio → break

  valida coordenadas → se inválido, descarta
  formata protocolo MONIAPP;...

  writer.println(protocolo)
  se writer.checkError() ou exception:
      synchronized(cacheItens) { cacheItens.add(item) }  // devolve
      break

writer.flush()
tryReadServerCommand(socket, reader)  // janela de 300ms
fecha socket

Por que LIFO (do mais novo para o mais antigo)

Por que socket único

O modelo antigo abria/fechava 1 socket por posição com delay(500ms) entre cada. Em 200 posições eram 200 handshakes TCP + 100 s de delay. Com socket único: 1 handshake total e println em sequência (line-delimited é o uso natural do protocolo).

Protocolo MONIAPP

Linha única terminada em \n (escrita via PrintWriter.println):

MONIAPP;{cpf};{lat};{lng};{timestamp_ms};{battery_pct};{speed_kmh};{os_name};{os_version};{device_model};{app_version_name};{app_version_code}

Interval dinâmico (configuração remota)

O interval (em minutos) controla o heartbeat de veículo parado. Default 3.0, persistido em DATA/interval_ms (Long, milissegundos para preservar precisão de fracionários como 3.5 → 3 min 30 s).

Fluxo da configuração

1. App escreve a linha MONIAPP no socket e dá flush()
2. App lê do socket com soTimeout = 300 ms via tryReadServerCommand
3. Se servidor respondeu uma linha JSON, parseia em handleServerCommand
4. Se vier {"interval": double} no range 0.1 – 60 min:
   • Atualiza a var @Volatile interval
   • Persiste em DATA/interval_ms
   • Próximo cálculo de heartbeat já usa o novo valor
5. Se vier valor inválido ou fora do range → log de warning e ignora

Exemplo de payload do servidor

{"interval": 3.5}

Foreground Service Type — Android 14+

Manifesto declara:

<service
    android:name=".service.BackgroundService"
    android:foregroundServiceType="location"/>

O startForeground usa ServiceInfo.FOREGROUND_SERVICE_TYPE_LOCATION explicitamente quando há permissão, e 0 quando não há (caminho de shutdown):

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {
    val type = if (useLocationType) ServiceInfo.FOREGROUND_SERVICE_TYPE_LOCATION else 0
    startForeground(NOTIFICATION_ID, notification, type)
} else {
    startForeground(NOTIFICATION_ID, notification)
}

Concorrência e thread-safety

LocationRequest

locationRequest = LocationRequest.create().apply {
    interval = 10_000          // 10 s entre samples
    fastestInterval = 5_000    // mínimo 5 s
    priority = LocationRequest.PRIORITY_HIGH_ACCURACY
}

O GPS amostra a cada 10 s independente do interval de envio. O filtro de movimento decide quais samples viram envio. Isso mantém precisão para detectar transições parado → movimento em até 10 s.

Reconexão de rede

ConnectivityManager.NetworkCallback mantém o flag _isNetworkAvailable sincronizado e dispara o flush quando a rede volta:

override fun onAvailable(network: Network) {
    _isNetworkAvailable.value = true
    if (cacheItens.isNotEmpty()) {
        serviceScope.launch { sendCachedLocations() }
    }
}

Configuração no SharedPreferences DATA

Mudanças recentes — histórico