[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.

[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

[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, 1 month ago by ecco256.

[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]

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]

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

[Author]

Posts