Do I need to disable debugImplementation and releaseImplementation before creating APK for release
I use a library named LeakCanary which allows me to find anything that cause memory leaks. I add the following references in gradle:
debugImplementation 'com.squareup.leakcanary:leakcanary-android:1.6.2'
releaseImplementation 'com.squareup.leakcanary:leakcanary-android-no-op:1.6.2'
debugImplementation 'com.squareup.leakcanary:leakcanary-support-fragment:1.6.2'
To use the library. Now, before creating an APK full release for the store, do I need to comment the above lines, or is it safe to just keep them and comment only the line to use the library in the main activity.
Thanks.
java android gradle
add a comment |
I use a library named LeakCanary which allows me to find anything that cause memory leaks. I add the following references in gradle:
debugImplementation 'com.squareup.leakcanary:leakcanary-android:1.6.2'
releaseImplementation 'com.squareup.leakcanary:leakcanary-android-no-op:1.6.2'
debugImplementation 'com.squareup.leakcanary:leakcanary-support-fragment:1.6.2'
To use the library. Now, before creating an APK full release for the store, do I need to comment the above lines, or is it safe to just keep them and comment only the line to use the library in the main activity.
Thanks.
java android gradle
add a comment |
I use a library named LeakCanary which allows me to find anything that cause memory leaks. I add the following references in gradle:
debugImplementation 'com.squareup.leakcanary:leakcanary-android:1.6.2'
releaseImplementation 'com.squareup.leakcanary:leakcanary-android-no-op:1.6.2'
debugImplementation 'com.squareup.leakcanary:leakcanary-support-fragment:1.6.2'
To use the library. Now, before creating an APK full release for the store, do I need to comment the above lines, or is it safe to just keep them and comment only the line to use the library in the main activity.
Thanks.
java android gradle
I use a library named LeakCanary which allows me to find anything that cause memory leaks. I add the following references in gradle:
debugImplementation 'com.squareup.leakcanary:leakcanary-android:1.6.2'
releaseImplementation 'com.squareup.leakcanary:leakcanary-android-no-op:1.6.2'
debugImplementation 'com.squareup.leakcanary:leakcanary-support-fragment:1.6.2'
To use the library. Now, before creating an APK full release for the store, do I need to comment the above lines, or is it safe to just keep them and comment only the line to use the library in the main activity.
Thanks.
java android gradle
java android gradle
asked Nov 22 '18 at 22:30
JonraJonra
32
32
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
release builds would only contain leakcanary-android-no-op
... where no op
means "no operation"; therefore one can assume no side-effects there; except adding the size of that dummy package to the release build's package size. that no op
dummy package is only required, because else any occurrence of LeakCanary
in the code would be unknown.
So, with me leaving those on, the APK size would increase?
– Jonra
Nov 22 '18 at 22:45
you must leave theno-op
package there, else your code will break. that's the reason why that package even exists. obviously, the release build would in general be slightly smaller than the debug build. and it might be a few kilobytes only, nothing too dramatic. alternatively, you'd have to remove it altogether... including all occurrences of classLeakCanary
in code, which removing thereleaseImplementation
would break.
– Martin Zeitler
Nov 22 '18 at 22:46
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53438668%2fdo-i-need-to-disable-debugimplementation-and-releaseimplementation-before-creati%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
release builds would only contain leakcanary-android-no-op
... where no op
means "no operation"; therefore one can assume no side-effects there; except adding the size of that dummy package to the release build's package size. that no op
dummy package is only required, because else any occurrence of LeakCanary
in the code would be unknown.
So, with me leaving those on, the APK size would increase?
– Jonra
Nov 22 '18 at 22:45
you must leave theno-op
package there, else your code will break. that's the reason why that package even exists. obviously, the release build would in general be slightly smaller than the debug build. and it might be a few kilobytes only, nothing too dramatic. alternatively, you'd have to remove it altogether... including all occurrences of classLeakCanary
in code, which removing thereleaseImplementation
would break.
– Martin Zeitler
Nov 22 '18 at 22:46
add a comment |
release builds would only contain leakcanary-android-no-op
... where no op
means "no operation"; therefore one can assume no side-effects there; except adding the size of that dummy package to the release build's package size. that no op
dummy package is only required, because else any occurrence of LeakCanary
in the code would be unknown.
So, with me leaving those on, the APK size would increase?
– Jonra
Nov 22 '18 at 22:45
you must leave theno-op
package there, else your code will break. that's the reason why that package even exists. obviously, the release build would in general be slightly smaller than the debug build. and it might be a few kilobytes only, nothing too dramatic. alternatively, you'd have to remove it altogether... including all occurrences of classLeakCanary
in code, which removing thereleaseImplementation
would break.
– Martin Zeitler
Nov 22 '18 at 22:46
add a comment |
release builds would only contain leakcanary-android-no-op
... where no op
means "no operation"; therefore one can assume no side-effects there; except adding the size of that dummy package to the release build's package size. that no op
dummy package is only required, because else any occurrence of LeakCanary
in the code would be unknown.
release builds would only contain leakcanary-android-no-op
... where no op
means "no operation"; therefore one can assume no side-effects there; except adding the size of that dummy package to the release build's package size. that no op
dummy package is only required, because else any occurrence of LeakCanary
in the code would be unknown.
answered Nov 22 '18 at 22:35
Martin ZeitlerMartin Zeitler
15.7k33965
15.7k33965
So, with me leaving those on, the APK size would increase?
– Jonra
Nov 22 '18 at 22:45
you must leave theno-op
package there, else your code will break. that's the reason why that package even exists. obviously, the release build would in general be slightly smaller than the debug build. and it might be a few kilobytes only, nothing too dramatic. alternatively, you'd have to remove it altogether... including all occurrences of classLeakCanary
in code, which removing thereleaseImplementation
would break.
– Martin Zeitler
Nov 22 '18 at 22:46
add a comment |
So, with me leaving those on, the APK size would increase?
– Jonra
Nov 22 '18 at 22:45
you must leave theno-op
package there, else your code will break. that's the reason why that package even exists. obviously, the release build would in general be slightly smaller than the debug build. and it might be a few kilobytes only, nothing too dramatic. alternatively, you'd have to remove it altogether... including all occurrences of classLeakCanary
in code, which removing thereleaseImplementation
would break.
– Martin Zeitler
Nov 22 '18 at 22:46
So, with me leaving those on, the APK size would increase?
– Jonra
Nov 22 '18 at 22:45
So, with me leaving those on, the APK size would increase?
– Jonra
Nov 22 '18 at 22:45
you must leave the
no-op
package there, else your code will break. that's the reason why that package even exists. obviously, the release build would in general be slightly smaller than the debug build. and it might be a few kilobytes only, nothing too dramatic. alternatively, you'd have to remove it altogether... including all occurrences of class LeakCanary
in code, which removing the releaseImplementation
would break.– Martin Zeitler
Nov 22 '18 at 22:46
you must leave the
no-op
package there, else your code will break. that's the reason why that package even exists. obviously, the release build would in general be slightly smaller than the debug build. and it might be a few kilobytes only, nothing too dramatic. alternatively, you'd have to remove it altogether... including all occurrences of class LeakCanary
in code, which removing the releaseImplementation
would break.– Martin Zeitler
Nov 22 '18 at 22:46
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53438668%2fdo-i-need-to-disable-debugimplementation-and-releaseimplementation-before-creati%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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