Android ContentProvider使用时出现的错误“java.lang.SecurityException: Permission Denial: opening provider ***”

AndroidAPK上自定义了一个ContentProvider,但是在调用者使用时出现的错误"java.lang.SecurityException: Permission Denial: opening provider ***"。

查询了半天才发现是由于在声明ContentProvider的时候没有声明android:exported="true"导致的。

从目前的测试情况来看,跟Android的版本有关系,目前看到在低版本的Android系统上面,这个如果不设置,默认是自动导出的,但是在高版本的Android上面,默认就是不导出了,这就导致一个问题,就是相同的APK在不同系统上面会出现不同的行为。因此要求必须显示指定这个字段

注意如下说明:

参考链接


Android真机使用Mockito-1.10.19+Dexmaker-1.2在Mock继承抽象父类的子类时报告错误“java.lang.AbstractMethodError: abstract method not implemented”

Android真机使用Mockito-1.10.19+Dexmaker-1.2Mock继承抽象父类的子类时报告如下错误:

父类代码如下:

子类代码如下:

测试代码如下:

在项目的build.gradle中的声明如下:

这个问题只在Dalvik虚拟机下面发生异常,相同的代码在ART下面是完全正常的。
导致问题发生的原因是Google提供的dexmaker库存在BUG导致的,而这个库,从Maven Center上看,自从2012年开始就没有提供过任何的更新了。
解决方法是不使用Google提供的dexmaker,而是使用com.crittercism.dexmaker修正过这个BUG的版本。

com.crittercism.dexmaker项目的GitHub地址是https://github.com/crittercism/dexmaker

Android上使用Mockito+Dexmaker报告错误“java.lang.IllegalArgumentException: dexcache == null (and no default could be found; consider setting the 'dexmaker.dexcache' system property) ”

Android上使用Mockito+Dexmaker,测试用例运行时,报告错误:

解决方法就是在调用Mockito之前设置环境变量"dexmaker.dexcache",如下:

参考链接


Mockito + Dexmaker on Android

Tomcat 7使用AJP协议导致AJP端口被意外暴露给外网

使用Ubuntu 13.10 Apache 2.2 通过 AJP 整合 Tomcat 7中的方法配置了通过AJP协议来通过Apache进行访问的代理。

但是最近发现Tomcat有时候会崩溃掉。刚刚开始以为是正常的OOM,后来分析日志,并没有找到相关的记录,反倒是发现如下内容:

于是感觉有些奇怪,因为AJP协议应该不会发生非常频繁的通信协议错误问题。结果尝试从外网连接TomcatAjp端口8009,发现竟然可以通过telnet连接成功!!说明端口意外暴露给了外网。

那么根据The AJP Connector中的介绍说明(注意address部分),如果没有指定IP地址的话,默认是绑定任意地址,这样就导致外网也可以访问这个端口。因此出于安全考虑,我们需要增加这个address的设置,并且绑定到127.0.0.1。最终结果如下:

而我在配置的时候,恰恰少设置了address="127.0.0.1".这个这种错误有些低级啊。

在Windows 7系统上编译运行体验Apache OFBiz-13.07.03

作为Apache基金会的赞助项目,OFBiz(全称为"Open for Business")是一套功能齐全的企业自动化套件,其中包含企业资源规划(简称ERP)、客户关系管理(简称CRM)、电子商务、内容管理、计费与费 率管理、供应链管理、制造资源规划以及企业资产管理等方案。OFBiz拥有丰富的说明文档及指导视频,其基于Java语言因此能够运行在任意支持Java SDK的系统当中,包括WindowsOS XLinux以及Unix

1.去OFBiz的官网http://ofbiz.apache.org/下载目前最新版本的13.07.03。下载完成后,是个zip格式的压缩包。解压压缩包到任意目录。

2.安装最新的JDK(要求最低是1.7,目前的1.8版本是可以正常使用的)。

完成后,直接访问http://localhost:8080/ecommerce即可看到如下页面:
ofbiz_index
其他的参考代码根目录下面的README.

参考链接


Ubuntu 16.04运行iLO-jirc.jnlp(.jnlp格式文件)

HP Gen8的远程控制支持.Net,Java Web Start,Java Applet三种控制方式,如下图所示:

hp_ilo_html
Windows下面首选是.Net方式,简单,快速,比较坑的就是必须在IE浏览器下面点击链接,在FireFox,Chrome中点击这个链接都是无效的。那么如何在Ubuntu 16.04下面运行远程控制呢?答案就是使用Java Web Start。但是Java Web Start下载下来的是iLO-jirc.jnlp这个文件,那么如何运行这个文件呢?如下方式即可:

WDMyCloud中使用Subversion Server不支持中文路径问题的解决

WDMyCloud中使用Subversion Server的时候,发现工程名字为中文的情况下,无法下载代码,此时Subversion客户端报告:

解决方法是在启动Subversion Server之前指定语言为中文,如下:

其他的的参考如下链接:
WD MyCloud中设置服务在开机时候自动启动

Android Studio编译出的APK中一直包含android:debuggable="true"

最近遇到一个比较奇葩的事情,就是编译出来的APKAndroidManifest.xml中的application标签中一直包含android:debuggable="true"。不管是release版本,还是debug版本,不管如何设置,最终生成的文件中的调试选项一直是处于开启状态。

一时间竟然有些无从下手的感觉。首先确认我们自己的配置文件是没有问题的,那么这个现象一定是引入了某个aar中引入的AndroidManifest.xml中存在这个android:debuggable="true",导致Android Studio在最终合并AndroidManifest.xml文件的时候,把这个选项给合并进来了。

那么我们既然已经知道引入的地方,因此就只需要针对这种情况进行剖析即可了。

执行gradlew build之后,我们在app\build\intermediates\exploded-aar目录下面可以找到我们引入的全部的依赖的aar。我们只需要逐个分析引入的aar包的AndroidManifest.xml文件即可。

那么比较奇葩,是奇葩在哪里呢? 正常情况下,我们引入一个aar包,需要在build.gradle中声明如下:

但是我们从真正的配置选项中看到的却是

按照一般的理解,我们如果没有设置@aar,那么Android Studio应该去下载对应的jar包才对。但是我们从实际的编译过程中看到,Android Studio在没有指定@aar的情况下,依旧默认去服务器上先尝试下载对应的aar,只有当aar找不到的时候才会去下载对应的jar包。而恰好,我们服务器上面两者都是存在的。于是出现了乌龙事件,本来只是需要下载jar包,结果却引入了一个莫名的aar包。而这个aar的开发同学又没有考虑到这种情况,以为用户只会用他提供的jar包。
解决方法还是比较简单的,就是明确告知Android Studio,我们需要的是jar包,也就是增加@jar。如下:

相关参考链接


Android Studio: Why is Release Build debuggable?