app/src/main/java/me/capcom/smsgateway/modules/receiver/ReceiverService.kt (1)

25-49: Make lifecycle guard atomic for concurrent start/stop calls.

started/mmsContentObserver are mutable shared state without synchronization. Concurrent calls can still interleave and double-register observers.

🔧 Suggested hardening

 class ReceiverService : KoinComponent {
@@
     private val eventsReceiver by lazy { EventsReceiver() }
+    private val lifecycleLock = Any()
     private var started = false
     private var mmsContentObserver: MmsContentObserver? = null

     fun start(context: Context) {
-        if (started) {
-            return
-        }
+        synchronized(lifecycleLock) {
+            if (started) return

-        MessagesReceiver.register(context)
-        MmsReceiver.register(context)
-        eventsReceiver.start()
+            MessagesReceiver.register(context)
+            MmsReceiver.register(context)
+            eventsReceiver.start()

-        val observer = MmsContentObserver(context) { mmsId ->
-            processMmsDownloaded(context, mmsId)
-        }
-        observer.start()
-        mmsContentObserver = observer
-        started = true
+            val observer = MmsContentObserver(context) { mmsId ->
+                processMmsDownloaded(context, mmsId)
+            }
+            observer.start()
+            mmsContentObserver = observer
+            started = true
+        }
     }

     fun stop(context: Context) {
-        mmsContentObserver?.stop()
-        mmsContentObserver = null
-        started = false
-        eventsReceiver.stop()
-        MmsReceiver.unregister(context)
-        MessagesReceiver.unregister(context)
+        synchronized(lifecycleLock) {
+            mmsContentObserver?.stop()
+            mmsContentObserver = null
+            started = false
+            eventsReceiver.stop()
+            MmsReceiver.unregister(context)
+            MessagesReceiver.unregister(context)
+        }
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/me/capcom/smsgateway/modules/receiver/ReceiverService.kt`
around lines 25 - 49, The start/stop lifecycle is not thread-safe: the mutable
fields started and mmsContentObserver can be accessed concurrently causing
double-registration or lost cleanup. Make access atomic by guarding start() and
stop() with a single synchronization mechanism (e.g., use a private lock object
or replace started with an AtomicBoolean) so that registration
(MessagesReceiver.register, MmsReceiver.register, eventsReceiver.start,
creating/starting and assigning MmsContentObserver) and teardown
(mmsContentObserver?.stop, nulling mmsContentObserver, setting started to false,
eventsReceiver.stop) happen as an atomic critical section; ensure you check and
set the guard atomically (compare-and-set if using AtomicBoolean) and only
perform observer start/stop when the guard transition succeeds to avoid
double-registers or races.

app/src/main/assets/api/swagger.json (1)

78-94: ⚠️ Potential issue | 🟠 Major

Add format: "int64" to partId and size fields to match Kotlin Long type.

The runtime fields are Long (64-bit), but the schema uses plain integer without format. OpenAPI generators default to 32-bit integers without an explicit format, risking overflow and client code mismatch.

🔧 Proposed fix

           "partId": {
             "description": "The _id from content://mms/part.",
+            "format": "int64",
             "type": "integer"
           },
@@
           "size": {
             "description": "Size in bytes, 0 if unknown.",
+            "format": "int64",
             "type": "integer"
           },

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/assets/api/swagger.json` around lines 78 - 94, The OpenAPI
schema fields "partId" and "size" are declared as type: integer but need format:
"int64" to match the Kotlin Long runtime type; update the swagger.json entries
for the properties named partId and size to include "format": "int64" (keeping
their type as integer) so OpenAPI generators and clients treat them as 64-bit
integers and avoid 32-bit overflow/mismatches.

app/src/main/assets/api/swagger.json (1)

57-63: Consider capping attachments array size in the contract.

attachments is currently unbounded. Adding maxItems improves contract safety and resolves the static-analysis concern for unbounded arrays.

💡 Suggested schema hardening

               "attachments": {
                 "description": "Metadata for non-text MMS parts, including optional Base64 content.",
                 "items": {
                   "$ref": "#/components/schemas/MmsDownloadedAttachment"
                 },
+                "maxItems": 50,
                 "type": "array"
               },

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/assets/api/swagger.json` around lines 57 - 63, The attachments
array in swagger.json under the MmsDownloadedAttachment reference is unbounded;
add a maxItems constraint to that "attachments" schema (and optionally minItems
if appropriate) to cap the number of attachments (e.g., maxItems: 10 or another
project-appropriate limit) so the OpenAPI contract enforces a safe upper bound
for "attachments" and resolves static-analysis warnings.