【51CTO 6月23日外电头条】早在2009年，Oracle公司就斥资74亿美元收购了在Unix服务器硬件领域光彩夺目的制造企业Sun Microsystems 。许多人当时都在猜测谷歌是否也是此次竞购的买家之一。谷歌的资金储备无疑是雄厚的，不过真正的问题在于收购的理由:许多分析人士都认为Sun公司的黄金时期已成往事，谷歌并没有充分的理由将其招至麾下。

当然，现在Oracle公司已经拥有了与Java相关的一切专利及版权(Java这项技术最初正是由Sun公司所创立的)，而谷歌也极有可能为自己的犹豫付出代价:尽管并未取得授权，谷歌的Android系统中仍然用到了Java技术。根据目前的情况来看，Oracle公司的赢面相当大，无论是即时生效的罚款裁决、还是根据Android平台的实际盈利按百分比计费，当初付出的74亿美元收购金额中的很大一部分恐怕都要由谷歌来承担了。

Oracle公司从Android盈利中强插一脚的现状并非谷歌应当收购Sun公司的惟一理由。换句话说，这实际上应该被称为战略失误。这种失误不仅使谷歌费尽心力所打造的标准化软件开发平台在竞争前景方面蒙上了一层阴影，更动摇了近年来苹果及Anroid得以借势腾飞的这场设备革命的根基。

为了公平起见，51CTO认为历史上由并购活动所造成的巨大失误屡见不鲜。微软在这方面可谓“久经考验”了，这也正是作者一直反对微软收购雅虎的部分原因。网络电视并购事件最终带给我们的是微软IP电视，即Mediaroom的领先地位。当然，这里所谓的“领先”是指我们等了八年以上才见到真正可行的IP电视平台搭建技术，只是因为这套技术要保证能被微软的其它电视及视频相关技术所兼容。说到这，合并史上的典型失败案例该登场了:微软斥资5亿美元收购Danger公司。这家公司的创始人之一安迪·鲁宾(Andy Rubin)如今在为谷歌工作，而他所负责的正是Android项目。Danger公司的资源一直集中在前途未卜的KIN上，这是一款曾经对微软Windows Phone 7造成过相当威胁的设备。

不过平心而论，并购也并不总是带来灾难。谷歌对YouTube耗资10亿美元的收购就是标准的成功范例。当然，带宽成本的局限使得谷歌很难从YouTube项目本身上盈利，但YouTube作为互联网视频提供者中的领军品牌，肯定能够在其它诸多方面向谷歌回馈丰厚的利润。而且连IP电视及智能手机也将支持访问YouTube当作一项基本功能。

另外，尽管小史蒂芬·沃恩(Stephen J. Vaughn)绝对不会认同，但作者还是觉得Skype并购案会被证明是一笔好买卖。要重新建立一套像Skype那样深入人心的视频及语音通讯交流体系绝不容易，而且事实上Skype原有的用户协议对使用者来说的确在理解及接受方面造成了不小的困扰。51CTO认为Skype能够为微软提供的潜在优势正如YouTube网站能够提供给谷歌的那样显著，至少在视频及语音通讯领域。当然，潜在可能性与现实之间仍然存在巨大的差距，最终结果如何我们还是拭目以待吧。

谷歌当初有意收购Sun Microsystems公司在很大程度上是为了实现其提升自有软件平台的野心。Solaris系统对谷歌意义有限，而且有可能会被那些关注客户硬件情况的买家(Oracle公司就是主要候选人之一)单独拍下。Sun公司的软件才是重中之重，他们自主研发或是拥有的软件能够为任何一家企业在.NET或是Objective-C /Cocoa 方面提供进行开发所必备的强大API;不仅如此，这些软件同时提供了强大的办公套件，能够以特殊的方式对自己的在线文字处理工具进行补充及增强。这两个方面对微软来说绝对是实实在在的威胁，因为它们所针对的正是微软公司立足的根本(即Windows系统平台及Office办公软件)。

假如当初是谷歌拍到了Java，他们无疑会为其提供特殊的发展空间，类似一款API，旨在帮助这项已经相当流行的技术进一步普及。大多数刚刚走出校门的程序员对这款平台非常熟悉，而且Java在包括电视及移动设备在内的诸多领域都具备深厚的覆盖基础。当然，谷歌同时也不会停止对其它开发技术的支持或是放缓将应用程序客户端推向网络接口的脚步。无论如何，即使在客户端领域，本地应用程序也还有不少潜力可供挖掘。Andy Rubin以及Android团队很清楚这一点，这也是他们在开发技术方面选择了Java，而不是像Palm在Web OS项目中那样选择HTML/CS****S/JavaScript之类的原因。

这样一种定位如今可以说恰逢其时。微软眼下正积极筹备自己的手机及平板设备，而确定要应用在这些设备上的未来计算平台都不是微软自家出品。

进一步来说，微软正为其用户界面战略酝酿一套大规模的改革方案，这其实给那些与微软公司向来保持亲密合作关系的开发商们带来了不小的压力。微软最近发布的Windows 8新基础概念吸引了很多人。开始屏幕将支持那些由HTML、CS****S以及JavaScript所编写的应用程序，这不仅颇具趣味性、更是一种重大进步。而Windows开发商们则注意到，.NET似乎成了被遗弃的孤儿。那些由.NET所开发的应用程序在全新的Windows 8桌面系统上将无法继续保持任何具有倾向性的特权。更让人费解的是，微软拒绝对上述情况做出明确回应，无论是证实还是否认。

也许，正如许多人所主张的，这完全是对谣传的一种肆意夸大。然而，微软公司在与开发商的交流方面一直做得很到位，像这样不同于以往的“失误”反而进一步加剧了.NET将被打入冷宫这类传言的可信程度。正如Tim Anderson最近在The Register网站上所指出，“在外界看来，好像微软的服务器及工具部门在向一个方向努力，而Windows团队则将目标定在了另一个方向。”作为一名曾在微软就职过的前员工，我得说公司内部不同产品的开发团队之间在配合方面的表现糟糕到不能解释。由此看来，.NET开发社区中弥漫着的悲观氛围似乎确实具有合理性。

微软的痛苦大概会成为谷歌的快乐。祸起萧墙的微软实际上是给竞争对手提供了一个千载难逢的机会;而抓住这个机会的谷歌打造了一个平台，一个足以当作备选方案的可靠平台。

谷歌希望自身成为应互联网时代之需所诞生的平台，这在其对浏览器的重视程度方面就得到了体现;但显然，Android系统的成功让谷歌在成功之路上又迈进了一大步。每家提供平台的企业都需要一款标准API。苹果有Objective-C及Cocoa。微软有.NET，虽然其公司内部的团队也不爱用这套东西。而谷歌呢，谷歌本来有机会获得Java。鉴于谷歌在开源社区中的群众基础相当不错，他们其实本可以将Java纳入麾下并直接为开发工作提供助力的。

与此类似的分析可参见OpenOffice，这是一款开源文字处理套件，于1999年被Sun公司以StarOffice的名称购入。

坦率地说，OpenOffice并没有能动摇微软Office系列的霸主地位。然而，这并不代表OpenOffice本身缺乏实用性，事实上它在对抗Office系列软件这一微软元老级收入来源方面表现抢眼。拥有Open Office的版权意味着在良好的发展指引下，它能够进一步巩固自身，继而成为谷歌基于云技术的主打文件编辑工具。它不仅能为谷歌提供一套强大的离线商务作业工具套件，更能够在Java的协助下为谷歌倡导的云战略立下汗马功劳、甚至有可能最终决定整套发展规划的成功与否。

谷歌肯定不会在与Oracle公司间的冲突中妥协，无论面对何种压力。然而，事实证明Java的拥有者正在成为可怕的敌人，并试图在任何方面全力阻挠谷歌使用Java技术。这说起来其实是种耻辱，因为像Java这样的好技术应该由谷歌这样的大公司购入，并在健康的开发环境下尽情发光发热。

.NET花了近十年时间来巩固自身在任何Windows标准开发平台上的地位…即使如此，它仍然没能完全取代传统的Win32。Objective-C与Cocoa也在NextStep的打压下继续存在了很久。换句话说，这种更新换代需要时间，尤其是开发平台的更新。显然，谷歌没有足够的时间来为自己打造备选方案。他们惟一的机会就是引入Java，而最终，机会就这样从指尖溜走了。

Android Debug Bridge version 1.0.29 >

-d – directs command to the only connected USB device > returns an error if more than one USB device is present. > -e – directs command to the only running emulator. > returns an error if more than one emulator is running. > -s – directs command to the USB device or emulator with > the given serial number. Overrides ANDROID_SERIAL environment variable. > -p – simple product name like ‘sooner’, or a relative/absolute path to a product > out directory like ‘out/target/product/sooner’. >

1. 下载 http://smali.googlecode.com/ 里的smali.jar和baksmali.jar两个包

2 . 通过odex生成class文件

java -jar baksmali-1.3.2.jar -x xxx.odex

执行完上面这行命令后，会生成一个out 文件夹里面是xxx.odex的class文件。出现问题，根据提示可以从rom的 /system/framework 目录下面找，然后放在odex的同一目录，注意的时当前CMD的路径要在当前目录

3. 通过class生成classes.dex 文件。

java -Xmx512M -jar smali-1.3.2.jar out -o classes.dex

之前有一篇文章介绍了用thread的join()方法来实现，但是我在实际应用过程中发现了一个问题，就是当任务占用时间过长时，会导致service的超时，太杯具了，研究了下，发现也许有更好的方法，还没来得及测试，先记录。

使用Java的线程次机制。

java.util.concurrent.ThreadPoolExecutor 线程池类

我这里用到的方法是newSingleThreadExecutor，这个方法只会创建一个线程，然后所有添加的任务都会用这个线程来顺序执行。代码如下:

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class ThreadPool {
ExecutorService pool = null;
public ExecutorService getSingleThreadPool() {
if (pool == null) {
pool = Executors.newSingleThreadExecutor();
}
return pool;
}

public class Main {
/**
* @param args
*/
public static void main(String[] args) {
ExecutorService pool = ThreadPool.getSingleThreadPool();
for (int i = 0; i < 5; i++)
Thread t = new myThread(i);
pool.execute(t);
}
pool.shutdown();
}
class myThread extends Thread{
int i = 0;
public myThread(int i){
this.i = i;
}
@Override
public void run() {
System.out.println(Thread.currentThread().getName() + "正在执行。。。" + this.i);
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}

[ What is it? ]
AntiLVL's purpose is to subvert standard license protection methods such as the Android License Verification Library (LVL), Amazon Appstore DRM and Verizon DRM. It also disables many anti-cracking and anti-tampering protection methods. Because every implementation of the LVL is potentially (and often is) quite different, it's not possible to automate patching in every case. It will not always work. However, it has been designed to get around obfuscation and to apply many variations.
Under the hood, AntiLVL is a configurable Smali code patcher with rules defined in user-modifiable XML files stored inside the jar called fingerprints. Brief summary of how it works:
* Decompiles the Apk
* Perform  regular expression matching
* Carrie out defined modifications
* Recompile, update classes.dex
* Resign and zipalign

[这是神马?] 英文不好，意思大概就是这个东西可以用来绕过android的签名验证，可以给smail代码打补丁，重新修改xml文件里面的规则等等。

编译源码out下面(/mydroid/out/target/product/generic/symbols /system/bin)的dexopt-wrapper拷到手机

adb push ./dexopt-wrapper  /data/local
adb shell
cd /data/local
./dexopt-wrapper  sim.apk sim.odex