<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[东方欲晓的专栏]]></title><description><![CDATA[东方欲晓，莫道君行早，踏遍青山人未老，风景这边独好]]></description><link>https://blog.youkuaiyun.com/nicefuture</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; nicefuture]]></copyright><item><title><![CDATA[很长时间没有写博客了，应该要写写了]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/9466047</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/9466047</guid><author>nicefuture</author><pubDate>Thu, 25 Jul 2013 11:19:53 +0800</pubDate><description><![CDATA[其实，工作中一直有积累，但是确实已经忘了博客这个东西，不过真心觉得应该把积累的东西一起分享。 所以，会恢复写博客了]]></description><category></category></item><item><title><![CDATA[Android 4.3 安全提升，Set-UID-Root 权限提升不再起作用，原先的ROOT方法将失效]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/9465635</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/9465635</guid><author>nicefuture</author><pubDate>Thu, 25 Jul 2013 11:11:16 +0800</pubDate><description><![CDATA[Android目前的ROOT的基本原理，是通过系统漏洞获取ROOT SHELL权限，然后往手机里面push 最核心的两个文件，su可执行文件和superUSer.apk。 后者用于管理对应用的授权，而前者则真正用来提升权限至ROOT。 当APK需要进行高权限操作时，使用Shell方式进行： su xxxxx 即可，此时（假设用户授权了，通过superUser.apk）xxxx的命令就会以ROOT用]]></description><category></category></item><item><title><![CDATA[Android手机Root授权原理细节全解析]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/7644388</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/7644388</guid><author>nicefuture</author><pubDate>Fri, 08 Jun 2012 10:24:19 +0800</pubDate><description><![CDATA[首先关于Root的方式，这里不做详解，可以有很多漏洞，比如利用uid溢出后归为0，得到Root权限，然后操作文件系统等。
 
手机Root后，最重要的是，给手机安装了su程序和superuser apk。 su一般被安装在/system/xbin 或者 /system/bin 下面，su文件的权限如下：
 
# ls su -l
ls su -l
-rwsr-sr-x    1 roo]]></description><category></category></item><item><title><![CDATA[比较BMP和Android的RPC机制]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/6678440</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/6678440</guid><author>nicefuture</author><pubDate>Thu, 11 Aug 2011 11:54:33 +0800</pubDate><description><![CDATA[RPC机制是现代系统的重要的一种机制，和IPC有关，却又没有必然关系。 RPC是更广义的，更高层的，为解决异构/非本地对象/过程调用而形成的一套解决方案，其目的重在解决如何让远程对象/过程的访问可以如同本地对象/过程那般，将真正的差异性向上层客户隐藏。

 
而IPC仅仅是]]></description><category></category></item><item><title><![CDATA[移动平台中的模块复用]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/6678436</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/6678436</guid><author>nicefuture</author><pubDate>Thu, 11 Aug 2011 11:54:01 +0800</pubDate><description><![CDATA[在“复用”这一角度，无疑android是最棒的，至少到目前尚无平台可以出其右。 当然，我相信android的思想也不是一蹴而就的，也是借鉴并发展了前人的思想。 我们慢慢看来：

 

 
1. 首先，在Windows等PC平台上，最常见的复用的粒度 是基于 “进程”的复]]></description><category></category></item><item><title><![CDATA[移动平台中的面向组件编程]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/6678434</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/6678434</guid><author>nicefuture</author><pubDate>Thu, 11 Aug 2011 11:53:25 +0800</pubDate><description><![CDATA[其实，很多移动平台都号称是面向组件编程，不过他们所谓的面向组件的层次其实是不同的。

 
首先我们看Android，它在设计思想，解空间模型上的确是面向组件的，它将进程，application的边界模糊化，而独将组件的边界凸显化，从而提醒开发者，是基于组件的开发思想。 不过]]></description><category></category></item><item><title><![CDATA[学好Android的基石]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/6658746</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/6658746</guid><author>nicefuture</author><pubDate>Thu, 04 Aug 2011 09:45:03 +0800</pubDate><description><![CDATA[以前一直搞BMP平台，现在Android实在太热了，由于项目的需求，现在也开始转到Android平台上了。个人认为，不管哪个平台，要学好他，都必须要搭好基石，才能轻松攀爬。而且不同平台的基石是不一样的，比如BMP平台的重要基石，如需要理解COM组件模型，C，MVC等
 
而对]]></description><category></category></item><item><title><![CDATA[高通的1（One）情结]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/5947138</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/5947138</guid><author>nicefuture</author><pubDate>Sun, 17 Oct 2010 19:17:00 +0800</pubDate><description><![CDATA[<br />细心的读者，可能已经观察到了，高通很喜欢用One来命名自己的产品，技术。One可以有两层意思，NO.1和Only One。 NO.1者即引领世界，Only One者，即一统天下。 作为技术领导者的高通，一直不忘将此二者作为自己的终极目标，即使在无线通信界目前已经是老大哥了。 我们还是来举几个例子。<br /> <br />CDMAOne：  这是高通CDMA技术的商标。很明星的是，CDMAOne无疑表明着Qualcomm想成为CDMA技术的NO.1 和 Only 1. 也确实， 在CDMA领域，]]></description><category></category></item><item><title><![CDATA[brew动态模块文件格式发展浅析：From MOD to MOD1]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/5931475</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/5931475</guid><author>nicefuture</author><pubDate>Sun, 10 Oct 2010 15:22:00 +0800</pubDate><description><![CDATA[<br /><br />为什么在BMP中开始引入MOD1格式，并且同时支持MOD和MOD1两种格式那？ 这还得从最初的MOD格式开始说起。<br />话说，最初时，BREW利用MOD这种格式作为动态模块加载的文件格式。 其实， MOD文件是纯的可执行文件，除了RO DATA， RO Code Section以外，不再包含任何的非可执行的数据，如符号表等。  MOD是从ELF转换而来的，剔除冗余的数据后，就变成了一个纯的可执行文件 MOD。<br />由于是纯的可执行文件，所以，理论上当MOD被加载后，PC跳]]></description><category></category></item><item><title><![CDATA[CS(Component Service)， BMP（Brew Mobile Platform）那点事]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/5931077</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/5931077</guid><author>nicefuture</author><pubDate>Sun, 10 Oct 2010 10:38:00 +0800</pubDate><description><![CDATA[<br />大家知道Qualcomm最新的BREW版本为BMP，BMP又是基于CS的，那么为何要演进到BMP，以及BMP为何需要基于CS那，其实，这个还是有一个背景的， 本文主要就笔者的观点，谈谈我所认为的背景。<br /> <br /> <br />BREW从1.0一直发展到3.x，一直充当着Feature Phone中的平民英雄的角色， 它的优点，就是可以不依赖于（不奢望）底层平台/系统的现代特性（多进程，多线程，内存保护，动态链接，动态加载等）而依靠自身实现一个轻量级的应用框架，同时支持动态加载。 所]]></description><category></category></item><item><title><![CDATA[BMP文档草拟]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/5908267</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/5908267</guid><author>nicefuture</author><pubDate>Sun, 26 Sep 2010 21:10:00 +0800</pubDate><description><![CDATA[接下去一段时间，我将主要从事BMP相关的工作，由于可以看到BMP的源码，所以，会在熟悉BMP源码之后，再书写一些相关的文档，以期能深入些，而不是贪快而不顾质。  目前想到的Topic如下：1.   Component Service的整体框架和产生背景，作用2.   BMP中组件支持RPC的机制和内部实现3.   BMP中的Process，Thread，Memory管理等机制实现4.   BMP中的组件动态注册，发现，加载和执行机制5.   BMP中的安全机制]]></description><category></category></item><item><title><![CDATA[换工作了，新的人生起点！！我对自己说，好好干，在新的起跑线上再次奔跑！]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/5907140</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/5907140</guid><author>nicefuture</author><pubDate>Sun, 26 Sep 2010 13:06:00 +0800</pubDate><description><![CDATA[在原先的手机设计公司做了快6年了，这次终于有机会，让我把握了我一直的梦想。我以前是学通信的， 再也没有任何其他一家公司能让我这么崇敬和仰慕。 一家由通信科学家创立的公司，拥有几千项通信的专利。 将通信理论从不可能变成现实中的可能。 通信界的巨牛， 信息之父，香农定理的发明者， 香农，分别是这家公司的两大创始人（雅各布，维特比）的老师和学生。我相信，读过通信的人，应该也有我这样的感觉的。]]></description><category></category></item><item><title><![CDATA[BREW和Android的安全思想]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/5806044</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/5806044</guid><author>nicefuture</author><pubDate>Thu, 12 Aug 2010 09:52:00 +0800</pubDate><description><![CDATA[<br /><br />理论上，所有的公众（公开）实体，都需要安全机制保障， 比如网络。 从分层角度而言，每一层都可以进行安全保护，比如网络协议中的IpSec（Ip层）， SSL（传输层）， sMIME（应用层）安全协议。 对于移动平台也不例外， 也可以在不同的层次进行安全保障，系统底层和框架上层。<br /> <br />对于BREW平台，一直就是非智能的平台，所以它对底层系统的奢求不是那么高，无需任何现代操作系统的支持。 所以， BREW也就不能对系统层的安全做任何奢求，那么只能完全在BREW这一层实现]]></description><category></category></item><item><title><![CDATA[Linux Driver思考：通向皇宫的通道]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/5788537</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/5788537</guid><author>nicefuture</author><pubDate>Wed, 04 Aug 2010 16:59:00 +0800</pubDate><description><![CDATA[传统意义上的Linux Driver仅仅是设备驱动，简言之，和设备有关，如LCD，Camera等等。 但是， 笔者认为，Linux Driver的作用不仅仅局限于此，从广义上讲， Linux Driver提供了一种User Space访问 Kernel中特定Function的通用编程模型，即，平民（User Space中的Application， Process， Lib等）通向皇宫（Kernel）的大道。如果一个模块提供的Function必须运行于Kernel Space中（可能是设备相关的Functio]]></description><category></category></item><item><title><![CDATA[【BREW你问我答】02期_20100709]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/5722964</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/5722964</guid><author>nicefuture</author><pubDate>Fri, 09 Jul 2010 12:39:00 +0800</pubDate><description><![CDATA[为了使得BREW你问我答办的更好，决定不再在一个帖子中靠不断的回复来问答，这样多了后比较乱。 以后，基本上每周我会更新一期， 大家每次的新问题，请都在最新期的BREW你问我答（会置顶）中提问。 我一般只会关注最新期的问题。  当然，对于老问题的继续探讨，可以在原先的提问的基础上再提问谢谢～～～～～新的问题请在本帖子下开始提问]]></description><category></category></item><item><title><![CDATA[关于BREW你问我答， 期望TX们提建议]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/5722769</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/5722769</guid><author>nicefuture</author><pubDate>Fri, 09 Jul 2010 11:17:00 +0800</pubDate><description><![CDATA[感觉BREW你问我答如果这样下去，那么回复贴越来越多，楼磊的非常高，比较乱。 同时，也不能把已经解决的问题，快速的分享给大家。TX们有什么好的建议那， 可以让BREW你问我答更好的做下去~~ 同时也可以让其他TX帮忙解答问题~~谢谢~~~]]></description><category></category></item><item><title><![CDATA[感慨这一刻，终于到来！]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/5721872</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/5721872</guid><author>nicefuture</author><pubDate>Thu, 08 Jul 2010 21:26:00 +0800</pubDate><description><![CDATA[感慨这一刻，终于到来。 5年前，我一手带领的BREW Team，后来演变为目前的application  Team，Team内员工最多时，达到过20多人。 5年来，看着我的组员一个个离职而去，到明天，原始的Team中的最后一名员工也将正式离职而去， 我曾经的激情岁月也将划一个句号！ 这一刻，说不感慨，不失意，那是假的。 不过，同时也为他们的更美好的前途感到高兴。 他们一个比一个优秀，一个比一个踏入更光辉的大道。 说我这5年带给了他们什么，培养了他们什么，其实真的很汗颜。 他们的成就，其实更多的都是他们的天赋]]></description><category></category></item><item><title><![CDATA[Android, BREW中Observer（观察者）模式的两种表现]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/5720128</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/5720128</guid><author>nicefuture</author><pubDate>Thu, 08 Jul 2010 09:17:00 +0800</pubDate><description><![CDATA[Observer模式无疑是最伟大的设计模式之一。 她被用来解耦一对多的关系，并对“多”的变化进行隔离。 现代移动平台中，各是随处可见她的身影。 本文将从Android，BREW两个移动平台中，一窥其迷人身姿。Listener机制。 在BREW和Android中，同时都提供了Listener机制。这是血统纯正的Observer模式体现。 BREW中的IModel的AddListener和Android中的View的AddXXXListener就是两个很好的例子。 在这种纯种Observer模式下，我们需要明确]]></description><category></category></item><item><title><![CDATA[Android AppWidget框架妄析： Android中的借尸还魂]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/5719243</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/5719243</guid><author>nicefuture</author><pubDate>Wed, 07 Jul 2010 17:59:00 +0800</pubDate><description><![CDATA[由于初识Android不久，所以一切分析皆可有误，故而只能为之妄析。 题目起的比较恐怖，然非我本意。 只是实在找不到更加贴切的，可以对AppWidget框架一针而见血的比喻了。 闲话少说，且看如何个借尸还魂。首看魂者何来。 大家都知道Widget的宗旨，就是要在同一屏幕（界面上）运行多个具有独立功能的小插件，从而丰富功能的同时简化操作。那么，在Android的4大组件中，何人可以充当该角色，抑或需要再独立设计一个组件？ Activity？ 非也！！ Activity是UI呈现和用户交互的一个组件，具有独特的]]></description><category></category></item><item><title><![CDATA[BREW与Android中的UI事件框架比较]]></title><link>https://blog.youkuaiyun.com/nicefuture/article/details/5718820</link><guid>https://blog.youkuaiyun.com/nicefuture/article/details/5718820</guid><author>nicefuture</author><pubDate>Wed, 07 Jul 2010 15:55:00 +0800</pubDate><description><![CDATA[对于BREW，我非常熟悉，但是对于Android，只能算刚刚认识，最近看了些Android的UI事件处理的相关文档，发现Android的UI事件处理框架与BREW有一些异同，这里给予一些比较，纯属个人认识。 如有不当之处，欢迎指正。相同之处在于，从高层而言，Android与BREW的UI事件框架均是基于职责链模式的，运行时构成了Event Chain。 Event Chain中的每一个部件默认将事件传递给后继者。 事件在Event Chain的终点处自然终止， 或者在中间异常终止（中间部件返回了TRUE，导]]></description><category></category></item></channel></rss>