Currently, I am getting "Finished with error: Gradle task assembleDebug failed with exit code 1" while trying to build a Flutter project (flutter run). The logs do not help much. Therefore, i want to run "gradlew build" or similar manually with stacktrace option to see what is happening under the hood. What is the command for that ?
For posterity I will post my comment as an answer too and I'll elaborate it a bit.
When you create a flutter project there are two new folders created inside the main folder, one is android and one is ios.
The android folder contains the Android native code and all the android configurations, you can handle it as a native android project.
The ios folder contains the iOS native code and all the ios configurations, it also has the xcworkspace file which can be opened with Xcode like a normal ios project.
Now you can run platform specific commands in each folder, like i said, the folders contain actual native projects.
So for Android you could do:
cd android/
./gradlew clean
./gradlew build
(clean and build the project)
For iOS you could do:
cd ios/
pod repo update
pod install
(update the pod repo and install the pods)
Just a short reminder, if you want to create apk/ipa from the native folders, don't forget to run flutter build in the main folder, otherwise you might get outdated code in your apk/ipa.
Go to the folder where you have gradle installed(the place where your GRADLE_HOME variable points to).
Move inside the wrapper folder
Move inside the dists folder which is inside the wrapper folder
Delete everything that you can find inside the dists folder(cached gradle wrapper)
Run/launch your android flutter project again. It should re-download the gradle wrapper and if you don't have any connection problems your project should run correctly.
Note: I'm having the same problem because of my unstable internet connection. I'm ending up with a corrupted gradle wrapper file and the download doesn't restart.
If the download gets interrupted and fails to completely download and launch your project repeat all of the steps.
Related
I have a jenkins job that is supposed to create a cordova app but it's failing some reason that I can't quite identify. The jenkins job simply does this:
cordova platform add android
cordova prepare android
cordova build android --debug --verbose
The first command (cordova platform add android) is resulting in the following error:
ENOENT: no such file or directory, mkdir 'platforms/android/app/src/main'
Error: ENOENT: no such file or directory, mkdir 'platforms/android/app/src/main'
at Object.mkdirSync (fs.js:738:3)
at Object.module.exports.makeDirSync (/Users/me/Documents/Jenkins/sharedspace/apps/my-app/cordova/node_modules/fs-extra/lib/mkdirs/make-dir.js:23:13)
at /Users/me/Documents/Jenkins/sharedspace/apps/my-app/cordova/node_modules/cordova-android/lib/create.js:231:16
+ /Users/me/.nvm/versions/node/v16.13.2/bin/cordova prepare android
(node:23901) ExperimentalWarning: The fs.promises API is experimental
Discovered platform "android". Adding it to the project
EEXIST: file already exists, mkdir '/Users/me/Documents/Jenkins/sharedspace/apps/my-app/cordova/platforms'
+ /Users/me/.nvm/versions/node/v16.13.2/bin/cordova build android --debug --verbose
(node:23902) ExperimentalWarning: The fs.promises API is experimental
No platforms added to this project. Please use `cordova platform add <platform>`.
CordovaError: No platforms added to this project. Please use `cordova platform add <platform>`.
at Object.preProcessOptions (/Users/me/.nvm/versions/node/v16.13.2/lib/node_modules/cordova/node_modules/cordova-lib/src/cordova/util.js:275:15)
at /Users/me/.nvm/versions/node/v16.13.2/lib/node_modules/cordova/node_modules/cordova-lib/src/cordova/build.js:29:31
at process._tickCallback (internal/process/next_tick.js:68:7)
at Function.Module.runMain (internal/modules/cjs/loader.js:745:11)
at startup (internal/bootstrap/node.js:236:19)
at bootstrapNodeJSCore (internal/bootstrap/node.js:560:3)
Build step 'Execute shell' marked build as failure
When I look inside the platforms directory on the jenkins box it is empty. It is able to create the platforms folder itself, just nothing else under. It doesn't seem to be a permission issue as far as I can tell. If I ssh into the box as the same user that jenkins in using I can run the cordova commands fine and everything works.
Furthermore, if I add the platform manually by sshing into the box and then let jenkins take over after the android folder already exists, the job works fine. So I guess for some reason it's not able to add the android project.
If it helps, this is what cordova requirements gives:
cordova requirements
Requirements check results for android:
Java JDK: installed 1.8.0
Android SDK: installed true
Android target: installed android-30,android-29,android-28
Gradle: installed /usr/local/Cellar/gradle/7.3.3/bin/gradle
Okay, I finally figured this SOB out! After taking a few weeks off and coming back to this I noticed that there is a setting in the job config called "Shared Workspace" and I had it set to the value (). I don't know what that means, but it had the effect of putting the code for this project in the
/Users/me/Documents/Jenkins/sharedspace
folder, which apparently was causing problems with cordova. Once I set the Shared Workspace value to NONE, it moved the project to the
/Users/trident/Documents/Jenkins/workspace/my-app
folder which is more what I would expect. After that, lo and behold, everything works.
I'm working on a Cordova plugin. As a plugin can't be executed, I'm using a Cordova project to test it. I found that running a Cordova project will not reimport and rebuild plugins, so currently I'm doing this:
rmdir \"./plugins/my-plugin\" /q /s
cordova platform remove android
cordova platform add android
cordova run android --device
Did I miss something or Cordova really doesn't have a command to fully rebuild everything before running the project?
Unfortunately, cordova will check your plugins folder only when adding or updating a plugin or platform. Then it will build and copy the needed plugin(s) into the designated OS in the platforms folder.
By your script I assume the source of the plugin is outside of the project folder. So the script you're using should do the work. But if I may give you a better solution would be as follows:
Create a Symlink/shortcut of the source folder for your plugin into the plugins folder, so you'll not need to remove the folder and stress the disk into copying files everytime you want to run the update.
Your "update" script should delete only the installed plugin folder at platforms/android/platform_www/plugins/my-plugin and it'll make the update far more quickier than removing and adding the platform again.
As described here in the Android Studio docs, one can build an Android app from the command line with the gradle wrapper generated by Android Studio. The command line window in Android Studio shows exactly this, i.e. a call to gradlew assembleDebug (or a similar task). However starting a terminal on macOS and calling the gradle wrapper with that exact call sometimes yields other results, i.e. either one is able to build from Android Studio, or the command line, or both (which is ideal, but unfortunately not always true).
Who can explain what other settings the Android Studio IDE sets for their environment and where to find them, how to reproduce these settings easily in a CI environment (e.g. Jenkins, Bamboo, ...) and how one would consistently store these settings in a VCS along an Android project.
In the root of the project you have gradlew.bat, which is how you can run it in the first place. If you open this file, you see the code for building and everything else Gradle does.
Whether you build from the command line or ANdroid Studio, the gradlew.bat file is used. So building and other stuff you do with the gradlew command all use the same file whether it is from the command line or Android Studio's integrated tools.
You can open the file(s, there's gradlew and gradlew.bat in the project root) and see how it works if you wanted too, though these files are usually automatically generated by Android Studio (it is possible to make your own config as well, though there's rarely a need for that). And for including in vcs, make sure the files aren't listed in .gitnore (or whatever vcs ignore extension you have)
Lately I came to know the power of Gradle as a build system and as an Android developer I wanna understand it deeply.
One article said the following:
You can execute all the build tasks available to your Android project using the Gradle wrapper command line tool. It's available as a batch file for Windows (gradlew.bat) and a shell script for Linux and Mac (gradlew.sh), and it's accessible from the root of each project you create with Android Studio.
To run a task with the wrapper, use one of the following commands:
On Windows:
gradlew task-name
Now I have some doubts which goes as follow:
What is Gradle Wrapper and gradlew.bat?
If I've got Android studio installed and it is using gradle to build my apps (so gradle is already installed on my system), do I still need to install gradle for build purpose from command line? As when i write any commend like gradle, gradlew on my command line I get error saying gradlew is not recognized as internal or external command (the same error for other commands). I may be using it on wrong path, help me on what path do I need to use Gradle related command?
If I need to download and install it, how and where can I find the file? And the other processes?
I am using a Windows machine for this.
The Gradle Wrapper is an optional part of the Gradle build system. It consists of four files that you check into version control system. The Unix start script <your root project>/gradlew, the <your root project>/gradlew.bat Windows start script, <your root project>/gradle/wrapper/gradle-wrapper.jar which contains the class files for the wrapper and is started by the start scripts and <your root project>/gradle/wrapper/gradle-wrapper.properties which contains some configuration for the wrapper, for example which Gradle version to use to build the project.
In my opinion, each and every Gradle project, even the tiniest, should make use of the Gradle wrapper.
The Gradle wrapper makes sure your build is always run with the same Gradle version, no matter who executes the build and where or that Gradle is installed or not, as long as the one uses the Gradle wrapper to build the project. This means you can design your build for that Gradle version and be sure that the build will not fail, just because someone is using a different version of Gradle and thus is also an important step in build reproducibility.
Also, someone wishing to build your project only needs to have Java installed and that's it. He does not need to have any Gradle version installed. Actually any already installed Gradle version is ignored. The Gradle wrapper checks whether in ~/.gradle/ the version that is necessary for the build is already present, because some Gradle wrapper of any project put it there already. If it is present already, it is used, otherwise it is automatically downloaded.
If you type gradlew on the commandline and the command is not found, that means you didn't put your root projects path to the PATH environment variable (I wouldn't recommend doing that either), nor are you currently in your root project's directory. To run a Gradle build, you have to be anywhere inside your project and call Gradle or the Gradle wrapper. But like with any executable file that is not on the path, you have to provide its path of course. So if you are in your root project directory, you can simply do gradlew. if you are in <root project dir>/foo/bar/, you would need to call ../../gradlew.
The Gradle Wrapper files are generated by the implicitly available Gradle task wrapper and then get checked into the VCS of the project in question. If those four files are not present for a project, it does not use the Gradle wrapper and you should post an improvement request to the project to add it.
If some project does not use the Gradle wrapper, but builds with Gradle, you can either install Gradle and use gradle instead of gradlew, or you can even call the Gradle wrapper of any other project that you have available on disk. The build will then be run with the Gradle version that wrapper or Gradle installation is using and thus might not behave as expected, which is why really each and every project should use the wrapper if it uses Gradle.
Edited after comments
Gradle is a build system.
This gradle-wrapper is kind of the primary interface to to build Android projects. It the part of Gradle-build-system and does some primary check if gradle in installed or not.
gradlew.bat - its a batch file used on Windows. You can even open it with a notepad to view the instructions in it. Batch files are like 'commands' written in a file to be executed. You use it (in case of Windows) to execute build commands. It also checks if gradle is installed or not. And in case it is not, it downloads and installs it.
Example : to build android app on Windows:
Open command prompt
Navigate to your project's root directory
execute gradlew.bat assembleDebug
It starts the wrapper, checks if Gradle is installed there and
executes all the 'gradle specific' commands to build your project.
Do you need to install Gradle ?
Actually, no. Its the job of this gradlew script to check for that. If gradle its not already there, it would automatically download it and use it for all later builds.
gradlew.bat IS the Gradle Wrapper (for Windows in this case). Gradle Wrapper is just a small utility that will ensure that Gradle is installed (or install it if necessary) so you can always build the project. Gradle itself allows you to manage dependencies and build configurations for your project.
If you have installed Android Studio, you have Gradle installed and are good to go. (Technically, each project will have it's own wrapper to handle installing/using Gradle)
As I mentioned above, you are good to go.
In the end Gradle is a command line tool that you use to build your project and you could very well use that directly (though you don't have to) since it is exactly what Android Studio uses to build your project.
How can I stop cordova from trying to copy my www/node_modules folder to platforms/{android/iOS}/www the when doing a build command like this:
cordova build android
This seems like a relatively straight forward thing that everybody would want to do, but everything I have found does not seem to work.
This is particularly an issue when doing a build for android as something in my node folder is causing the build to fail.
I am hoping there is a way to leverage the config.xml file for this.
Don't include node_modules in /www. It should be one level up. My guess is that you initialized your npm project from the incorrect directory.
Have your build process that needs node_modules for Grunt and Bower run in some other folder in your project, one that is at the same level in the folder hierarchy as www perhaps. Then at the end of your build process, have the build tools copy the built artifacts into www before kicking off cordova build <platform name>.