Exclude temporary Realm files from Gradle build












7















Realm provides a database viewer called "Realm Studio" that allows users to browse the contents of their database. When the application is used to view a database, it creates several "temporary" files in the directory of the database, namely:




  • A .realm.lock file.

  • A .realm.note file.

  • A .realm.management directory containing:


    • A access_control.control.mx file.

    • A access_control.new_commit.cv file.

    • A access_control.pick_writer.cv file.

    • A access_control.write.mx file.




In the context of Android, a preexisting Realm database is sometimes shipped with an application by placing the database in the /assets directory. Thus, when the Realm Studio is used to view this database, the aforementioned files are generated in /assets. For unknown reasons, this causes Gradle to hang indefinitely after the :app:generateDebugAssets task, apparently at the :app:mergeDebugAssets task.



As such, i'd like to find a way to exclude these files from the build. I've tried several methods, such as:



applicationVariants.all { variant ->
if (variant.buildType.name == 'debug') {
variant.mergeAssets.doLast {
delete(fileTree(dir: variant.mergeAssets.outputDir, includes: ['**/*.cv', '**/*.mx', '**/*.lock', '**/*.note']))
}
}
}


and other methods, like:



sourceSets.main.assets.exclude 'appData.realm.management'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.control.mx'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.new_commit.cv'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.pick_writer.cv'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.write.mx'
sourceSets.main.assets.exclude 'appData.realm.lock'
sourceSets.main.assets.exclude 'appData.realm.note'


to no avail.



How can one instruct Gradle to exclude these files when running a build?



EDIT: Small snippet of repeated output from ./gradlew -d app:mergeDebugAssets:



[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2572066816}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2572066816}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2567909376}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2567909376}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2564087808}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2564087808}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2560860160}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2560860160}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
...









share|improve this question

























  • None of the above solution works ? Any error message ?

    – ToYonos
    Dec 5 '18 at 10:01
















7















Realm provides a database viewer called "Realm Studio" that allows users to browse the contents of their database. When the application is used to view a database, it creates several "temporary" files in the directory of the database, namely:




  • A .realm.lock file.

  • A .realm.note file.

  • A .realm.management directory containing:


    • A access_control.control.mx file.

    • A access_control.new_commit.cv file.

    • A access_control.pick_writer.cv file.

    • A access_control.write.mx file.




In the context of Android, a preexisting Realm database is sometimes shipped with an application by placing the database in the /assets directory. Thus, when the Realm Studio is used to view this database, the aforementioned files are generated in /assets. For unknown reasons, this causes Gradle to hang indefinitely after the :app:generateDebugAssets task, apparently at the :app:mergeDebugAssets task.



As such, i'd like to find a way to exclude these files from the build. I've tried several methods, such as:



applicationVariants.all { variant ->
if (variant.buildType.name == 'debug') {
variant.mergeAssets.doLast {
delete(fileTree(dir: variant.mergeAssets.outputDir, includes: ['**/*.cv', '**/*.mx', '**/*.lock', '**/*.note']))
}
}
}


and other methods, like:



sourceSets.main.assets.exclude 'appData.realm.management'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.control.mx'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.new_commit.cv'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.pick_writer.cv'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.write.mx'
sourceSets.main.assets.exclude 'appData.realm.lock'
sourceSets.main.assets.exclude 'appData.realm.note'


to no avail.



How can one instruct Gradle to exclude these files when running a build?



EDIT: Small snippet of repeated output from ./gradlew -d app:mergeDebugAssets:



[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2572066816}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2572066816}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2567909376}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2567909376}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2564087808}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2564087808}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2560860160}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2560860160}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
...









share|improve this question

























  • None of the above solution works ? Any error message ?

    – ToYonos
    Dec 5 '18 at 10:01














7












7








7








Realm provides a database viewer called "Realm Studio" that allows users to browse the contents of their database. When the application is used to view a database, it creates several "temporary" files in the directory of the database, namely:




  • A .realm.lock file.

  • A .realm.note file.

  • A .realm.management directory containing:


    • A access_control.control.mx file.

    • A access_control.new_commit.cv file.

    • A access_control.pick_writer.cv file.

    • A access_control.write.mx file.




In the context of Android, a preexisting Realm database is sometimes shipped with an application by placing the database in the /assets directory. Thus, when the Realm Studio is used to view this database, the aforementioned files are generated in /assets. For unknown reasons, this causes Gradle to hang indefinitely after the :app:generateDebugAssets task, apparently at the :app:mergeDebugAssets task.



As such, i'd like to find a way to exclude these files from the build. I've tried several methods, such as:



applicationVariants.all { variant ->
if (variant.buildType.name == 'debug') {
variant.mergeAssets.doLast {
delete(fileTree(dir: variant.mergeAssets.outputDir, includes: ['**/*.cv', '**/*.mx', '**/*.lock', '**/*.note']))
}
}
}


and other methods, like:



sourceSets.main.assets.exclude 'appData.realm.management'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.control.mx'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.new_commit.cv'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.pick_writer.cv'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.write.mx'
sourceSets.main.assets.exclude 'appData.realm.lock'
sourceSets.main.assets.exclude 'appData.realm.note'


to no avail.



How can one instruct Gradle to exclude these files when running a build?



EDIT: Small snippet of repeated output from ./gradlew -d app:mergeDebugAssets:



[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2572066816}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2572066816}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2567909376}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2567909376}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2564087808}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2564087808}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2560860160}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2560860160}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
...









share|improve this question
















Realm provides a database viewer called "Realm Studio" that allows users to browse the contents of their database. When the application is used to view a database, it creates several "temporary" files in the directory of the database, namely:




  • A .realm.lock file.

  • A .realm.note file.

  • A .realm.management directory containing:


    • A access_control.control.mx file.

    • A access_control.new_commit.cv file.

    • A access_control.pick_writer.cv file.

    • A access_control.write.mx file.




In the context of Android, a preexisting Realm database is sometimes shipped with an application by placing the database in the /assets directory. Thus, when the Realm Studio is used to view this database, the aforementioned files are generated in /assets. For unknown reasons, this causes Gradle to hang indefinitely after the :app:generateDebugAssets task, apparently at the :app:mergeDebugAssets task.



As such, i'd like to find a way to exclude these files from the build. I've tried several methods, such as:



applicationVariants.all { variant ->
if (variant.buildType.name == 'debug') {
variant.mergeAssets.doLast {
delete(fileTree(dir: variant.mergeAssets.outputDir, includes: ['**/*.cv', '**/*.mx', '**/*.lock', '**/*.note']))
}
}
}


and other methods, like:



sourceSets.main.assets.exclude 'appData.realm.management'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.control.mx'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.new_commit.cv'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.pick_writer.cv'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.write.mx'
sourceSets.main.assets.exclude 'appData.realm.lock'
sourceSets.main.assets.exclude 'appData.realm.note'


to no avail.



How can one instruct Gradle to exclude these files when running a build?



EDIT: Small snippet of repeated output from ./gradlew -d app:mergeDebugAssets:



[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2572066816}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2572066816}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2567909376}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2567909376}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2564087808}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2564087808}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2560860160}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2560860160}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
...






android gradle android-gradle realm build.gradle






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 17 '18 at 22:52







Orbit

















asked Nov 27 '18 at 0:02









OrbitOrbit

67832562




67832562













  • None of the above solution works ? Any error message ?

    – ToYonos
    Dec 5 '18 at 10:01



















  • None of the above solution works ? Any error message ?

    – ToYonos
    Dec 5 '18 at 10:01

















None of the above solution works ? Any error message ?

– ToYonos
Dec 5 '18 at 10:01





None of the above solution works ? Any error message ?

– ToYonos
Dec 5 '18 at 10:01












3 Answers
3






active

oldest

votes


















5





+100









I think the problem is that you did not delete the .realm.management directory.



android {

...

applicationVariants.all { variant ->
if (variant.buildType.name == 'debug') {
variant.mergeAssets.doLast {
delete(fileTree(dir: variant.mergeAssets.outputDir, includes: ['**/.realm.management', '**/*.lock', '**/*.note']))
}
}
}
}


assets directory contents:



enter image description here



assets directory contents in apk:



enter image description here






share|improve this answer


























  • this looks almost alike the approach already presented along with the question.

    – Martin Zeitler
    Dec 12 '18 at 12:13











  • @MartinZeitler: Yes, you are right. I've added '**/.realm.management' to be deleted.

    – aminography
    Dec 12 '18 at 12:15













  • the basic issue might be conflicting exclusive file access. I might be wrong (concerning aapt & assets), but would assume that empty directories are in general not being packaged.

    – Martin Zeitler
    Dec 12 '18 at 12:31













  • @aminography I noticed that your .realm.management directory in the screenshot provided is not prefixed with "appData", i.e. appData.realm.management/. Did this solution work for you? It did not appear to resolve the issue.

    – Orbit
    Dec 17 '18 at 21:35











  • @aminography almost have to up-vote this, for providing the screenshot of the assets directory, which enabled my to write that cleanupRealm task. else I would not have known what to write.

    – Martin Zeitler
    Dec 17 '18 at 22:56





















5














guess you might be using an elder version of Realm Studio,
because according to issue #842 and pull request #847, those directories should meanwhile be properly cleaned up - and also report, in case not - instead of stalling. the current version 3.12 should have that fixed (basically any release after the 18th of June). if that should not help, the best you can do is to report it below issue #842; or file a new one issue, which is referencing issue #842. also check the file-system permissions, that the user which runs gradle is permitted to delete there; manually moving files out of the way "might" help, so the current user may re-create them and then subsequently is able to delete his own files.



both methods using gradle are workarounds - because it should not happen in the first place.



in order to obtain further information "why it stalls", run this command in the terminal:



./gradlew -d app:generateDebugAssets


respectively on Windows (the question does neither indicate the OS nor the Realm Studio version):



gradlew.bat -d app:generateDebugAssets


edit: one could even delete these files before each build:



task cleanupRealm(type: Delete) {
delete project.projectDir.path + "/src/main/assets/.realm.management"
delete project.projectDir.path + "/src/main/assets/appData.realm.lock"
delete project.projectDir.path + "/src/main/assets/appData.realm.note"
}

tasks.whenTaskAdded { task ->
if (task.name == "preDebugBuild" || task.name == "preReleaseBuild") {
task.dependsOn cleanupRealm
}
}


which changes the task graph to:



:app:checkDebugClasspath
:app:cleanupRealm
:app:preBuild
:app:preDebugBuild





share|improve this answer


























  • I believe the description and code shown in the linked PRs has to do with Electron's renderer process and relative files containing a renderer- pattern, as they don't appear to be related to this issue. I am running the latest release of Realm Studio. Your suggestion to manually run the task was great, as app:generateDebugAssets completes successfully. :app:generateDebugAssets UP-TO-DATE had been the last thing printed while building in Android Studio, however the real culprit appears to be :app:mergeDebugAssets, which repeatedly prints logs regarding the daemon addresses registry.

    – Orbit
    Dec 17 '18 at 21:48













  • @Orbit and when you'd run ./gradlew -d :app:mergeDebugAssets? it might be waiting to get access to a shared lock, which it does not get ...

    – Martin Zeitler
    Dec 17 '18 at 22:28













  • The task hangs at 75%. I'll add a small snippet of the output that gets repeatedly logged at that point, as the full output is quite large, to the original post. Note that ./gradlew -s app:mergeDebugAssets shows no exceptions. Also, note that without these "temporary" Realm files, this task usually completes within a few seconds.

    – Orbit
    Dec 17 '18 at 22:47











  • @Orbit just added the task which creates this situation. it's not tested, because I don't have these files - but at least the task is added properly, has the correct type and I'm convinced that only the paths might vary. nevertheless it could fail, when any of these files is opened with an exclusive lock.

    – Martin Zeitler
    Dec 17 '18 at 23:01













  • Your cleanupRealm task works great, though i've changed the call to use delete project.projectDir.path instead. This deletes these temporary files on every Gradle sync and every build. Any idea as to why the issue with mergeDebugAssets was occuring? Is there a way to simply have the build ignore these files instead of deleting them?

    – Orbit
    Dec 17 '18 at 23:12



















4














Try that :



android {
aaptOptions {
ignoreAssetsPattern "!*.cv:!*.mx:!*.lock:!*.note"
}
}


From aapt binary from build-tools folder :



./aapt
[...]
--ignore-assets
Assets to be ignored. Default pattern is:
!.svn:!.git:!.ds_store:!*.scc:.*:<dir>_*:!CVS:!thumbs.db:!picasa.ini:!*~





share|improve this answer


























  • Where should the aaptOptions block go? Both options I tried (inside android {} and another in android { buildTypes {} }) did not appear to solve the issue.

    – Orbit
    Dec 11 '18 at 22:20











  • Yes it's in the android block. It does not work at all ?

    – ToYonos
    Dec 12 '18 at 0:49











  • ignoreAssetsPattern = ignoreAssetsPattern + "..." would add instead of replace.

    – Martin Zeitler
    Dec 12 '18 at 12:14











  • @ToYonos Correct, it does not appear to resolve the issue. Note that before setting ignoreAssetsPattern, ignoreAssets and ignoreAssetsPattern are both null.

    – Orbit
    Dec 17 '18 at 22:14











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53490891%2fexclude-temporary-realm-files-from-gradle-build%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes









5





+100









I think the problem is that you did not delete the .realm.management directory.



android {

...

applicationVariants.all { variant ->
if (variant.buildType.name == 'debug') {
variant.mergeAssets.doLast {
delete(fileTree(dir: variant.mergeAssets.outputDir, includes: ['**/.realm.management', '**/*.lock', '**/*.note']))
}
}
}
}


assets directory contents:



enter image description here



assets directory contents in apk:



enter image description here






share|improve this answer


























  • this looks almost alike the approach already presented along with the question.

    – Martin Zeitler
    Dec 12 '18 at 12:13











  • @MartinZeitler: Yes, you are right. I've added '**/.realm.management' to be deleted.

    – aminography
    Dec 12 '18 at 12:15













  • the basic issue might be conflicting exclusive file access. I might be wrong (concerning aapt & assets), but would assume that empty directories are in general not being packaged.

    – Martin Zeitler
    Dec 12 '18 at 12:31













  • @aminography I noticed that your .realm.management directory in the screenshot provided is not prefixed with "appData", i.e. appData.realm.management/. Did this solution work for you? It did not appear to resolve the issue.

    – Orbit
    Dec 17 '18 at 21:35











  • @aminography almost have to up-vote this, for providing the screenshot of the assets directory, which enabled my to write that cleanupRealm task. else I would not have known what to write.

    – Martin Zeitler
    Dec 17 '18 at 22:56


















5





+100









I think the problem is that you did not delete the .realm.management directory.



android {

...

applicationVariants.all { variant ->
if (variant.buildType.name == 'debug') {
variant.mergeAssets.doLast {
delete(fileTree(dir: variant.mergeAssets.outputDir, includes: ['**/.realm.management', '**/*.lock', '**/*.note']))
}
}
}
}


assets directory contents:



enter image description here



assets directory contents in apk:



enter image description here






share|improve this answer


























  • this looks almost alike the approach already presented along with the question.

    – Martin Zeitler
    Dec 12 '18 at 12:13











  • @MartinZeitler: Yes, you are right. I've added '**/.realm.management' to be deleted.

    – aminography
    Dec 12 '18 at 12:15













  • the basic issue might be conflicting exclusive file access. I might be wrong (concerning aapt & assets), but would assume that empty directories are in general not being packaged.

    – Martin Zeitler
    Dec 12 '18 at 12:31













  • @aminography I noticed that your .realm.management directory in the screenshot provided is not prefixed with "appData", i.e. appData.realm.management/. Did this solution work for you? It did not appear to resolve the issue.

    – Orbit
    Dec 17 '18 at 21:35











  • @aminography almost have to up-vote this, for providing the screenshot of the assets directory, which enabled my to write that cleanupRealm task. else I would not have known what to write.

    – Martin Zeitler
    Dec 17 '18 at 22:56
















5





+100







5





+100



5




+100





I think the problem is that you did not delete the .realm.management directory.



android {

...

applicationVariants.all { variant ->
if (variant.buildType.name == 'debug') {
variant.mergeAssets.doLast {
delete(fileTree(dir: variant.mergeAssets.outputDir, includes: ['**/.realm.management', '**/*.lock', '**/*.note']))
}
}
}
}


assets directory contents:



enter image description here



assets directory contents in apk:



enter image description here






share|improve this answer















I think the problem is that you did not delete the .realm.management directory.



android {

...

applicationVariants.all { variant ->
if (variant.buildType.name == 'debug') {
variant.mergeAssets.doLast {
delete(fileTree(dir: variant.mergeAssets.outputDir, includes: ['**/.realm.management', '**/*.lock', '**/*.note']))
}
}
}
}


assets directory contents:



enter image description here



assets directory contents in apk:



enter image description here







share|improve this answer














share|improve this answer



share|improve this answer








edited Dec 12 '18 at 12:10

























answered Dec 12 '18 at 11:30









aminographyaminography

6,26521533




6,26521533













  • this looks almost alike the approach already presented along with the question.

    – Martin Zeitler
    Dec 12 '18 at 12:13











  • @MartinZeitler: Yes, you are right. I've added '**/.realm.management' to be deleted.

    – aminography
    Dec 12 '18 at 12:15













  • the basic issue might be conflicting exclusive file access. I might be wrong (concerning aapt & assets), but would assume that empty directories are in general not being packaged.

    – Martin Zeitler
    Dec 12 '18 at 12:31













  • @aminography I noticed that your .realm.management directory in the screenshot provided is not prefixed with "appData", i.e. appData.realm.management/. Did this solution work for you? It did not appear to resolve the issue.

    – Orbit
    Dec 17 '18 at 21:35











  • @aminography almost have to up-vote this, for providing the screenshot of the assets directory, which enabled my to write that cleanupRealm task. else I would not have known what to write.

    – Martin Zeitler
    Dec 17 '18 at 22:56





















  • this looks almost alike the approach already presented along with the question.

    – Martin Zeitler
    Dec 12 '18 at 12:13











  • @MartinZeitler: Yes, you are right. I've added '**/.realm.management' to be deleted.

    – aminography
    Dec 12 '18 at 12:15













  • the basic issue might be conflicting exclusive file access. I might be wrong (concerning aapt & assets), but would assume that empty directories are in general not being packaged.

    – Martin Zeitler
    Dec 12 '18 at 12:31













  • @aminography I noticed that your .realm.management directory in the screenshot provided is not prefixed with "appData", i.e. appData.realm.management/. Did this solution work for you? It did not appear to resolve the issue.

    – Orbit
    Dec 17 '18 at 21:35











  • @aminography almost have to up-vote this, for providing the screenshot of the assets directory, which enabled my to write that cleanupRealm task. else I would not have known what to write.

    – Martin Zeitler
    Dec 17 '18 at 22:56



















this looks almost alike the approach already presented along with the question.

– Martin Zeitler
Dec 12 '18 at 12:13





this looks almost alike the approach already presented along with the question.

– Martin Zeitler
Dec 12 '18 at 12:13













@MartinZeitler: Yes, you are right. I've added '**/.realm.management' to be deleted.

– aminography
Dec 12 '18 at 12:15







@MartinZeitler: Yes, you are right. I've added '**/.realm.management' to be deleted.

– aminography
Dec 12 '18 at 12:15















the basic issue might be conflicting exclusive file access. I might be wrong (concerning aapt & assets), but would assume that empty directories are in general not being packaged.

– Martin Zeitler
Dec 12 '18 at 12:31







the basic issue might be conflicting exclusive file access. I might be wrong (concerning aapt & assets), but would assume that empty directories are in general not being packaged.

– Martin Zeitler
Dec 12 '18 at 12:31















@aminography I noticed that your .realm.management directory in the screenshot provided is not prefixed with "appData", i.e. appData.realm.management/. Did this solution work for you? It did not appear to resolve the issue.

– Orbit
Dec 17 '18 at 21:35





@aminography I noticed that your .realm.management directory in the screenshot provided is not prefixed with "appData", i.e. appData.realm.management/. Did this solution work for you? It did not appear to resolve the issue.

– Orbit
Dec 17 '18 at 21:35













@aminography almost have to up-vote this, for providing the screenshot of the assets directory, which enabled my to write that cleanupRealm task. else I would not have known what to write.

– Martin Zeitler
Dec 17 '18 at 22:56







@aminography almost have to up-vote this, for providing the screenshot of the assets directory, which enabled my to write that cleanupRealm task. else I would not have known what to write.

– Martin Zeitler
Dec 17 '18 at 22:56















5














guess you might be using an elder version of Realm Studio,
because according to issue #842 and pull request #847, those directories should meanwhile be properly cleaned up - and also report, in case not - instead of stalling. the current version 3.12 should have that fixed (basically any release after the 18th of June). if that should not help, the best you can do is to report it below issue #842; or file a new one issue, which is referencing issue #842. also check the file-system permissions, that the user which runs gradle is permitted to delete there; manually moving files out of the way "might" help, so the current user may re-create them and then subsequently is able to delete his own files.



both methods using gradle are workarounds - because it should not happen in the first place.



in order to obtain further information "why it stalls", run this command in the terminal:



./gradlew -d app:generateDebugAssets


respectively on Windows (the question does neither indicate the OS nor the Realm Studio version):



gradlew.bat -d app:generateDebugAssets


edit: one could even delete these files before each build:



task cleanupRealm(type: Delete) {
delete project.projectDir.path + "/src/main/assets/.realm.management"
delete project.projectDir.path + "/src/main/assets/appData.realm.lock"
delete project.projectDir.path + "/src/main/assets/appData.realm.note"
}

tasks.whenTaskAdded { task ->
if (task.name == "preDebugBuild" || task.name == "preReleaseBuild") {
task.dependsOn cleanupRealm
}
}


which changes the task graph to:



:app:checkDebugClasspath
:app:cleanupRealm
:app:preBuild
:app:preDebugBuild





share|improve this answer


























  • I believe the description and code shown in the linked PRs has to do with Electron's renderer process and relative files containing a renderer- pattern, as they don't appear to be related to this issue. I am running the latest release of Realm Studio. Your suggestion to manually run the task was great, as app:generateDebugAssets completes successfully. :app:generateDebugAssets UP-TO-DATE had been the last thing printed while building in Android Studio, however the real culprit appears to be :app:mergeDebugAssets, which repeatedly prints logs regarding the daemon addresses registry.

    – Orbit
    Dec 17 '18 at 21:48













  • @Orbit and when you'd run ./gradlew -d :app:mergeDebugAssets? it might be waiting to get access to a shared lock, which it does not get ...

    – Martin Zeitler
    Dec 17 '18 at 22:28













  • The task hangs at 75%. I'll add a small snippet of the output that gets repeatedly logged at that point, as the full output is quite large, to the original post. Note that ./gradlew -s app:mergeDebugAssets shows no exceptions. Also, note that without these "temporary" Realm files, this task usually completes within a few seconds.

    – Orbit
    Dec 17 '18 at 22:47











  • @Orbit just added the task which creates this situation. it's not tested, because I don't have these files - but at least the task is added properly, has the correct type and I'm convinced that only the paths might vary. nevertheless it could fail, when any of these files is opened with an exclusive lock.

    – Martin Zeitler
    Dec 17 '18 at 23:01













  • Your cleanupRealm task works great, though i've changed the call to use delete project.projectDir.path instead. This deletes these temporary files on every Gradle sync and every build. Any idea as to why the issue with mergeDebugAssets was occuring? Is there a way to simply have the build ignore these files instead of deleting them?

    – Orbit
    Dec 17 '18 at 23:12
















5














guess you might be using an elder version of Realm Studio,
because according to issue #842 and pull request #847, those directories should meanwhile be properly cleaned up - and also report, in case not - instead of stalling. the current version 3.12 should have that fixed (basically any release after the 18th of June). if that should not help, the best you can do is to report it below issue #842; or file a new one issue, which is referencing issue #842. also check the file-system permissions, that the user which runs gradle is permitted to delete there; manually moving files out of the way "might" help, so the current user may re-create them and then subsequently is able to delete his own files.



both methods using gradle are workarounds - because it should not happen in the first place.



in order to obtain further information "why it stalls", run this command in the terminal:



./gradlew -d app:generateDebugAssets


respectively on Windows (the question does neither indicate the OS nor the Realm Studio version):



gradlew.bat -d app:generateDebugAssets


edit: one could even delete these files before each build:



task cleanupRealm(type: Delete) {
delete project.projectDir.path + "/src/main/assets/.realm.management"
delete project.projectDir.path + "/src/main/assets/appData.realm.lock"
delete project.projectDir.path + "/src/main/assets/appData.realm.note"
}

tasks.whenTaskAdded { task ->
if (task.name == "preDebugBuild" || task.name == "preReleaseBuild") {
task.dependsOn cleanupRealm
}
}


which changes the task graph to:



:app:checkDebugClasspath
:app:cleanupRealm
:app:preBuild
:app:preDebugBuild





share|improve this answer


























  • I believe the description and code shown in the linked PRs has to do with Electron's renderer process and relative files containing a renderer- pattern, as they don't appear to be related to this issue. I am running the latest release of Realm Studio. Your suggestion to manually run the task was great, as app:generateDebugAssets completes successfully. :app:generateDebugAssets UP-TO-DATE had been the last thing printed while building in Android Studio, however the real culprit appears to be :app:mergeDebugAssets, which repeatedly prints logs regarding the daemon addresses registry.

    – Orbit
    Dec 17 '18 at 21:48













  • @Orbit and when you'd run ./gradlew -d :app:mergeDebugAssets? it might be waiting to get access to a shared lock, which it does not get ...

    – Martin Zeitler
    Dec 17 '18 at 22:28













  • The task hangs at 75%. I'll add a small snippet of the output that gets repeatedly logged at that point, as the full output is quite large, to the original post. Note that ./gradlew -s app:mergeDebugAssets shows no exceptions. Also, note that without these "temporary" Realm files, this task usually completes within a few seconds.

    – Orbit
    Dec 17 '18 at 22:47











  • @Orbit just added the task which creates this situation. it's not tested, because I don't have these files - but at least the task is added properly, has the correct type and I'm convinced that only the paths might vary. nevertheless it could fail, when any of these files is opened with an exclusive lock.

    – Martin Zeitler
    Dec 17 '18 at 23:01













  • Your cleanupRealm task works great, though i've changed the call to use delete project.projectDir.path instead. This deletes these temporary files on every Gradle sync and every build. Any idea as to why the issue with mergeDebugAssets was occuring? Is there a way to simply have the build ignore these files instead of deleting them?

    – Orbit
    Dec 17 '18 at 23:12














5












5








5







guess you might be using an elder version of Realm Studio,
because according to issue #842 and pull request #847, those directories should meanwhile be properly cleaned up - and also report, in case not - instead of stalling. the current version 3.12 should have that fixed (basically any release after the 18th of June). if that should not help, the best you can do is to report it below issue #842; or file a new one issue, which is referencing issue #842. also check the file-system permissions, that the user which runs gradle is permitted to delete there; manually moving files out of the way "might" help, so the current user may re-create them and then subsequently is able to delete his own files.



both methods using gradle are workarounds - because it should not happen in the first place.



in order to obtain further information "why it stalls", run this command in the terminal:



./gradlew -d app:generateDebugAssets


respectively on Windows (the question does neither indicate the OS nor the Realm Studio version):



gradlew.bat -d app:generateDebugAssets


edit: one could even delete these files before each build:



task cleanupRealm(type: Delete) {
delete project.projectDir.path + "/src/main/assets/.realm.management"
delete project.projectDir.path + "/src/main/assets/appData.realm.lock"
delete project.projectDir.path + "/src/main/assets/appData.realm.note"
}

tasks.whenTaskAdded { task ->
if (task.name == "preDebugBuild" || task.name == "preReleaseBuild") {
task.dependsOn cleanupRealm
}
}


which changes the task graph to:



:app:checkDebugClasspath
:app:cleanupRealm
:app:preBuild
:app:preDebugBuild





share|improve this answer















guess you might be using an elder version of Realm Studio,
because according to issue #842 and pull request #847, those directories should meanwhile be properly cleaned up - and also report, in case not - instead of stalling. the current version 3.12 should have that fixed (basically any release after the 18th of June). if that should not help, the best you can do is to report it below issue #842; or file a new one issue, which is referencing issue #842. also check the file-system permissions, that the user which runs gradle is permitted to delete there; manually moving files out of the way "might" help, so the current user may re-create them and then subsequently is able to delete his own files.



both methods using gradle are workarounds - because it should not happen in the first place.



in order to obtain further information "why it stalls", run this command in the terminal:



./gradlew -d app:generateDebugAssets


respectively on Windows (the question does neither indicate the OS nor the Realm Studio version):



gradlew.bat -d app:generateDebugAssets


edit: one could even delete these files before each build:



task cleanupRealm(type: Delete) {
delete project.projectDir.path + "/src/main/assets/.realm.management"
delete project.projectDir.path + "/src/main/assets/appData.realm.lock"
delete project.projectDir.path + "/src/main/assets/appData.realm.note"
}

tasks.whenTaskAdded { task ->
if (task.name == "preDebugBuild" || task.name == "preReleaseBuild") {
task.dependsOn cleanupRealm
}
}


which changes the task graph to:



:app:checkDebugClasspath
:app:cleanupRealm
:app:preBuild
:app:preDebugBuild






share|improve this answer














share|improve this answer



share|improve this answer








edited Dec 17 '18 at 23:40

























answered Dec 12 '18 at 11:48









Martin ZeitlerMartin Zeitler

17.5k34169




17.5k34169













  • I believe the description and code shown in the linked PRs has to do with Electron's renderer process and relative files containing a renderer- pattern, as they don't appear to be related to this issue. I am running the latest release of Realm Studio. Your suggestion to manually run the task was great, as app:generateDebugAssets completes successfully. :app:generateDebugAssets UP-TO-DATE had been the last thing printed while building in Android Studio, however the real culprit appears to be :app:mergeDebugAssets, which repeatedly prints logs regarding the daemon addresses registry.

    – Orbit
    Dec 17 '18 at 21:48













  • @Orbit and when you'd run ./gradlew -d :app:mergeDebugAssets? it might be waiting to get access to a shared lock, which it does not get ...

    – Martin Zeitler
    Dec 17 '18 at 22:28













  • The task hangs at 75%. I'll add a small snippet of the output that gets repeatedly logged at that point, as the full output is quite large, to the original post. Note that ./gradlew -s app:mergeDebugAssets shows no exceptions. Also, note that without these "temporary" Realm files, this task usually completes within a few seconds.

    – Orbit
    Dec 17 '18 at 22:47











  • @Orbit just added the task which creates this situation. it's not tested, because I don't have these files - but at least the task is added properly, has the correct type and I'm convinced that only the paths might vary. nevertheless it could fail, when any of these files is opened with an exclusive lock.

    – Martin Zeitler
    Dec 17 '18 at 23:01













  • Your cleanupRealm task works great, though i've changed the call to use delete project.projectDir.path instead. This deletes these temporary files on every Gradle sync and every build. Any idea as to why the issue with mergeDebugAssets was occuring? Is there a way to simply have the build ignore these files instead of deleting them?

    – Orbit
    Dec 17 '18 at 23:12



















  • I believe the description and code shown in the linked PRs has to do with Electron's renderer process and relative files containing a renderer- pattern, as they don't appear to be related to this issue. I am running the latest release of Realm Studio. Your suggestion to manually run the task was great, as app:generateDebugAssets completes successfully. :app:generateDebugAssets UP-TO-DATE had been the last thing printed while building in Android Studio, however the real culprit appears to be :app:mergeDebugAssets, which repeatedly prints logs regarding the daemon addresses registry.

    – Orbit
    Dec 17 '18 at 21:48













  • @Orbit and when you'd run ./gradlew -d :app:mergeDebugAssets? it might be waiting to get access to a shared lock, which it does not get ...

    – Martin Zeitler
    Dec 17 '18 at 22:28













  • The task hangs at 75%. I'll add a small snippet of the output that gets repeatedly logged at that point, as the full output is quite large, to the original post. Note that ./gradlew -s app:mergeDebugAssets shows no exceptions. Also, note that without these "temporary" Realm files, this task usually completes within a few seconds.

    – Orbit
    Dec 17 '18 at 22:47











  • @Orbit just added the task which creates this situation. it's not tested, because I don't have these files - but at least the task is added properly, has the correct type and I'm convinced that only the paths might vary. nevertheless it could fail, when any of these files is opened with an exclusive lock.

    – Martin Zeitler
    Dec 17 '18 at 23:01













  • Your cleanupRealm task works great, though i've changed the call to use delete project.projectDir.path instead. This deletes these temporary files on every Gradle sync and every build. Any idea as to why the issue with mergeDebugAssets was occuring? Is there a way to simply have the build ignore these files instead of deleting them?

    – Orbit
    Dec 17 '18 at 23:12

















I believe the description and code shown in the linked PRs has to do with Electron's renderer process and relative files containing a renderer- pattern, as they don't appear to be related to this issue. I am running the latest release of Realm Studio. Your suggestion to manually run the task was great, as app:generateDebugAssets completes successfully. :app:generateDebugAssets UP-TO-DATE had been the last thing printed while building in Android Studio, however the real culprit appears to be :app:mergeDebugAssets, which repeatedly prints logs regarding the daemon addresses registry.

– Orbit
Dec 17 '18 at 21:48







I believe the description and code shown in the linked PRs has to do with Electron's renderer process and relative files containing a renderer- pattern, as they don't appear to be related to this issue. I am running the latest release of Realm Studio. Your suggestion to manually run the task was great, as app:generateDebugAssets completes successfully. :app:generateDebugAssets UP-TO-DATE had been the last thing printed while building in Android Studio, however the real culprit appears to be :app:mergeDebugAssets, which repeatedly prints logs regarding the daemon addresses registry.

– Orbit
Dec 17 '18 at 21:48















@Orbit and when you'd run ./gradlew -d :app:mergeDebugAssets? it might be waiting to get access to a shared lock, which it does not get ...

– Martin Zeitler
Dec 17 '18 at 22:28







@Orbit and when you'd run ./gradlew -d :app:mergeDebugAssets? it might be waiting to get access to a shared lock, which it does not get ...

– Martin Zeitler
Dec 17 '18 at 22:28















The task hangs at 75%. I'll add a small snippet of the output that gets repeatedly logged at that point, as the full output is quite large, to the original post. Note that ./gradlew -s app:mergeDebugAssets shows no exceptions. Also, note that without these "temporary" Realm files, this task usually completes within a few seconds.

– Orbit
Dec 17 '18 at 22:47





The task hangs at 75%. I'll add a small snippet of the output that gets repeatedly logged at that point, as the full output is quite large, to the original post. Note that ./gradlew -s app:mergeDebugAssets shows no exceptions. Also, note that without these "temporary" Realm files, this task usually completes within a few seconds.

– Orbit
Dec 17 '18 at 22:47













@Orbit just added the task which creates this situation. it's not tested, because I don't have these files - but at least the task is added properly, has the correct type and I'm convinced that only the paths might vary. nevertheless it could fail, when any of these files is opened with an exclusive lock.

– Martin Zeitler
Dec 17 '18 at 23:01







@Orbit just added the task which creates this situation. it's not tested, because I don't have these files - but at least the task is added properly, has the correct type and I'm convinced that only the paths might vary. nevertheless it could fail, when any of these files is opened with an exclusive lock.

– Martin Zeitler
Dec 17 '18 at 23:01















Your cleanupRealm task works great, though i've changed the call to use delete project.projectDir.path instead. This deletes these temporary files on every Gradle sync and every build. Any idea as to why the issue with mergeDebugAssets was occuring? Is there a way to simply have the build ignore these files instead of deleting them?

– Orbit
Dec 17 '18 at 23:12





Your cleanupRealm task works great, though i've changed the call to use delete project.projectDir.path instead. This deletes these temporary files on every Gradle sync and every build. Any idea as to why the issue with mergeDebugAssets was occuring? Is there a way to simply have the build ignore these files instead of deleting them?

– Orbit
Dec 17 '18 at 23:12











4














Try that :



android {
aaptOptions {
ignoreAssetsPattern "!*.cv:!*.mx:!*.lock:!*.note"
}
}


From aapt binary from build-tools folder :



./aapt
[...]
--ignore-assets
Assets to be ignored. Default pattern is:
!.svn:!.git:!.ds_store:!*.scc:.*:<dir>_*:!CVS:!thumbs.db:!picasa.ini:!*~





share|improve this answer


























  • Where should the aaptOptions block go? Both options I tried (inside android {} and another in android { buildTypes {} }) did not appear to solve the issue.

    – Orbit
    Dec 11 '18 at 22:20











  • Yes it's in the android block. It does not work at all ?

    – ToYonos
    Dec 12 '18 at 0:49











  • ignoreAssetsPattern = ignoreAssetsPattern + "..." would add instead of replace.

    – Martin Zeitler
    Dec 12 '18 at 12:14











  • @ToYonos Correct, it does not appear to resolve the issue. Note that before setting ignoreAssetsPattern, ignoreAssets and ignoreAssetsPattern are both null.

    – Orbit
    Dec 17 '18 at 22:14
















4














Try that :



android {
aaptOptions {
ignoreAssetsPattern "!*.cv:!*.mx:!*.lock:!*.note"
}
}


From aapt binary from build-tools folder :



./aapt
[...]
--ignore-assets
Assets to be ignored. Default pattern is:
!.svn:!.git:!.ds_store:!*.scc:.*:<dir>_*:!CVS:!thumbs.db:!picasa.ini:!*~





share|improve this answer


























  • Where should the aaptOptions block go? Both options I tried (inside android {} and another in android { buildTypes {} }) did not appear to solve the issue.

    – Orbit
    Dec 11 '18 at 22:20











  • Yes it's in the android block. It does not work at all ?

    – ToYonos
    Dec 12 '18 at 0:49











  • ignoreAssetsPattern = ignoreAssetsPattern + "..." would add instead of replace.

    – Martin Zeitler
    Dec 12 '18 at 12:14











  • @ToYonos Correct, it does not appear to resolve the issue. Note that before setting ignoreAssetsPattern, ignoreAssets and ignoreAssetsPattern are both null.

    – Orbit
    Dec 17 '18 at 22:14














4












4








4







Try that :



android {
aaptOptions {
ignoreAssetsPattern "!*.cv:!*.mx:!*.lock:!*.note"
}
}


From aapt binary from build-tools folder :



./aapt
[...]
--ignore-assets
Assets to be ignored. Default pattern is:
!.svn:!.git:!.ds_store:!*.scc:.*:<dir>_*:!CVS:!thumbs.db:!picasa.ini:!*~





share|improve this answer















Try that :



android {
aaptOptions {
ignoreAssetsPattern "!*.cv:!*.mx:!*.lock:!*.note"
}
}


From aapt binary from build-tools folder :



./aapt
[...]
--ignore-assets
Assets to be ignored. Default pattern is:
!.svn:!.git:!.ds_store:!*.scc:.*:<dir>_*:!CVS:!thumbs.db:!picasa.ini:!*~






share|improve this answer














share|improve this answer



share|improve this answer








edited Dec 12 '18 at 8:37

























answered Dec 5 '18 at 10:11









ToYonosToYonos

11.7k22747




11.7k22747













  • Where should the aaptOptions block go? Both options I tried (inside android {} and another in android { buildTypes {} }) did not appear to solve the issue.

    – Orbit
    Dec 11 '18 at 22:20











  • Yes it's in the android block. It does not work at all ?

    – ToYonos
    Dec 12 '18 at 0:49











  • ignoreAssetsPattern = ignoreAssetsPattern + "..." would add instead of replace.

    – Martin Zeitler
    Dec 12 '18 at 12:14











  • @ToYonos Correct, it does not appear to resolve the issue. Note that before setting ignoreAssetsPattern, ignoreAssets and ignoreAssetsPattern are both null.

    – Orbit
    Dec 17 '18 at 22:14



















  • Where should the aaptOptions block go? Both options I tried (inside android {} and another in android { buildTypes {} }) did not appear to solve the issue.

    – Orbit
    Dec 11 '18 at 22:20











  • Yes it's in the android block. It does not work at all ?

    – ToYonos
    Dec 12 '18 at 0:49











  • ignoreAssetsPattern = ignoreAssetsPattern + "..." would add instead of replace.

    – Martin Zeitler
    Dec 12 '18 at 12:14











  • @ToYonos Correct, it does not appear to resolve the issue. Note that before setting ignoreAssetsPattern, ignoreAssets and ignoreAssetsPattern are both null.

    – Orbit
    Dec 17 '18 at 22:14

















Where should the aaptOptions block go? Both options I tried (inside android {} and another in android { buildTypes {} }) did not appear to solve the issue.

– Orbit
Dec 11 '18 at 22:20





Where should the aaptOptions block go? Both options I tried (inside android {} and another in android { buildTypes {} }) did not appear to solve the issue.

– Orbit
Dec 11 '18 at 22:20













Yes it's in the android block. It does not work at all ?

– ToYonos
Dec 12 '18 at 0:49





Yes it's in the android block. It does not work at all ?

– ToYonos
Dec 12 '18 at 0:49













ignoreAssetsPattern = ignoreAssetsPattern + "..." would add instead of replace.

– Martin Zeitler
Dec 12 '18 at 12:14





ignoreAssetsPattern = ignoreAssetsPattern + "..." would add instead of replace.

– Martin Zeitler
Dec 12 '18 at 12:14













@ToYonos Correct, it does not appear to resolve the issue. Note that before setting ignoreAssetsPattern, ignoreAssets and ignoreAssetsPattern are both null.

– Orbit
Dec 17 '18 at 22:14





@ToYonos Correct, it does not appear to resolve the issue. Note that before setting ignoreAssetsPattern, ignoreAssets and ignoreAssetsPattern are both null.

– Orbit
Dec 17 '18 at 22:14


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53490891%2fexclude-temporary-realm-files-from-gradle-build%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

A CLEAN and SIMPLE way to add appendices to Table of Contents and bookmarks

Calculate evaluation metrics using cross_val_predict sklearn

Insert data from modal to MySQL (multiple modal on website)