I recently had to purge a whole bunch of assets from a Flutter Android project because the resulting aab is over 150mb.
This worked for one configuration. For another configuration all the files that were deleted are magically in the build. The files do not physically exist in the repository, or on disk, or in the project.
A colleague of mine ran the exact same flutter appbuild command with the same parameters and got the correct build with the correct assets.
I've done flutter clean thousands of times trying to get the dependencies to work so it's not a case of running flutter clean.
Where is the build getting these files from?
Related
I've recently upgraded my react-native app to version 0.60.5, as to fulfil App Store requirement of 64-bit app, but I've noticed that the executionHistory.bin file inside android/.gradle/x.x.x/executionHistory got really big, going from ~6Mb, to ~100Mb, which is a real pain as GitHub won't allow files larger than 100Mb to be uploaded. I searched a way to clean the file, delete it and recreate it but really haven't found much. I want to know how to solve this issue, if I screw up upgrading my rn version or something.
Specs:
OS:
macOS Catalina
version: 10.15.1
React-Native: 0.60.5
The .gradle directory should be added to the .gitignore. There is no need to have this in version control as it is just used to store some build cache and various things that get re-generated when gradle builds.
My suggestion... Delete the .gradle directory locally and from your git repo (it will regenerate next time you build android). Then add it to your .gitignore.
See here for the recommended ignore file for react-native (created by react-native):
https://github.com/facebook/react-native/blob/master/template/_gitignore
Just in case you are having this issue AFTER committing and pushing...
I just realized I had this issue when cloning a large repo (~470MB).
I used https://github.com/newren/git-filter-repo to inspect large objects that were bloating the git history, and found executionHistory.bin, node_modules and all kinds of other shit that should never have been checked in the first place.
I made a list of files a directories to delete from history and added them in a file to_delete.txt, in the directory one level above my repo:
# Files and directories to delete
android/.gradle
node_modules
...
And then:
git filter-repo --invert-paths --paths-from-file ../to_delete.txt --force
Note the --force option, because I was getting wrong warnings about my repo not being a fresh clone.
After this, my repo size is just above 6MB, which makes much more sense for the small-ish project that it is 🎉🤩🥳
Hope this helps!
I'm importing from Bitbucket and am experiencing the issue. There are also no run configurations available. Do any Android gurus have an idea?
Thank you
-T
edit run config:
Different views will show and group your project files differently in Android Studio and IntelliJ IDEs. I think if you choose "Files", you will see all project files, and the actual directories in which they exist.
If this is a project you downloaded from bitbucket, you will most likely have to build the project yourself, and that is why you only see gradle scripts in the project view. You will also most likely have to create your own Run configurations.
Developers usually only upload the source files-- it's up to the end users downloading the project to build it themselves to generate the build files.
You could try creating and running your own "Android" Run configuration, and see where the build breaks, patch the current build failure + rerun. Rinse and repeat. Sorry for the bad news-- I've been frustrated in the past getting Android projects from github running for the same reasons.
I have used clean project a few times after breaking my tutorial app. I did this by doing a refactor or some other fancy command on a variable. I don't actually know what android studio is doing in the background and I am wondering if anyone can give a good detailed answer in simple English. :)
Thank you in advance,
Simple answer it Deletes the build directory
It removes whatever already-compiled files are in your project meaning it removes the .class files and recompiles the project again.
Source is here : https://www.jetbrains.com/help/idea/2016.3/cleaning-system-cache.html?search=clean
If you want to have some fun by cleaning yourself
Open your project path using cmd
(go to project path and type cmd and hit enter like below)
Then use command gradlew clean and hit enter and see what happens when it cleans
For other tasks and meet your project's Mr.Gradle use command gradlew help
Clean action, basically invoking ./gradle clean task in your application directory, which is removing all generated files, removes build folders. So basically next time you will run/build all the artifacts will be builded from the scratch and will not be reused.
More information you can find on a official gradle site
Information about android plugin
DSL reference for Android plugin
Cleaning the project removes all build artifacts (ex: deleting the app/build folder)
I don't know what it does. But I would like to share my experience that is worth to know.
I was having one Android Studio project in which I was managing two projects through buildTypes(Lets name them project A and B).
I was previously working with project A. Now I need to work on project B. So I made necessary changes and implemented the functionality. My next task was to generate the signed APK. I generated the signed APK with the keystore of appropriate project that is project B.
But the generated signed APK was showing the SHA1 of the keystore of project A. and Google play store was not allowing me to upload the apk with different keystore. I checked it 5 to 6 times and generated signed APK and failed every time.
After 3 to 4 hours I gave one try to clean project as any other solution was not working for me and Voila now it signed the apk with correct keystore.
So clean and rebuild the project before generating the signed APK is a best practice mainly If you are working with different buildTypes
Cleaning an Android project simply deletes the build directory. It removes the .class files that are generated when you compile your project and then recompiles again. As per my experience, whenever I move my Android Studio project folder in another location in same or different hard drive, it gives an error while running the project. In that case, cleaning the project helps eliminating the errors by re-building the project from scratch and to run successfully.
To clear a project in Studio, go to Build > Clean Project. Done.
When i ran Gradle task via Android Studio' GUI (using IDE‘s own Gradle distribution), no dependencies need to download. But after that, when i did the same via terminal the first time, it would download some dependencies, for example, "lint" . Is it normal ? I don't want to cache two duplicated dependencies.
I don't want to cache two duplicated dependencies.
Gradle (and Maven) dependencies are only contained within your user home folder, in .gradle and .m2 respectively. Unless you have modified those files otherwise, of course.
Gradle just happens to be included in Android Studio. If you are able to run Gradle independently in the terminal, then you have two installations of Gradle.
The gradle wrapper would be downloaded separately of the local system installation.
for example, "lint"
Lint shouldn't be downloading anything. It only inspects your code for errors and warnings.
we are using Hudson for CI of an Android project with Android emulator plugin to run UI tests on the emulator. A git project delivers the source code.
Now I see that in the git repo, for each build a logcat file is created and put in the git project folder, which is then pushed back to git. As we are expecting a lot of builds, this could easily spam the project folder. Does anyone know if it is possible to set the destination folder for the emulator logs?
I cannot find any options in the emulator plugin or Hudson anywhere.
The logcat files are named logcat_[some_number].log.
Best regards,
Kim
Upgrade to version 2.0 of the plugin (or newer) and you'll see these logcat files are now written to a temporary directory, rather than your workspace.
If you're using Hudson, possibly you only see the very old version 1.6 in the Update Centre.
Which is just another reason to upgrade to Jenkins! :)
However, if you can't upgrade either the plugin or Jenkins (for some weird reason), just use an "Execute shell" step to delete any logcat_*.log files at the start of each build.
These files are purely temporary anyway and should probably only exist in your workspace after a failed build — otherwise the logcat output is archived automatically as logcat.txt.
Add an ant task to rename the logcat file to your convenience and remove the oldest ones.
add the logs to the .gitignore file, if you want to exclude them from your repository.