PlatformColor crashes on android if resource colour is supplied

[hurali97]

Description

While testing for 0.72.x patch, Android is crashing when tapped on Border example. I narrowed it down to one point which was causing the crash. As seen in the attached screenshots, PlatformColor when passed android resource color returns a map which conflicts from the expected Int type.

  border15: {
    borderWidth: 10,
    borderColor: Platform.select({
      ios: PlatformColor('systemGray4'),
      android: PlatformColor('@android:color/holo_orange_dark'),
      windows: PlatformColor('SystemAccentColorDark1'),
      default: 'black',
    }),
  },

react-native/packages/rn-tester/js/examples/Border/BorderExample.js

Line 188 in fe804b8

android: PlatformColor('@android:color/holo_orange_dark'),

Tracked it back to 0.71-stable branch and the issue is there too.

React Native Version

0.72-stable

Output of npx react-native info

System:
OS: macOS 13.4.1
CPU: (10) arm64 Apple M1 Pro
Memory: 111.59 MB / 16.00 GB
Shell:
version: "5.9"
Binaries:
Node:
version: 18.17.1
Yarn:
version: 1.22.19
npm:
version: 9.6.7
Watchman:
version: 2023.06.08.00
Managers:
CocoaPods:
version: 1.12.1
IDEs:
Android Studio: 2022.1 AI-221.6008.13.2211.9514443

Steps to reproduce

• Checkout to 0.71-stable or 0.72-stable
• Run yarn install
• Run yarn test-e2e-local -t RNTester -p Android -h true -c CCIPAT_asd

Snack, screenshot, or link to a repository

[github-actions]

⚠️	Missing Reproducible Example
ℹ️	We could not detect a reproducible example in your issue report. Please provide either: If your bug is UI related: a Snack If your bug is build/update related: use our Reproducer Template. A reproducer needs to be in a GitHub repository under your username.

[github-actions]

⚠️	Add or Reformat Version Info
ℹ️	We could not find or parse the version number of React Native in your issue report. Please use the template, and report your version including major, minor, and patch numbers - e.g. 0.70.2

[mateoguzmana]

This doesn't happen anymore in 0.76.4. Seems like it got fixed by #39893.