init with package-name specified creates Android project in a broken state

[liamjones]

Environment

System:
  OS: macOS 14.2
  CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
  Memory: 31.53 MB / 32.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 21.4.0
    path: /usr/local/bin/node
  Yarn:
    version: 1.22.21
    path: /usr/local/bin/yarn
  npm:
    version: 10.2.5
    path: /usr/local/bin/npm
  Watchman:
    version: 2023.12.04.00
    path: /usr/local/bin/watchman
Managers:
  CocoaPods: Not Found
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.2
      - iOS 17.2
      - macOS 14.2
      - tvOS 17.2
      - watchOS 10.2
  Android SDK: Not Found
IDEs:
  Android Studio: Not Found
  Xcode:
    version: 15.1/15C65
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: javac 21
    path: /Users/liam.jones/.sdkman/candidates/java/current/bin/javac
  Ruby:
    version: 2.6.10
    path: /Users/liam.jones/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.73.0
    wanted: 0.73.0
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: Not found
  newArchEnabled: false

Description

When package-name is specified in init the Android project is setup incorrectly. MainActivity.kt#getMainComponentName() sets the name to the package name rather than the app name. Once the app starts you'll see a LogBox error stating the component hasn't been registered.

Reproducible Demo

npx react-native@latest init AwesomeProject --package-name some.awesome.project --install-pods false
cd AwesomeProject
yarn
yarn android

MainActivity.kt will contain:

override fun getMainComponentName(): String = "some.awesome.project"

But should be:

override fun getMainComponentName(): String = "AwesomeProject"

[liamjones]

A random thought related to this one; would an e2e test for this be possible within the CLI project's CI setup or would it be too complicated to setup?

E.g. run init with a project name + package name, boot both platforms' apps up and check the expected default app UI is present.

[thymikee]

We have tests for e2e init so definitely!

[szymonrybczak]

A random thought related to this one; would an e2e test for this be possible within the CLI project's CI setup or would it be too complicated to setup?

We have for init, but after creating project we're not testing if the app complies - it might a good thing to add!