由于是小众的，所以网络中关于这方面的资料比较少。这几天由于工作原因，我有幸接触到 Add-on，因此把这方面的知识进行了汇总，整理成如下内容。这些知识来自于我对 sample 示例的理解，并经过项目实践验证，我竭力保证无误，但差错之处也可能存在，如发现，请指正。

以下内容将分成若个步骤：

1. 添加模块；
2. 添加资源文件；
3. 加入编译脚本；
4. 发布；

在阅读下面内容前，先假设是对 $ANDROID_HOME/device/sample 进行修改。

一、添加模块（Add Module）

在自己 product-name 目录下建立 frameworks 文件夹，从 sample 中拷贝 Android.mk 文件到 frameworks。

依照 sample 的方式，在 frameworks 路径下，建立 PlatformLibrary 文件夹，再次从 sample/frameworks 中拷贝 Android.mk 文件，并将其中的 LOCAL_MODULE 和 LOCAL_DROIDDOC_OPTIONS 修改为自己中意的名字。–这里值得注意的是，LOCAL_MODULE 变量被定义两次，第一次是 library，第二次是 document。

依照 sample/frameworks/com.example.android.platform_library.xml 的形式创建自己的 XML 文件，文件名称、XML 内容中 name 和 file 保持和 LOCAL_MODULE(library) 一致。

完成上述操作之后，建立 java 文件夹，并将自己创建的源文件（java）放入到其中，这里不再赘述。

二、添加 Overlay(Add Resoruce)

代码中可能需要访问图片、字符串等资源，但是这些在原有的 Android 中没有，因此需要想办法自行加入，Android 对此提供了两种方式。

第一种就是直接在 $ANDROID_HOME/framework/base/core/res/res 下进行操作，添加文件，追加字符串。这种方式虽然简单，但是破坏了原有的“纯洁性”，因此不予推荐，在第三节修改编译脚本中我采用了第二种方式。

第二种方式就是使用 overlay。在 product-name 目录下建立 overlay 文件夹，依照 framework 的结构建立各级目录，例如想添加图片，可以先依次建立 base/core/res/res/drawable，然后将图片置于其中，同样可以建立 layout 等文件夹。

如果要添加字符串或者 style 资源，就要稍微复杂一点，需要使用 add-resource 来让系统“明白”新添加的内容。

<?xml version="1.0" encoding="utf-8"?>
<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">
    <add-resource type="string" name="numwheel_year" />
    <!-- Strings for number wheel -->
    <string name="numwheel_year">年</string>
</resources>

如果没有 add-resource，则会遇到这样的信息：Resource at numwheel_year appears in overlay but not in the base package; use to add.

完了以后，就可以用使用 com.android.internal.R 来访问这些资源了。

三、加入编译脚本（Add build script）

在自己 product-name 目录下建立 sdk_addon 文件夹，并依照 sample/sdk_addon 分别拷贝 manifest.xml 和 hardware.xml，注意 manifest.xml 中的内容必须要根据之前第一步的变更同步修改。

接下来最关键，也是最容易出错的环节到了，那就是修改自己 product 的 mk 文件，需要修改 PRODUCT_PACKAGES、PRODUCT_COPY_FILES、DEVICE_PACKAGE_OVERLAYS 的值，定义 PRODUCT_SDK_ADDON_NAME、PRODUCT_SDK_ADDON_COPY_FILES、PRODUCT_SDK_ADDON_COPY_MODULES和PRODUCT_SDK_ADDON_DOC_MODULE。修改和定义的区别就在于，前者使用”+=”，后者使用“:=”。这些变量的值可以参照sample示例。

由于 sample 的示例中没有出现 DEVICE_PACKAGE_OVERLAYS，所以我这里特别解释一下它的作用，除了刚才为 add-on 增加资源以外，它还起到的作用就是替换掉原来的framework中的资源，比如图片等等，惟一的要求就是必须建立和原来图片位置相同的路径。和 add-on 不同的是，如果你是替换原来资源，那么是不用 add-resource 的。DEVICE_PACKAGE_OVERLAYS 的值就是 overlay 文件夹的路径，不包含 $ANDROID_HOME，到 overlay 一级即可。

完成了修改以后，使用 make PRODUCT-product-name-sdk_addon 进行编译。当然也可以直接执行 make sdk_addon，但是需要注意在此之前，你需要使用 chooseproduct 指定 product-name。执行完毕以后，会得到一个 zip 文件，这个就是 add-on 了。

四、发布（Relase）

完成上面的环节以后，剩下临门一脚了。所谓发布，就是通过诸如 HTTPD 一类的 HTTP SERVER 将资源公布出去。从 http://httpd.apache.org 下载 httpd，如何安装以及修改监听端口可参看其 document，在此不予赘述。

现在把刚才生成的 zip 文件，放置到 htdoc 目录下。并且创建一个 repository.xml，其内容和形式参看 https://dl-ssl.google.com/android/repository/repository.xml，我把它删减一下得到以下内容：

<sdk:sdk-repository
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:sdk="http://schemas.android.com/sdk/android/repository/2">
 
    <sdk:add-on>
        <sdk:name>Google APIs</sdk:name>
        <sdk:api-level>3</sdk:api-level>
        <sdk:vendor>Google Inc.</sdk:vendor>
        <sdk:revision>03</sdk:revision>
        <sdk:description>Android + Google APIs</sdk:description>
        <sdk:desc-url>http://developer.android.com/</sdk:desc-url>
        <sdk:uses-license ref="android-sdk-license" />
        <sdk:archives>
            <sdk:archive os="any">
                <sdk:size>34908058</sdk:size>
                <sdk:checksum type="sha1">1f92abf3a76be66ae8032257fc7620acbd2b2e3a</sdk:checksum>
                <sdk:url>google_apis-3-r03.zip</sdk:url>
            </sdk:archive>
        </sdk:archives>
        <sdk:libs>
            <sdk:lib>
                <sdk:name>com.google.android.maps</sdk:name>
                <sdk:description>API for Google Maps.</sdk:description>
            </sdk:lib>
        </sdk:libs>
    </sdk:add-on>
 
    <sdk:license type="text" id="android-sdk-license">
        This is the Android Software Development Kit License Agreement.
    </sdk:license>
</sdk:sdk-repository>

接下来的事情，就是替换掉里面的 Google 信息为自己，大部分可以从它们的名称中理解其含义，例如 size 是指文件大小，你可以使用ls –l来查看文件大小。checksum 则要麻烦一些，执行 sha1sum ZIP.zip，即使用 sha1 对刚才生成 zip 文件生成校验码。

修改完成以后，通过浏览器访问 http://IP-address:port/repository.xml，确认是否 OK。确认以后，打开 Android SDK and AVD Manager，点击左侧 Available Packages，选择 “Add Add-on Sites” 填入URL，接下来的安装就不费口舌了。完成以后，你可以在 sdk 下的 add-ons 目录下看到刚刚安装的 add-on。

捎带提一下，应用开发方面使用该 add-on 时，调整工程的 Project Build Target 设定即可。

Inner Class? Static Nested Class?

如果不是去读 Android 的源码，我不会想到在自己的 toolkit 里还有 inner class 这么一把小“锉刀”。如果不是发现non-static variable this cannot be referenced from a static context，我不会想到去查 inner class 的知识，也就不会发现自己对 inner class 的理解一直都是错误的。

七年前学习 Java 时，明白一个 class 可以定义在另外一个 class 里，编译后各自生一个后缀为 .class 的文件，此后很少用到这种方式，直到看到 Android ，叹其大量运用 inner class。当我试图对某个 inner class 进行修改，删去其类修饰符（class modifier）中的 static 时，Eclipse 给出了这样的提示：

No enclosing instance of type Hello is accessible. Must qualify the allocation with an enclosing instance of type Hello (e.g. x.new A() where x is an instance of Hello).

顿时我糊涂了，明明看到诸如 EnclosingClass.InnerClass inner = new Enclosing.InnerClass() 一类的写法大行其道，怎么我写出来就出错了呢？当我按照提示，首先获得 EnclosingClass 的实例 outter，然后再EnclosingClass.InnerClass inner = outter.new InnerClass()，编译器告诉我：OK！

在代码编译通过并正常执行后，我对自己的 Java 知识产生了怀疑：我对 inner class 的理解是充分和正确的吗？在质疑中，我找到《The Java Language Specification》对 inner class 的定义：

An inner class is a nested class that is not explicitly or implicitly declared static.

虽然有了上述定义，可还是不清楚，其采用了一个新的名词 nested class 来解释，可是 nested class 又是什么呢？继续来看《The Java Language Specification》：

A nested class is any class whose declaration occurs within the body of another class or interface. A top level class is a class that is not a nested class.

一个 class A 如果定义在了另一个 class B 或 interface B 里，那么这个 class A 就是 nested class，class B 或 interface B 则被称为 enclosing class。至于 class A 是定义在了 class B 或 interface B 的什么地方，例如 method 和 constructor，则是没有限制的。再打开《The Java Tutorial》，找到 nested class 的相关表述：

Nested classes are divided into two categories: static and non-static. Nested classes that are declared static are simply called static nested classes. Non-static nested classes are called inner classes.

恍然大悟，原来我理解中的 inner class 其实是 nested class，只有non-static 的 nested class 才能被称为 inner class，否则就是 static nested class！《The Java Tutorial》把 nested class 笼统分为两类，而更深入一点的话，inner class 还可以继续划分成三类：local class、anonymous class、non-static member class。根据《The Java Language Specification》的描述，local class 和 member class 分别定义如下：

A local class is a nested class that is not a member of any class and that has a name.

A member class is a class whose declaration is directly enclosed in another class or interface declaration.

由此看来，简单把 inner class 等同于 non-static member class 也是不正确。焦点重新回到 inner class 上，了解一下 inner class 的部分规则：

Inner classes may not declare static initializers (§8.7) or member interfaces. Inner classes may not declare static members, unless they are compile-time constant fields (§15.28).

It is a compile-time error if a local class declaration contains any one of the following access modifiers: public, protected, private, or static.

An anonymous class is never abstract (§8.1.1.1). … An anonymous class is always implicitly final (§8.1.1.2).

inner class 不能被声明为 static，不能有 static initalizer（静态初始化块），不能是 interface（因为 member interface 一律都是 static 的），不能声明 static member，–compile-time constant field （诸如 static final int i = 0）除外。an inner class is associated with an instance of its enclosing class ，换句话说，没有 enclosing class 的 instance 就不会有 inner class 的 instance，我想 enclosing class 和 inner class 之间可以用 UML 中的 composition 来表示。

尽管语言设计者给 inner class 了这么多的限制，但是也不忘给它一些弥补，–inner class 可以访问 enclosing class 的所有 member，包括 method、field、nested class、nested interface，哪怕它是 private 也可以。但是有一个前提，inner class instance 能够访问 enclosing class instace，因为并非所有的 inner class 都能访问的到，比如在声明在 static method 中的 local class。

相较之下，static nested class 的 instance 则是可以隔离 enclosing class 而独立存活的，但是它 cannot refer directly to instance variables or methods defined in its enclosing class。

至此，对 nested class 和 inner class 的探索告一段落，虽然前前后后翻阅了不少的资料，修正了此前的片面理解，但是绝算不上深刻理解。最后用一朋友的签名来作结：越学越知道要学。

Network Is Unreachable

去年撰写过一篇博客，解释了如何将默认下载地址从 https 变更为 http，提到其中的原因是由于Gnome 和 SWT 的 BUG，这些小问题往往给人带来很不好的使用体验。事情过去一年多了，由于一些原因，又要安装 Linux 版的 Android SDK，发现去年的问题依旧存在，不幸的是，除此之外，又发现了一个新问题。

问题表现为，当采用 http 下载时，窗口提示：Failed to fetch URL http://dl-ssl.google.com/android/repository/repository.xml, reason: Network is unreachable。－－确信这在去年是没有发生的，那么问题既然已经发生了，就别抱怨了，把精力集中在如何解决它，了解发生的原因。

没有 Log，没有 Debug，还好我们有搜索引擎。How to resolve an issue “Network is unreachable” in Java applications 和 Solved network unreachable when installing Android 是我找到的两篇博客，给了我很大的帮助，根据他们的办法，这才使得问题顺利解决。

问题的解决办法很简单，在 Terminal 执行以下命令（root角色）：

eniac:/home/xuhj# sysctl -w net.ipv6.bindv6only=0
net.ipv6.bindv6only = 0

这样做无需 reboot，当即可解决问题，不过等到下次开机之后，问题依旧，那就采用修改配置文件（/etc/sysctl.d/bindv6only.conf）的方式来一劳永逸吧。在我的电脑上，该文件只有一行有效信息，确认 net.ipv6.bindv6only 的值为1。

# This sysctl sets the default value of the IPV6_V6ONLY socket option.
#
# When disabled, IPv6 sockets will also be able to send and receive IPv4
# traffic with addresses in the form ::ffff:192.0.2.1 and daemons listening
# on IPv6 sockets will also accept IPv4 connections.
#
# When IPV6_V6ONLY is enabled, daemons interested in both IPv4 and IPv6
# connections must open two listening sockets.
# This is the default behaviour of almost all modern operating systems.
 
net.ipv6.bindv6only = 0

让我遗憾的是，找的到解决办法，却找不到问题原因。从表象上来看，这个问题在 Eclipse 也能重现，那么是不是 SWT 的原因呢？从上面配置文件里的注释可以看出，如果选项被打开，即赋值为1，IPV6和IPV4是分别打开监听 socket，如果关闭它，则IPV6也可以收发IPV4的数据（原文为traffic，理解可能有误）。显然，如果关闭这个选项会好一些。

Linux 就是这样“神奇”，你永远不知道接下来的一个问题会是什么。好在自己已经不再像以前那样急躁，现在能耐下心来跟踪问题了。

host C: libclearsilver-jni <= external/clearsilver/java-jni/j_neo_util.c
In file included from /usr/include/features.h:378,
                      from /usr/include/string.h:26,
		      from external/clearsilver/java-jni/j_neo_util.c:1:
/usr/include/gnu/stubs.h:9:27: error: gnu/stubs-64.h: No such file or directory
make: *** [out/host/linux-x86/obj/SHARED_LIBRARIES/libclearsilver-jni_intermediates/j_neo_util.o] Error 1

兵来将挡，水来土掩，用关键字 android “error: gnu/stubs-64.h: no such file or directory” 来搜一下吧，发现搜索结果寥寥无几，看样子问题比较新，其中有一个 CSDN 的链接，就顺手点了过去。帖子反映的问题和我一模一样，不过它的分析给了我一些提醒。

从错误信息入手，追踪到/usr/include/gnu/stubs.h，看到如下代码：

#if __WORDSIZE == 32
# include <gnu/stubs-32.h>
#elif __WORDSIZE == 64
# include <gnu/stubs-64.h>
#else
# error "unexpected value for __WORDSIZE macro"
#endif

顺着 WORDSIZE，进入/usr/include/bits/wordsize，发现：

#if defined __x86_64__
# define __WORDSIZE	64
# define __WORDSIZE_COMPAT32	1
#else
# define __WORDSIZE	32
#endif

结合报错的信息，可以知道这里一定是有定义__x86_64__，执行一下 uname -a 可以确认 OS 明明是x86，为什么会__x86_64__呢？追根溯源， Android 源码或许能露出蛛丝马迹。

果不其然，从 android.git.kernel.org 的 platform/external/clearsilver.git 上，看到5天前，有个 Ying Wang 的家伙提交一个修改：Fix 64-bit clearsilver shared library issue，参看这里，修改内容中 java-jni/Android.mk，和出现本次问题的路径 java-jni/j_neo_util.c，同属一个父目录，看样子有点关系，查看 Android.mk 的修改内容，发现做了如下修改：

+# This forces a 64-bit build for Java6
+ifneq ($(filter 1.6%,$(java_version)),)
+    LOCAL_CFLAGS += -m64
+    LOCAL_LDFLAGS += -m64
+endif

当发现你使用Java6时，它将强制使用64-bit，我想这就能解释__x86_64__出现的原因。那么既然它要64-bit，我就满足它。首先要解决 gnu/stubs-64.h: No such file or directory，解决这个问题需要执行以下命令：

[xuhj@eniac mydroid]$ apt-get install libc6-dev-amd64

完成以后再执行 make，发现有错误：

/usr/bin/ld: cannot find -lstdc++

那就继续满足它：

[xuhj@eniac mydroid]$ apt-get install g++-multilib lib64stdc++6

还是不行，又发生下面的错误：

/usr/bin/ld: cannot find -lz

再来执行命令：

[xuhj@eniac mydroid]$ apt-get install lib64z1-dev

OS for development

每一年 Eclipse 都会在社区内部进行一项调查，来了解开发者的动态，前不久他们公布了2010年的调查报告，从中可以看到一些有趣的趋势。

先从大的方面来看，我觉得有三个亮点，首先是越来越多的开发者采用 Linux 做为自己的 OS，我想这和 Eclipse 社区成员大多是开源“粉丝”这一现状有关，Eclipse 本身是 Open Source，它的用户绝大部分不会是 .net 程序员，因此不是非要使用 Windows。以我为例，Java, PHP, Python, Ruby, C, MySQL 是我经常接触到的技术，个人环境使用 Linux 完全可以胜任，不过公司环境还是使用 Windows，–这不是我能够控制的。

Linux continues to gain market share on the developer desktop. Close to one third of developers (33%) now use Linux as their primary development operating system; this is up from 20% in 2007. In parallel Microsoft Windows has dropped from 74% in 2007 to 58% in 2010.

其次，开源解决方案依旧赢得开发者的青睐，JQuery 和 Spring 分别是构建 RIA (Rich Internet Application) 和Server Side Application 最受欢迎的 Framework。

最后，云计算得到越来越多的认可和采用，已经采用和将要采用的比例接近三成。从调查结果来看，Amazon 和Google 在云计算上深得人心，但是目前在这个领域，每个公司各自为战，一个概念，不同解读，各有各云，Amazon EC2，Google App Engine，Salesforce 分别代表了目前三大观点。

Deploying to a cloud infrastructure is a current option or planned option for 29.5% of the respondents. Amazon EC2, Google App Engine and a private cloud are the popular choice for those considering a cloud infrastructure.

在 Java 使用情况方面，大部分人已经选择了 Java SE 1.5 或 1.6，这在 Java 7 迟迟不肯露面的情形下再正常不过。但是随后一项数据让我十分惊讶：

For deployment, they typically choose the Sun Hotspot JVM (69.8%) or Open JDK (21.7%).

Open JDK 的比例居然能够占到21.7%，真是出乎我的意料，我一直没有搞懂 Open JDK 和 Sun JDK 的关系，就像无法理解 Open Solaris 和 Sun Solaris 一样。

还有一项数据，Development Methodology，比较有幽默感，先来看有哪些选项。None, Scrum, Iterative Development, Don’t know, Agile Modeling, Extreme Programming (XP), Test Driven Development (TDD), Waterfall Feature Driven Development (FDD), Rational Unified Process (RUP), ISO 9000, Lean Development, Other。这里面的都是些热门词汇，我今天才知道还有FDD、ISO 9000和Lean Developemnt，剩下的名词里，觉得眼熟，但讲不出一二三。Close to a third responded that they didn’t use methodolgy (25%) or didn’t know (7.8%)，我应该是属于这三分之一。

在 Source code management (SCM) 方面，SVN 继续独占鳌头，CVS 老态龙钟，失去的份额被 Git 和 Mercurial 这两个分布式 SCM 工具占据。Change management system 的一二名分别是 JIRA 和 Bugzilla。Build and Release Management 的头名也依旧是 ANT。

最后，Applicaiton Style 的数据是我比较关注的，server-centric (26.9%)，web (26.9%)，desktop application (21%)。其中desktop 居然还有21%的比例，超出意料，至少我接触到的软件里采用 Swing/SWT 来开发的少之又少。server-centric 和 web 这两个选项，我认为是很难区分的，二者应该相互依存的关系，不知道当初是怎么定义的，因此我无法从中做出分析。

解读这份报告，我的目的是想知道老外们现在是怎么想的，他们在关注什么，在做什么，毕竟国内的软件理念、方法还是要落后国外至少五年左右，看看国外的现在，大概可以预测国内的未来。