alien75的专栏

自从跳出三界奋勇前行三年有余，其间的喜怒哀乐自有体会，收获还是颇丰，但有一点做得不好就是博客停更，虽说任务重时间紧，但或多或少拿它当借口了。言归正传，期间所做的技术工作主要是原生Linux相关的，本以为做Android机会不是很多(做得又不需要太深入)，但是最近的工作又需要转回到Android上(要比较深入)，于是乎又得捡起回看一下原来做Android所做的笔记，缩短一下热身和起步时间。下面所写的...

基于KitKat(KRT16S)、ARM平台配置进行描述。 一、基础概念1、  sdk级别高级别sdk：一般就是指android.jar，这个在做应用开发的时候可以直接导入；低级别sdk：通过如“make  sdk”命令生成的zip文件，包含platforms、platform-tools、tools等目录，以及模拟器、avd管理器、sdk管理器等；这个需要开发工具如eclip

在进行配置和编译前，已经安装好了Android的NDK和SDK，以及其它的辅助工具如git、cmake、ant、doxygen等。配置和编译的方法也是基本上按照官方(引用一)所描述的做法进行，由于可以进行系统定制所以并没有选择使用OpenCV Manager/Service，而是编译生成Native共享库、附带生成JavaAPI和JNI的形式进行开发(引用二)，当然也可以使用cmake工程或NDK

以前在编译需要不依赖于cygwin(主要是cyggcc_s-1.dll和cygwin1.dll)的程序时可加上-mno-cygwin参数，但这个参数只是针对gcc3的，而gcc4不再支持这个参数，替代方法是使用mingw。网上常说的方法是mingw32+msys来配合编译，不过在现在的cygwin中其实是支持mingw32的，安装好相关组件后就能进行相应工作了。我在编译ffmpeg的时候就采用的这

Live555是一个为流媒体提供解决方案的跨平台的C++开源项目，具体就不做介绍了。从它提供的例子程序来看，都是运行后就不再退出，在实际工作中把它移到Android下做为流媒体服务器运行(TS数据流通过RTSP发送)，但是需要根据WIFI状态的变化来加载和退出，退出的时候还需要保证申请的资源都被释放。为此深入研究了一番代码实现这个目的。        Live555的基本组件包括UsageEn

本文是在在Android中使用native程序（非Java）来广播intent这篇博文的基础上的完整实现，实现了在Native下广播一个即将关机的通知。#define LOG_TAG "IntentTest"#include #include #include #include #include #include #include #include namespace

现在市面上流行的电视盒大部分都是Android，“音频透传”是一个经常见到的词，那到底什么是音频透传、音频透传背后的技术实现到底如何，引起了我的兴趣，因此花了点时间研究了一下。由于是针对全志H8的电视盒方案进行分析，因此分析的结果不具有普遍性，可能其它的方案在技术实现上有所不同。        在开始分析前先查找了一下关于“透传”这个概念的解释，根据度娘的说法是“透传即是透明传送，即传送网络无

最近在8核(Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz)、64GB内存服务器下编译的Android 6.0时，发现在仅开了四个编译任务(make -j 4)的情况下，服务器的所有CPU占用率和虚拟内存的使用都达到满负荷，导致命令行操作极慢，这在原来编译4.4的时候就算开了八个编译任务都是没有出现过的情况。经分析是因为6.0的java编译工具默认已经由openj

在研究内核hibernate实现的时候，由于需要对内存管理如MMU配置、内存分布和分配有相应了解，因此进行了专门的学习。最终结果是hibernate未研究出什么成果，反倒是内存管理的学习小有心得，就此予以总结。当然，按照一贯做法少上代码、多提思路和关键点。        我所使用的平台是全志的平台T3(四核Cortex-A7、2G DDR)，内核版本是3.10.65，硬件物理地址分布是：S

在上一篇文章中，主要从MMU的映射规则角度对内存管理进行了一些分析，经过一些初步学习(未包括LPAE方式)发现不同版本ARM对应的MMU映射和工作规则是兼容的(错了请拍砖)，对于差异性就需要通过阅读对应的官方提供的芯片手冊(如多核cortex-a7手冊目前最新版本是r0p5，文件名是DDI0464F_cortex_a7_mpcore_r0p5_trm.pdf)来深入学习了。       

在编译并使用基于android的htop-2.0.2过程中(引用一)，发现查看进程使用文件句柄(快捷键'l'，实际调用命令lsof)信息一直为空白，经研究发现原来android的lsof其实是包含在toolbox中的子功能，其功能很单一不支持命令行参数，现单独编译源代码生成程序供htop调用。一、编译方式1、在android框架中编译在github上有项目(引用二)，是基于4.86在l

在团队日常开发中，选择合适的版本控制工具并灵活运用能更好的协调团队开发节奏，并保证公司重要的资产---项目文档资料---的安全性，同时也能为产品发布后的运行维护提供帮助。目前常用的版本控制工具是SVN(集中式)和Git(分布式)，两者各有特点，选用哪种工具根据公司策略及其团队实际情况而定，如公司产品类型(线上或线下)、开发模式(敏捷或原型)、团队规模(单分支或多分支)、开发工具使用(原生或托管)等

2016年即将过去，在这一时刻总觉得应该写点什么有价值的东西来纪念一下。思前想后，觉得脱离M$体系转向Android/Linux的开发有两年时间了，在这一过程中还是有很多收获的：澄清了一些模糊概念、验证并确认了一些个人做法、领会了开源项目中的精妙内容。由于Android体系的庞大代码量，当初为尽快入门采用的是“提纲挈领、重点突破、由线及面”的策略，在了解Android的整体设计哲学思想(详见引用一，

在学习Android的lowmemorykiller机制过程中，发现从KK到L再到M有一些新的变化，因此有必要进行一下总结。在开始分析前先厘清一些基础概念，便于描述的展开和结论的形成。一、基本概念1、PageCache：Linux内核为加快文件预取而采用的特有机制(参考引用一)，就是尽可能的把空闲内存用于缓存最近访问过的磁盘文件数据。由于会占用大量的空闲内存，在某种情况下就会导致OOM

仅做记录，未涉及背景相关内容#!/bin/shexport ANDROID_NATIVE_API_LEVEL=21export ANDROID_TOOLCHAIN_NAME=arm-linux-androideabi-4.9cmake \ -DBUILD_SHARED_LIBS=ON \ -DWITH_OPENGL=ON \ -DBUILD_opencv_apps=ON \

仅做记录，未涉及背景相关内容#!/bin/shNDK=/home/ffmpeg/android-ndk-r10dSYSROOT=$NDK/platforms/android-19/arch-arm/TOOLCHAIN=$NDK/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64PREFIX=/home/ffmpeg/

如标题所言，只是做为学习后的思想总结，仅标识出个人关注的要点。一、关注的函数wake_up_interruptible               proc/thread(9)wake_up_interruptible_all           proc(1)wait_event_interruptible            thread(1)wait_event

注：基于kitkat进行的分析Surface的三种使用方式Native层的Surface工作方式有：仅在Proxy端、Proxy和Service端协同、仅在Service端工作三种方式(第三种方式有待确认)。前两种方式在Proxy端都有共同的预处理工作要做，如下：Proxy端1、创建SurfaceFlinger的本地代理sp client = new Surface

具体的说来，高通msm系列的android方案中，camera子系统有一个mm-camera-daemon的服务进程是开机自动运行的。它也是很多人诟病的一个东西：太耗电了。为什么要这么设计在(https://www.mail-archive.com/linux-media%40vger.kernel.org/msg26091.html)有明确的答案，摘抄其关键部分如下：For MSM came

我的本本是T22，256M内存，savagaIX带8M显存的独立显卡，装其它的版本有些吃力，一直听说archlinux是个lightweight的，终于有时间研究一下，费尽一番周折终于装好。ISO是2008.6的，用的是2008.3的启动文件硬盘安装，没别的，因为本本光驱坏了。基本系统只选了base, 先从windows那里分了5个G过来，swap做了一个G，boot单独划了64M，其它的做r

    其实开始并没想到研究这个问题，因为在研究linux的时候是通过cygwin+skyeye+uboot来起步，在搭建好交叉编译环境后将arm-linux-gcc路径设到了全局/etc/profile中，由于cygwin中另外还装了x86-linux-gcc，在编译uboot或x86程序的时候根据路径先后搜索编译器就可能会编译出错，这个时候把编译器路径放到全局就显得不合适了。于是研究了一下cy

1、使用包文件加入一个新的软件包# pacman --add foo.pkg.tar.gz# pacman -A foo.pkg.tar.gz这将会在系统上安装 foo.pkg.tar.gz 软件包。如果不能满足依赖关系，pacman 会退出并显示错误和报告所缺少的依赖关系，但不会尝试自动解决依赖关系，如果你需要这功能，看看 --sync 选项。2、使用包文件升级一个软件包#

试验平台: winxp+vmware 6.52+ubuntu 9.04+skyeye 1.2.6一、交叉编译环境建立操作系统环境：ubuntu 9.04, gcc-4.1.0, crosstool-0.43交叉编译环境：gcc-3.4.5, glibc-2.3.6, linux-2.6.12, u-boot-1.2.0问题：1、建立交叉编译环境依赖库：build-essential，texin

平台环境:skyeye1.2.8+u-boot1.2.0+smdk2410现象描述:在运行的时候会出现大量的“bus read error”错误，或者u-boot跑飞出现乱码信息。      1.2.8相对1.2.6最大的改变就是将存储管理这一块做成相对独立的模块，我想这样做的目的应该是能够把更多的精力放在新平台新架构的研发。出现问题我初步想法可能就是在这个改变上。通过与1.2.6上跑u-

SVN是CVS的下一个版本，主要用来进行版本控制，可以对程序代码，音频，视频以及图像文件等，做版本控制。目录以及文件是Subversion中可以记录版本的对象。其主要工作原理如下图：                   _ _ _ _ _ _ _ _ _ _                  /                              /                  |

　　前言：第二阶段的学习计划的启动可以用“阴差阳错”来描述，前后持续了三个多星期，对于陌生东西的研究确实是一个痛苦的过程，一旦找到问题的所在却有一种“豁然开朗”的快乐。　　在完成第一阶段的学习计划后，对于第二阶段内容按原计划是根据第一阶段积累的经验移植linux到现有的开发板上。只是根据第一阶段的情况感觉这是个比较花时间的过程，再加上项目比较紧，只好暂时搁置了一段时间。　　大概二个月前，老

navit版本: r4846，cegcc版本: 0.59.1官方网站上介绍可以用mingw32ce来做，但是我试了一下有问题就没有再深入，改为用cegcc来做，不过也花了一些时间。配置脚本内容如下：PATH=/opt/cegcc/bin:$PATH \CFLAGS="-I/usr/wince/include -mwin32 -DWIN32 -D_WIN32_WCE=0x0600 -

3.17.2 ARM OptionsThese `-m' options are defined for Advanced RISC Machines (ARM) architectures:-mabi=name Generate code for the specified ABI. Permissible values are: `apcs-gnu', `atpcs', `aapc

转自：http://www.360doc.com/content/10/0311/12/155970_18337965.shtml1。什么是ABIABI，application binary interface (ABI)，应用程序二进制接口。既然是 接口，那就是某两种东西之间的沟通桥梁，此处有这些种情况：A。应用程序 操作系统；B。应用程序 （应用程序所用到的）库C

两年前因为要移植一些linux功能库曾经用过cegcc0.51(自己下载代码重新编译的)，之后就没有用过。这两天闲来无事想把pixman移植到wince就上到SF上发现已经更新到0.59.1了，一时兴起就又下了代码编译，现在把出现的问题记录下来就当是温故知新吧。需要说明的是现在SF上有三个交叉编译环境，cygwin是在windows下用的，cegcc和mingw32ce则是在linux下用的。考虑

从网上了解到的种种下载android源码失败的处理，都提到repo同步是可以“续传”的，我也一直认为这个所谓的“续传”是“断点续传”的意思。直到我在下载android-x86这个开源项目时，才发现这个“续传”不是“断点续传”。现象是这样的：由于服务器的不稳定，在下载到frameworks/base这个有几GB的project时老是失败，提示信息先后是“The remote end hung

注：本文档基于kk进行分析，着重于概念的精确定义和版本历史演变一、关于hwc的介绍广义的来讲是指利用硬件完成图像数据组合并显示的功能(能力)，狭义的来讲就是指Hwcomposer HAL。1、从广义的角度来分析，有几个概念需要精确定义(注意字母大小写差异)(1)hwc：利用硬件完成图像数据组合并显示的功能(能力)，具体到代码级别它是由多个类如SurfaceFling

对于我这样的菜鸟感觉还不错，收藏。 http://blog.frompku.com/archives/238