Gradle Flavors not supported?

[ecco256]

I seem to be unable to use flavors when using gradle in combination with VisualGDB. Building from Visual Studio for example always calls gradlew with “zipalignDebug” and I can find no way to turn that into “zipalignMyFlavorDebug”. Did I overlook something? Is there some way to combine gradle flavors with VisualGDB?

[support]

Hi,

Please try the newest VisualGDB 5.0 Preview 3 build. It supports customizing the Gradle flavor via VisualGDB Project Properties dialog.

[ecco256]

Thanks, that does seem to be a jump in the right direction. I encounter a myriad of problems with this version though…
<h2>Problem 1</h2>
For example, I try to follow the Android Studio Co Debugging tutorial to the letter. Everything goes fine until I need to create the Visual Studio project. I import my gradle project and try to debug the app. The jni sources are built fine and debugging starts, only to immediately exit with SIGSEGV: Segmentation Fault. The GDB Session window shows this:

C:\android\android-ndk-r10d\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin\arm-linux-androideabi-gdb.exe --interpreter mi "C:\Users\Erik\AppData\Local\VisualGDB\AndroidBinaryCache15d3fbace541002\app_process" -x "C:\Users\Erik\AndroidStudioProjects\MyApplication\app\libs\armeabi\gdb.setup"
Activating library load breakpoint bug workaround...
VisualGDB was not able to find library load entry point in /system/bin/linker. Automatic symbol loading and startup debugging won't work.

Logcat shows: 03-27 10:43:16.210 22233 22262 libc Fatal signal 11 (SIGSEGV), code 2, fault addr 0x29faea50 in tid 22262 (RenderThread)

So I am unable to do any kind of debugging in Visual Studio, which of course renders the whole exercise useless.
<h2>Problem 2</h2>
Not the biggest one but pressing build in Visual Studio multiple times always results in “C:\Users\Erik\AndroidStudioProjects\MyApplication\app\libs\armeabi.jar will be rebuilt.” – Is this really necessary when the source file clearly hasn’t changed?
<h2>Problem 3</h2>
When adding some very simple flavors to my gradle file:

productFlavors {
  flavor2 {
  }
  flavor1 {
  }
}

Of course building in Visual Studio results in the problems I got in VisualGDB 4. So I add “flavor1” as custom flavor in my build configuration. When trying to build I get the following output:

VisualGDB: Run "cmd.exe /c gradlew.bat flavor1" in directory "C:\Users\Erik\AndroidStudioProjects\MyApplication" on local computer
1>
1> FAILURE: Build failed with an exception.
1>
1> * What went wrong:
1> Task 'flavor1' not found in root project 'MyApplication'.

Of course that doesn’t work; visualgdb simply calls gradle with the flavor name. That does not work at all, it is supposed to call the correct task. For example: “cmd.exe /c gradlew.bat assembleFlavor1Debug” to build an apk. Gradle has some awesome autocorrect features for task names, but not that awesome 😉
<h2>Problem 4</h2>
Cleaning now leads to build errors:

1> VisualGDB: Run "gradlew.bat clean" in directory "C:\Users\Erik\AndroidStudioProjects\MyApplication\app\.." on local computer
1>VisualGDB : error : The system cannot find the file specified: gradlew.bat
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.MakeFile.Targets(33,5): error MSB3073: The command ""C:\Program Files (x86)\Sysprogs\VisualGDB\\VisualGDB.exe" /clean "C:\Users\Erik\AndroidStudioProjects\CoDebugDemo\CoDebugDemo.vcxproj" "/solution:C:\Users\Erik\AndroidStudioProjects\CoDebugDemo\CoDebugDemo.sln" "/config:Debug" "/platform:Win32"" exited with code -1.
========== Clean: 0 succeeded, 1 failed, 0 skipped ==========
<h2>Problem 5</h2>
Just to see what happens I enter “assembleFlavor1Debug” as the custom flavor name, as VisualGDB simply seems to pass on the flavor name to gradle. An apk is now created (even though technically it should only have built the sources). At least I have something to run now, even though I cannot debug at all.

So now I try to actually use a flavor for what they were meant for: providing flavor specific settings such as the app id. I change my flavor 1 as follows:

flavor1 {
  applicationId "some.other.appid"
}

I try to build and run again. VisualGDB shows a popup with “Failed to start the main Activity”:

c:\android\android-sdk-20140702\SDK\platform-tools\adb.exe -s 015d3fbace541002 shell run-as com.example.virtual.myapplication /system/bin/sh -c pwd
run-as: Package 'com.example.virtual.myapplication' is unknown
Command exited with code 0

Trying to run the app like that is of course also wrong; the applicationId specified in the flavor overwrites the packageId, so VisualGDB is not starting the apk with the correct command.

All of these things combined make my VisualGDB license absolutely unusable at the moment, so I really hope that something can be done to fix these issues, or perhaps show me I’m just doing it all wrong ^^

Also some more unrelated minor gripes:

• When there are more apk’s in the output directory VisualGDB asks which one should be run. It should be able to deduce this from the current build configuration…
• Upon importing a gradle project it does not detect or import any flavors. Would be great if VisualGDB would create configurations for the entire flavor matrix X build type, or even allow you to select which ones should be created

[support]

The SIGSEGV is most likely caused by the workaround VisualGDB utilizes to fix issues with library symbol loading. Please try switching the workaround method or disabling it completely.

VisualGDB rebuilds the .jar file when any of the .so files that go into it has a more recent timestamp than the .jar file itself. Please double-check why your .so files get rebuilt.

Regarding the gradle flavor issues, we will do a full investigation/analysis of that after we release the new clang-based IntelliSense engine. Before that we should be able to provide hotfixes that should make debugging possible with reasonable manual adjustments. Could you make and send us a small small repro case demostrating the broken build/launch for a custom flavor? We should be able to release a hotfix based on it very quickly.

[ecco256]

After redoing the tutorial again the library load entry point issue is all of a sudden gone; even though I got the same issue the 3 times I tried before. So I suppose either my laptop is haunted or VisualGDB has a silent update feature 😛

Some further issues I found on Visual Studio 2012:

• The jar file is rebuilt every time I build from the first moment I imported the gradle project with visualgdb, following the visualgdb tutorial at http://visualgdb.com/tutorials/android/astudio/ to the letter. So immediately after the import step I get the output below; looks like the problem is “Install : libHelloLibrary.so => libs/armeabi/libHelloLibrary.so” so the .so file is new each time build is pressed. This results in having to reinstall the apk each time you run, which for a large project is a huge time waster.

1>------ Build started: Project: CoDebugDemo, Configuration: Debug Win32 ------
1> VisualGDB: Run "C:\android\android-ndk-r10d\ndk-build.cmd NDK_DEBUG=1 APP_PLATFORM=android-9 VGDB_VSCONFIG=Debug" in directory "C:\Users\Erik\AndroidStudioProjects\MyApplication\app" on local computer
1> [armeabi] Gdbserver : [arm-linux-androideabi-4.8] libs/armeabi/gdbserver
1> [armeabi] Gdbsetup : libs/armeabi/gdb.setup
1> [armeabi] Install : libHelloLibrary.so => libs/armeabi/libHelloLibrary.so
1> C:\Users\Erik\AndroidStudioProjects\MyApplication\app\libs\armeabi.jar will be rebuilt.

• “Targeted Android NDK Platform” is by default set to android-8. However this setting is ignored until you manually change it.
• The Apply button stays disabled until I toggle a checkbox or radiobutton; editing the textfield does not enable the button.

I have zipped my Android Studio and Visual Studio projects here: https://dl.dropboxusercontent.com/u/20000559/AndroidStudioProjects.zip

They are nothing special, just the tutorial with 2 flavors added to the Android Studio project. Not being able to run (main activity not found) is probably by far the biggest issue at all, it makes flavor support useless.

[ecco256]

Another issue: the output screen is cleared when the VisualGDB Project Properties window is closed while I am compiling, so I always have to wait until I finish compiling before I open/close that window.

[ecco256]

Another possible issue: VisualGDB injects debuggable=true into the AndroidManifest.xml. This results in Android Studio showing the warning:

Avoid hardcoding the debug mode; leaving it out allows debug and release builds to automatically assign one

It's best to leave out the android:debuggable attribute from the manifest. If you do, then the tools will automatically insert android:debuggable=true when building an APK to debug on an emulator or device. And when you perform a release build, such as Exporting APK, it will automatically set it to false.

If on the other hand you specify a specific value in the manifest file, then the tools will always use it. This can lead to accidentally publishing your app with debug information.

When I select the “don’t change the manifest” option it complains about not having that attribute; but that should not matter.

• This reply was modified 9 years ago by ecco256.

[support]

Hi,

Please try the following build: http://visualgdb.com/tmp/VisualGDB-5.0.3.310.msi

We have made the following changes:

• When using Gradle build subsystem, VisualGDB now uses the $(SourceDir)\$(GradleAppSubdirectory)\build\intermediates\manifests\full\$(GradleFlavor)\$(GradleBuildName)\AndroidManifest.xml file to determine the package/activity names and other settings. I.e. all changes caused by the Gradle flavor will be now read correctly. The path (that appears to be hardcoded in Gradle) can be currently modified by editing the .vgdbsettings file manually.
• VisualGDB now uses the zipalign$(GradleFlavor)$(GradleBuildName) as the gradle task name. The GradleFlavor can be defined via VisualGDB Project Properties as before.
• VisualGDB now does not edit the AndroidManifest.xml file if it has successfully found a generated manifest file from the intermediates folder.
• You can specify additional arguments to Gradle by adding a VisualGDBProjectSettings2/Build/AdditionalGradleArguments element to the .vgdbsettings file (no GUI setting for it yet).
• In case of multiple apk files VisualGDB checks whether the $(app subdirectory)-$(gradle flavor)-Debug.apk file is present. If it is found, it is automatically selected without showing any extra windows.
• If VisualGDB has to rebuild the .jar file, it now displays the file that caused the rebuild.

The build output is actually still available if you select ‘build’ in the “show output from” field. Opening VisualGDB Project Properties switches the output view to VisualGDB internal output.

[ecco256]

An awesome update, thanks!

This just leaves the following issues for me:

– VisualGDB uses the flavor and buildtype names verbatim, but the convention seems to be to use lower case names. Any derived name such as the generated task names should concatenate the names by capitalising the first letter; ie flavor1/debug -> zipalignFlavor1Debug

– cleaning the project still does not work; gradlew not found.

– the android:debuggable=”true” attribute is still added to the manifest and checked when running; I think that instead of checking the merged manifest in the build dir maybe you should be decoding the manifest file in the apk itself?

– the jar file is recreated for my project because of the .so file that ndk-build outputs. I’ll check if this is also the case with the tutorial project as it’s a lot simpler.

 

Just out of curiosity, why are you invoking the zipalign- task and not the assemble- task as that seems to be the intended hook according to google’s documentation: https://developer.android.com/tools/building/plugin-for-gradle.html

[support]

Hi,

Please try this build: http://visualgdb.com/tmp/VisualGDB-5.0.3.312.msi

If cleaning is still not working, please provide a build log and double-check that the gradlew.bat file is present in the directory that VisualGDB reports.

If android:debuggable is still added, please check the build log, it should now print the full path of the AndroidManifest.xml it is editing. Please let us know which file version is VisualGDB trying to edit.

We used zipalign because assemble did not seem to work properly on some older version of Gradle. As it seems to work now, we have changed it to assemble and added a setting that allows overriding it.

[ecco256]

Another awesome update, thanks!

The debuggable flag is still set:

2>  VisualGDB: Successfully updated debuggable flag in C:\<<path to my android studio project>>\app/src/main/AndroidManifest.xml to true.

[Author]

Posts