Nativescript-cli: Cannot change android package id via package.json

[tjvantoll]

From https://github.com/NativeScript/docs/pull/496.

1) Create a NativeScript app.
2) Run it on Android.
3) Change the nativescript.id in your package.json file.
4) rm -rf platforms
5) tns install
6) tns run android --emulator

Expected: The package in the Android app’s manifest will be updated to the new value.
Actual: No update occurs.

It seems that once an App_Resources/Android/app.gradle file exists, you must change your application id there rather than in package.json. But that goes against what our documentation says.

Where is the right place to change this value? We either need to update the CLI or the docs, and I’m not sure which.

Thanks.

[tjvantoll]

I’ll note that my vote is for nativescript.id to go away in the package.json file. I’d rather just update that value in App_Resources/Android/app.gradle and App_Resources/iOS/Info.plist personally.

[rosen-vladimirov]

I vote for keep using one value (in package.json) and populate it in the native project. I've not tried the steps provided by @tjvantoll , but updating the file in app/App_Resources/Android/app.gradle seems incorrect for me. All placeholders should be replaced in the native project, not in the app directory. Here's the code that modifies the app.gradle.
However the user may not notice the app.gradle and modify the package.json (as @tjvantoll tried to do) and the appid will not be respected. This will make the run, livesync and all other commands working with device useless as they are unable to determine application state on device (the commands read the appid from package.json). Also we may end-up with three different application identifiers:

• one in package.json
• another one in app/App_Resources/Android/app.gradle
• another one in app/App_Resources/Android/AndroidManifest.xml

For beginner users this will be really difficult to understand, so I vote to keep the id in package.json and make sure CLI works correctly with the id in different files.

[Plamen5kov]

We can introduce logic that replaces the app_id from the package.json to app.gradle and AndroidManifest.xml, but for android that might introduce some unexpected behavior since these values can be different in a native project, and the one in the AndroidManifest.xml is the one responsible for what is the application name on the device, and the one in app.gradle is responsible for the publishing in app store. If we force these two values to be the same, we loose functionality that is otherwise present on the native platform.
IMO since this is a native configuration, it should be separated from the common part. This is the point of the app.gradle file - to present the user with a way to configure the native project.

[dtopuzov]

Not sure if users (specially web developer we target) will be happy to manually edit app.gradle

[atanasovg]

We can't make a whole new abstraction by a common denominator over two totally different platforms in a sustainable and non-error-prone way. And when/if Windows come in the equation then it would become even harder to achieve so. Sometimes native just isn't evil, on the contrary - it provides better control and less confusion. It is our responsibility to _educate_ our users on the why in such cases. And we should not be afraid to choose native paradigms as long as they provide better mechanism for handling such cases.

That's my thinking. For example we are still experiencing significant issues because of the way we handle Android plugins. Instead of pushing plugin authors to use the native platform approach (*.AAR packages), we literally augment the platform and add plugins to a project through flavors. And flavors are meant to handle completely different cases. And what was the major reason behind this solution? People were afraid of building AAR packages. Why? Because, for some reason, we failed to explain why these are better sustainable in the long run and will be less error prone. And because our thinking is _"native is a bad thing, make an abstraction"_.

[PanayotCankov]

Can't we read the id from the Info.plist for iOS and the AndroidManifest.xml for android, instead of reading the package.json?

[Plamen5kov]

Currently CLI reads the id from package.json and interpolates the name into the AndroidManifest.xml and Info.plist. And as I understand the question, the problem is changing the package id, not reading it.

[EricRobertBrewer]

I tested this functionality, but I can't seem to get the iOS app to read its CFBundleIdentifier in Info.plist. It currently gets clobbered by nativescript.id in package.json.

(I'm expecting to see com.company.ios above).

I added CFBundleIdentifier here according to TJ VanToll's SO answer.

When I try to remove nativescript.id, the project doesn't run:

iOS:

Project successfully built
Segmentation fault: 11

Android:

Project successfully built
No .apk found in /Users/ericbrewer/Documents/Personal/NativeScript/package-test/platforms/android/build/outputs/apk directory

Am I missing some setting?

[Plamen5kov]

We need an iOS expert here: ping @PanayotCankov

[rosen-vladimirov]

These are two different issues here:
1) During project creation CLI sets app id directly in app/App_Resources/app.gradle, so any additional changes in package.json will not be respected (for Android only).
2) During every prepare of iOS platform, CLI replaces the bundle identifier in platforms/ios/<project_name>/*.plist with the id in package.json and disregards value in app/App_Resources/ios/Info.plist.

[Plamen5kov]

I vote for removing the app_id from the package.json, because it's error prone, plus we already have a native configuration specific for each platform.
Given we provide a good default behavior and it's documented well, I don't see the novice users making unwilling mistakes, and for the advanced users we have documentation describing how the native configuration is augmented or changed.
IMO in our current state, we neither have one decent abstraction, nor do we guide the users to properly using the native configuration we've exposed.

[Plamen5kov]

closing in favor of: https://github.com/NativeScript/nativescript-cli/issues/2367

[iamabs2001]

I vote for keep using one value (in package.json) and populate it in the native project. I've not tried the steps provided by @tjvantoll , but updating the file in app/App_Resources/Android/app.gradle seems incorrect for me. All placeholders should be replaced in the native project, not in the app directory. Here's the code that modifies the app.gradle.
However the user may not notice the app.gradle and modify the package.json (as @tjvantoll tried to do) and the appid will not be respected. This will make the run, livesync and all other commands working with device useless as they are unable to determine application state on device (the commands read the appid from package.json). Also we may end-up with three different application identifiers:

• one in package.json
• another one in app/App_Resources/Android/app.gradle
• another one in app/App_Resources/Android/AndroidManifest.xml

For beginner users this will be really difficult to understand, so I vote to keep the id in package.json and make sure CLI works correctly with the id in different files.

safe doing manually ?