React Native 0.82 Fetch Issues fetching local file

Description

When trying to fetch a file from the device and turn it into a blob with default fetch shipped within RN 0.82.0, fetch issues a TypeError. Also other methods to fetch the file from the device fail.

The code used for this:

const response = await fetch(image.path)
const blob = await response.blob()

Response:

 Error: Uncaught (in promise, id: 1): "TypeError: Network request failed"

I used to used this throughout all RN versions I previously used and it doesnt work since upgrading from 0.73.6 to 0.82.0.
If I implement it with the formdata approach that I find on multiple sources, the upload succeeds but I get corrupted files.

      const formData = new FormData()

        formData.append('file', {
          type: mime.getType(image.path),
          uri: image.path,
          name: image.fileName,
        });

If I use the XMLHttpRequest approach I get errors as well.

To me it seems something changed regarding to accessing files/uri's on a device, yet I find 0 sources on it.
I changed all necessary permissions to match current latest approach.

I also added a reproducer with all 3 of the methods I described.
You will need an endpoint to upload a file for the reproducer.

Does anybody know what I am doing wrong?

Steps to reproduce

1. install packages
2. start app
3. supply an api url to the fetch methods
4. pick an image
5. press upload image

React Native Version

0.82.0

Affected Platforms

Runtime - Android

Output of npx @react-native-community/cli info

System:
  OS: macOS 15.5
  CPU: (8) arm64 Apple M2
  Memory: 137.97 MB / 8.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 24.6.0
    path: /Users/alexander/.nvm/versions/node/v24.6.0/bin/node
  Yarn:
    version: 1.22.22
    path: /Users/alexander/.nvm/versions/node/v24.6.0/bin/yarn
  npm:
    version: 11.5.1
    path: /Users/alexander/.nvm/versions/node/v24.6.0/bin/npm
  Watchman:
    version: 2024.04.01.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.14.3
    path: /usr/local/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.4
      - iOS 18.4
      - macOS 15.4
      - tvOS 18.4
      - visionOS 2.4
      - watchOS 11.4
  Android SDK:
    API Levels:
      - "31"
      - "33"
      - "34"
      - "35"
      - "36"
    Build Tools:
      - 30.0.3
      - 33.0.0
      - 33.0.1
      - 34.0.0
      - 35.0.0
      - 36.0.0
    System Images:
      - android-34 | Google APIs ARM 64 v8a
    Android NDK: Not Found
IDEs:
  Android Studio: 2024.1 AI-241.18034.62.2411.12169540
  Xcode:
    version: 16.3/16E140
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.10
    path: /usr/bin/javac
  Ruby:
    version: 2.6.10
    path: /usr/bin/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 20.0.0
    wanted: 20.0.0
  react:
    installed: 19.1.1
    wanted: 19.1.1
  react-native:
    installed: 0.82.0
    wanted: 0.82.0
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: true

Stacktrace or Logs

Error: Uncaught (in promise, id: 1): "TypeError: Network request failed"
    at onUnhandled (&platform=android&dev=true&lazy=true&minify=false&app=com.awesomeproject&modulesOnly=false&runModul…:22082:59)
    at onUnhandled (address at InternalBytecode.js:1:3386)Caused by: TypeError: Network request failed
    at anonymous (&platform=android&dev=true&lazy=true&minify=false&app=com.awesomeproject&modulesOnly=false&runModul…:24029:33)

MANDATORY Reproducer

https://github.com/IR-Baboon/reproducer

Screenshots and Videos

No response

Commencez par le reproducer lié et exécutez ses trois méthodes d’upload sur Android avec React Native 0.82.0, en utilisant un endpoint d’upload comme décrit. Comparez le même comportement de fetch avec un fichier local et de blob avec la version signalée 0.73.6. La tâche est terminée lorsque le comportement modifié des URI de fichier a été identifié et qu’il a été confirmé que l’upload de fichiers locaux fonctionne, ou que la limitation prise en charge a été documentée.