直接使用VS(VisualStdio)对Android,Linux,树莓派,ARM等进行代码编辑,编译,调试 VS的功能之强大,地球人都知道,VisualGDB+Visual Studio。VisualGDB整合了GNU Toolchain(GCC/GDB)进Visual Studio。 这样就可以直接使用Visual Studio开发和调试一些基于GNU Toolchain的各平台应用程序。例如:嵌入式程序,Android Native Code,MacOS Driver,Linux Driver, Linux Application等。
VisualGDB是德国一家公司Sysprogs UG开发的。
gdb调试工具(VisualGDB)把GDB调试工具集成到visual studio 开发环境中,在调试过程中,可以使用visual studio原有的单步执行、设定断定等快捷键,还可以在visual GDB session的窗口中输入GDB的调试命令,集成了visualGDB之后还可以在程序执行的过程中用鼠标悬停的方式查看和修改变量的值,这样在不改变调试习惯的同时还可以使用GDB强大的调试功能,很不错。
除了调试windows项目之外,visualGDB还可以在visual studio中调试android项目,linux项目。只不过调试linux项目的时候是通过ssh登陆的方式进行远程调试,也就是说基于网络的,至少是双机。
1.安装VisualGDB-5.0-beta2.msi
2.将VisualGDB.exe覆盖安装目录下的文件,安装路径默认为C:\Program Files\Sysprogs\VisualGDB
目前已知的VisualGDB免费版最新版是VisualGDB-5.0-beta2,具体的话可以简介的百度云中下载;
点击并安装 VisualGDB-5.0-beta2.msi
选择正确的版本的Visual Studio,,如下图所示,我当前选择的是Visual Studio 2013
安装完后用"VisualGDB.exe"替换掉安装目录下面的VisualGDB.exe,如我的完整的路径是"D:Program Files (x86)SysprogsVisualGDBVisualGDB.exe",具体的如下图所示:
打开Visual Studio 2013,便可以开始新建一个Android Project,具体的效果如下:
虽然界面上显示的是jdk32位的,但是实际上都用64位的版本的也是可以的,效果如下图所示:
可以新建一个 App 试试:
调试效果如下图所示:
当然可以导入一个已经存在的eclipse工程,效果如下:
1. 配置JDK
打开【我的电脑】属性-【高级系统设置】-【环境变量】如下图:
1) 第一“JAVA_HOME”:JAVA_HOME的内容是jdk安装目录。如小编安装的位置C:Program Files (x86)Javajdk1.7.0_60,并且后边不带分号,如下图:
2) 第二,检查CLASSPATH,这是一个jar包的调用。.;%JAVA_HOME%libdt.jar;%JAVA_HOME%lib ools.jar;(前面有点号和分号,后边结尾也有分号。或者可以写成“.;%JAVA_HOME%lib”如图所示,一样的效果。如下图:
3) 第三检查“PATH"变量是否正确,PATH变量很简单,就是jdk的bin目录的意思。%JAVA_HOME%in;
4) 安装了JDK的话,正常CMD下输入JAVAC时一定可以成功的。就会有如下信息提示
2.1:创建一个带有NativeC库的Android APP。
File -> New -> Project ->VistualGDB -> Android Project Wizard
选择Create a New App with a simple native library.
则会创建一个VS工程,这个工程包含Java文件和NativeC文件. C文件中包含JNI接口.
可以在C/C++ 程序中添加断点调试.
2.2: 使用VisualGDB和Net ADB调试程序:
如果Android设备使用USB线和开发机连接,则使用VisualGDB直接可以调试之。 GDBServer也由VisualGDB从NDK中Push到远端机器上。
但Sam在机顶盒项目中,使用网络ADB而非USB connect ADB. 测试了一下,在adt-bundle-windows-x86_64-xxxxsdkplatform-tools 目录下,利用adb 连接远端设备。
$adb.exe connect 10.0.0.7:5555
然后使用VisualGDB调试,则它会自动找到远端设备并正常调试。赞一个。
2.3: 创建一个纯NativeC 可执行文件并调试:
选中Create a command-line Android executable.
其实这个就是常作的Android Native C 可执行程序。
可以正常加断点,Debug。
其它还可以Clone NDK的例子程序,打开Eclipse 工程的程序等都可以正常使用。
在实际工作中,工程常是以下几种情况,
NativeC可执行程序依赖于 NativeC 动态或静态库。
Android App使用JNI调用NativeC的动态库,这个动态库又依赖于其它NativeC动态库。
现就这两种情况使用VisualGDB调试的情况尝试一下。
3.1:NativeC可执行程序调用NativeC 动态库。
以Sam一个工程: V4L2_Utils为例。它由V4L2_Utils.cpp声成一个动态库。最终被Main.cpp所使用。
3.1.1:尝试一:
创建了一个Native C可执行程序,注意,在Automatic Android.mk updating: 中选择:
The JNI folder contains multiple libraries or conditional stantements. You will have to edit android.mk manually.
也就是说,JNI目录内的文件,不要自动加入Android.mk中编译,如果需要,我们手动加入。
1. 修改Application.mk为Sam常用模式。
# Build both ARMv5TE and ARMv7-A machine code.
APP_PLATFORM = android-8
APP_ABI := armeabi-v7a
#APP_ABI := $(ARM_ARCH)
#Sam modify it to release
#APP_OPTIM := release
APP_OPTIM := debug
#APP_OPTIM = $(MY_OPTIM)
APP_CPPFLAGS += -fexceptions
APP_CPPFLAGS += -frtti
#sam modify it from gnustl_static to gnustl_shared
#APP_STL := gnustl_static
#APP_STL := gnustl_shared
APP_STL := gnustl_shared
#APP_CPPFLAGS += -fno-rtti
#
APP_CPPFLAGS += -Dlinux -fsigned-char
APP_CFLAGS += -fsigned-char
2. 把V4L2_utils.cpp, V4L2_Utils.h放到jni目录中。但不加入到工程中(否则会自动加入编译)
3. 修改Android.mk
# Generated by VisualGDB
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := TestNDK
LOCAL_ARM_MODE := arm
#VisualGDBAndroid: AutoUpdateSourcesInNextLine
LOCAL_SRC_FILES := TestNDK.cpp
LOCAL_C_INCLUDES :=
LOCAL_STATIC_LIBRARIES :=
LOCAL_SHARED_LIBRARIES :=
LOCAL_LDLIBS :=
LOCAL_CFLAGS :=
LOCAL_CPPFLAGS :=
LOCAL_LDFLAGS :=
COMMON_SRC_FILES := $(LOCAL_SRC_FILES)
LOCAL_STATIC_LIBRARIES := Camera_V4L2
include $(BUILD_EXECUTABLE)
include $(CLEAR_VARS)
LOCAL_ARM_MODE := arm
LOCAL_MODULE := Camera_V4L2
LOCAL_SRC_FILES := v4l2_util.cpp
LOCAL_CXXFLAGS := -D_GLIBCXX_USE_WCHAR_T -I./
LOCAL_LDLIBS := -llog
include $(BUILD_SHARED_LIBRARY)
编译,果然生成libCamera_V4L2.so , 和TestNDK. 但这个办法显然不是好办法。
因为调试时,只能调试主程序:TestNDK.cpp。 而无法调试动态库。且debug时,VisualGDB甚至不会自动把动态库push到开发板上。
3.1.2:尝试二:
建立两个工程,其中一个工程是Main.cpp生成可执行程序。
另一个工程是V4L2_Utils.cpp生成 动态库。
利用Vs工程的依赖方法让第一个工程依赖于第二个。
编译,一切正常。但可悲的是,visualGDB 还是不会自动把动态库push上去。 且它竟然没法export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./
导致无法调试。
这两个尝试其实都是失败的。难道VisualGDB只适合调试JNI下的NativeC库?
尝试三:
干脆把V4L2_Utils.cpp加入工程一。则不再生成动态库,直接合并入可执行文件中。这样则可以调试。
但这显然不是个好办法。无法满足真正的项目调试。