利用NDK做开发,因为各种原因的不小心,导致了闪退问题,没有stack的话,很难查到问题的所在.这时候ndk-stack出场了. 先看看如下DUMP信息: ********** Crash dump: ********** Build fingerprint: 'OPPO/A33/A33:5.1.1/LMY47V/1390465867:user/release-keys' pid: , tid: , name: Thread- >>> com.example.dctool <<

ndk编译c++库,然后通过jni调用实现重要代码封装,是安卓应用中最常用的技术,一方面可以将重要的代码实现隐藏,防止泄漏,也可以提高打包速度. ndk里面的sample文件夹中有很多实用的例子,其中hello-jni有一个编译c++的例子. 首先,创建一个jn文件夹,文件夹内放置Android.mk和Application.mk两个文件,Android.mk文件主要是 写入编译的c++代码,打包的库名,打包的库类型(静态库or动态库),引用的模块等等.Application.mk 是主要表示打

Boost库是一个可移植.提供源代码的C++库,作为标准库的后备,是C++标准化进程的开发引擎之一. Boost库由C++标准委员会库工作组成员发起,其中有些内容有望成为下一代C++标准库内容.在C++社区中影响甚大,是不折不扣的“准”标准库.Boost由于其对跨平台的强调,对标准C++的强调,与编写平台无关.大部分boost库功能的使用只需包括相应头文件即可,少数(如正则表达式库,文件系统库等)需要链接库.但Boost中也有很多是实验性质的东西,在实际的开发中实用需要谨慎. 在Android的

ndk_r9编译通过,里面带了自动生成代码的脚本(tool/createPBFile.bat). 下载地址

Android.mk是这样的 LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := lua LOCAL_SRC_FILES := lua.cpp MY_FILES := $(wildcard $(LOCAL_PATH)/lua/*.c) MY_FILES := $(MY_FILES:$(LOCAL_PATH)/%=%) LOCAL_SRC_FILES += $(MY_FILES) # includes LOCAL_C

1.jni 首先clean Project,在makeProject生成对应的class文件 然后点出命名框,输入命令: cd app/build/intermediates/classes/debug 在输入: javah -classpath . -jni 包名.类名(要生成jin头文件的类的完整路径) 或者直接是这样 javah 包名.类名(要生成jin头文件的类的完整路径) 2.ndk 在当前的jni文件目录下   输入ndk-build即可   前提要下载ndk

公司的手游项目,使用的是基于cocos2d-x绑lua的解决方案(参数quick-x的绑定),虽然使用了lua进行开发,更新很爽了,但是崩溃依然较为严重,从后台查看崩溃日志时,基本上只能靠"猜"来复现bug.更为郁闷的是很多时候并没有使用log输出,在崩溃日志里还无法查看大概在哪一步操作崩溃的-   后来在网上搜索了一下,受到一点启发,lua代码在执行的时候可随时调用debug.traceback()方法来获得调用栈的字符串信息,如下图所示:   而c++导出方法给lua调用,是使用t

SpringBoot在项目启动时如果遇到异常并不能友好的打印出具体的堆栈错误信息,我们只能查看到简单的错误消息,以致于并不能及时解决发生的问题,针对这个问题SpringBoot提供了故障分析仪的概念(failure-analyzer),内部根据不同类型的异常提供了一些实现,我们如果想自定义该怎么去做? FailureAnalyzer SpringBoot提供了启动异常分析接口FailureAnalyzer,该接口位于org.springframework.boot.diagnosticspack

error显示的log堆栈信息,是从最深层(最内层)的堆栈信息开始由内向外打印的. error显示的log堆栈信息,是从最深层(最内层)的堆栈信息开始由内向外打印的. error显示的log堆栈信息,是从最深层(最内层)的堆栈信息开始由内向外打印的. 即:A调用B,B调用C,C堆栈信息报出error了. 那么就会开始从最内层开始打印这个方法的堆栈信息, 分别是C B A SPRING mvc抛出error,一层层打印堆栈信息,直到最外层的spring dispatcherservlet,再给到容

使用android的breakpad工具 使用这个工具需要下载Breakpad的源码,然后进行编译,编译之后会生成两个工具 我们使用这两个工具来解析奔溃的位置.这里我们可以下载已经编译好的工具 下载地址是:链接:http://pan.baidu.com/s/1jIiU5cq 密码:wy6f 你把对应的工具下载完成后需要上传到对应的linux环境下才能使用 二.生成转换工具1.下载BreakPad源代码命令行输入:svn checkout http://google-breakpad.google

1.protobuf 编译过程 前提: 确保自己电脑上已经安装了cygwin + ndk, 并且NDK能够编译hello-jni成功 1.1 把protobuf 压缩包解压到protobuf文件夹下 1.2 在protobuf文件夹下新建jni文件下 1.3 把protobuf文件夹下的src文件夹复制一份到jni文件夹下 1.4 在jni文件夹下新建Android.mk文件并且在里面添加如下内容 LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS

原文链接:http://blog.csdn.net/acm2008/article/details/41040015 当用NDK编译的库在运行加载时报如下错: dlopen("/data/data/xxx.xxx.xxx/lib/libxxx.so") failed: dlopen failed: cannot locate symbol "__exidx_end" referenced by "libxxx.so"... 解决办法如下: 在你报

当用NDK编译的库在执行载入时报例如以下错: dlopen("/data/data/xxx.xxx.xxx/lib/libxxx.so") failed: dlopen failed: cannot locate symbol "__exidx_end" referenced by "libxxx.so"... 解决的方法例如以下: 在你报错的库libxxx.so的编译脚本Android.mk请加上:LOCAL_LDFLAGS += -fuse-

1.背景: 在开发人员进行项目开发和调试代码时,有一个非常困扰的问题,就是程序在调试运行过程中会莫名其妙地异常退出.由于导致异常退出的问题非常多,因此在面对这种无任何提示的异常退出时,开发人员会非常无奈.因为他需要考虑最近的那些更改有可能导致这个错误的发生,万不得已,可能就需要把代码回退到某个版本,然后去慢慢验证了.这当然是非常影响工作效率的. 后来,项目经理前段时间介绍了一个新的库,用这个库可以非常准确地定位上一次奔溃的出错位置.这样开发人员便可以在奔溃的位置添加断点,进行调试. 自从知道有这

利用Android NDK编译动态库,在C文件中调用了两个JNI函数:JNI_GetDefaultJavaVMInitArgs和JNI_CreateJavaVM.编译的时候始终报以下错误: XXX: undefined reference to `JNI_GetDefaultJavaVMInitArgs' XXX: undefined reference to `JNI_CreateJavaVM' 看了网上很多人的解答,基本都是添加libjvm.so或者libnativehelper库.尝试下,

一直以为android ndk编译x86 so库可以在linxu下运行,结果我试了几次都行不通.后来想了一下,android ndk编译的库应该只能在android设备或模拟器上运行才有效,后来改用 cmake编译so. 贴上一段简单编译so的过程: set(SRC classes/MD5.cpp classes/main.cpp ) set(CMAKE_C_FLAGS_DEBUG "-g -rdynamic -Wall") set(CMAKE_CXX_FLAGS_DEBUG ${CM

前言 ​ 采集应用程序奔溃信息,主要分为以下两种场景: ​ NSException 异常 ​ Unix 信号异常 一.NSException 异常 ​ NSException 异常是 Objective-C 代码抛出的异常.在 iOS 应用程序中,最常见就是通过 @throw 抛出的异常.比如,常见的数组越界访问异常. 1.1 捕获 NSException ​ 我们可以通过 NSSetUNcaughtExceptionHandle 函数来全局设置异常处理函数,然后手机异常堆栈信息并触发响应的事件

在android程序中使用NDK编译后的ffmpeg库的时候出现了如下错误: jni/libs/libavutil.a(mem.o): in function av_malloc:libavutil/mem.c:95: error: undefined reference to 'posix_memalign' 上网查阅,发现是由于android系统一开始并不支持posix,后来增加了对posix的支持. 这个问题出现的主要原因有两个: 1.编译APP的时候指定的APP_PLATFORM 过低

目录: 手工编译动态库 ndk-build编译动态库(Eclipse环境)   手工编译静态库 老规矩还是先手工操作,知其然并知其所以然   需要用到的核心命令: gcc -g -c -fpic -Wall mod1.c mod2.c mod3.c gcc -g  -shared mod1.o mod2.o mod3.o -o libfoo.so gcc -g  -fpic -Wall -shared mod1.o mod2.o mod3.o -o libfoo.so   程序运行会优先从系统目

在eclipse工程目录下建立一个jni的文件夹 在jni文件夹中建立Android.mk和Application.mk文件 Android.mk文件: Android提供的一种makefile文件,用来指定诸如编译生成so库名.引用的头文件目录.需要编译的.c/.cpp文件和.a静态库文件等.详见附件中的Android.mk. Application.mk文件: 定义了项目的一些细节,比如APP_ABI := x86(编译X86平台库).APP_PLATFORM := android-9(使用

LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := live555 MY_SRC_PATH := $(LOCAL_PATH)/ MY_All_Files := $(shell find $(MY_SRC_PATH)/.) MY_All_Files := $(MY_All_Files:$(MY_SRC_PATH)/./%=$(MY_SRC_PATH)%) MY_C_CPP_LIST := $(filter %.cpp