Receive shares and serve file requests, so other apps can reach this one

The manifest had nothing but a LAUNCHER filter, so no other app could hand Plain Files anything. It now registers for ACTION_SEND and SEND_MULTIPLE (a bar over the browser: navigate to the folder, then Save here) and for GET_CONTENT and OPEN_DOCUMENT, where tapping a file hands it back through the existing FileProvider.

Both reuse the browser instead of a second screen, because both are navigate-to-a-folder with a different verb at the end. data/ gains one port, IncomingSource, to keep a ContentResolver out of the ViewModel the way DeleteRequestFactory keeps one out of the delete path. Shared files are named from the sender OpenableColumns, allocated by the same NameAllocator a paste uses, and deleted again if they cannot be read rather than left as zero-byte stubs. While providing, a tap on a file chooses it but a tap on a folder still navigates, or the user could never reach the file.

ACTION_VIEW is deliberately not registered: the app already hands files out through the system chooser, and registering as a viewer would offer Plain Files back to itself. No new permissions - the merged release manifest still declares no INTERNET.

app/src/main/java/de/softwareapp_hb/filemanager/FileManagerApplication.kt

@@ -1,7 +1,9 @@
 package de.softwareapp_hb.filemanager
 
 import android.app.Application
+import de.softwareapp_hb.filemanager.data.ContentResolverIncomingSource
 import de.softwareapp_hb.filemanager.data.DeleteRequestFactory
+import de.softwareapp_hb.filemanager.data.IncomingSource
 import de.softwareapp_hb.filemanager.data.MediaStoreDeleter
 import de.softwareapp_hb.filemanager.data.StorageProvider
 import de.softwareapp_hb.filemanager.domain.OperationNotifier
@@ -10,9 +12,9 @@ import de.softwareapp_hb.filemanager.service.ServiceOperationNotifier
 /**
  * Application entry point and the app's tiny object graph.
  *
- * There is no dependency-injection framework here on purpose: three long-lived
- * collaborators are built once and handed to the one ViewModel that needs them. Nothing
- * holds a reference to an Activity, so none of this leaks.
+ * There is no dependency-injection framework here on purpose: four long-lived collaborators
+ * are built once and handed to the one ViewModel that needs them. Nothing holds a reference
+ * to an Activity, so none of this leaks.
  */
 class FileManagerApplication : Application() {
 
@@ -28,10 +30,15 @@ class FileManagerApplication : Application() {
     lateinit var deleteRequests: DeleteRequestFactory
         private set
 
+    /** Reads whatever another app shares in. */
+    lateinit var incoming: IncomingSource
+        private set
+
     override fun onCreate() {
         super.onCreate()
         storage = StorageProvider(this)
         notifier = ServiceOperationNotifier(this)
         deleteRequests = MediaStoreDeleter(this).factory()
+        incoming = ContentResolverIncomingSource(contentResolver)
     }
 }