Android系统在用户长时间不操作时,为了节省资源,系统会选择休眠.在休眠过程中自定义的Timer.Handler.Thread.Service等都会暂停.而有时候这种机制会影响到我们程序的正常运行.那如何避免系统休眠对我们程序的影响呢? 以下已Service服务为例说明在系统休眠的状态下如何唤醒系统并执行我们自定义的Service服务. 一.单次Service服务的开启 1.方法:在需要执行Service服务时获取电源锁,并在执行完毕释放电源锁. 2.代码举例: public class W

最近在做关于android手机端gps定时定位的功能,需要每隔几秒钟将gps定位获取的经纬度上传至后台,但是发现某些手机在屏幕黑屏,进入休眠状态后,后台就没有收到定位信息了,后来通过网上查找资料,发现一旦手机在休眠的时候,手机的cpu也休眠了,创建的线程也会sleep,所以为了让手机屏幕黑屏之后,上传线程可以继续运行,就必须保存手机CPU一直处于运行状态,综合网上所查找的资料,发现可以通过使用android的PowerManager和PowerManager.WakeLock这两个类来控制,具体

问题的由来: 自从安装上了最新发布的Windows 10 ,使用起来有诸多的改进:无论是重绘的图标还是通知消息中心的整合还是更智能的OneDrive客户端都使得工作起来非常愉悦. 不过笔者这两天频繁遇到晚上下班休眠了的机器,第二天早晨回来电脑处于开机状态的现象,这个奇怪的现象之前笔者曾经写过在Windows 8 下面的解决办法 (可前往此处查看当时博文调查Windows 8 的“幽灵”般启动). 通过一系列的查看发现此法在本次的9926版上不灵,所提示的内容居然是个“唤醒源:未知”. Figur

本文转载自:http://blog.csdn.net/mu0206mu/article/details/7464987  在使用update.zip包升级时怎样从主系统(main system)重启进入Recovery模式,进入Recovery模式后怎样判断做何种操作,以及怎样获得主系统发送给Recovery服务的命令,这一系列问题的解决是通过整个软件平台的不同部分之间的密切通信配合来完成的.为此,我们必须要了解Recovery模式的工作原理,这样才能知道我们的update.zip包是怎样一步步

Android系统Recovery工作原理之使用update.zip升级过程分析(一)---update.zip包的制作 http://blog.csdn.net/mu0206mu/article/details/7399822 Android系统Recovery工作原理之使用update.zip升级过程分析(二)---update.zip差分包问题的解决http://blog.csdn.net/mu0206mu/article/details/7464551 Android系统Recovery

Android系统定制配套视频: 为了把Android系统源码定制和编译的课程讲完,从准备到录制完所有的视频,一共花去了近半年的时间,前前后后各种下载源码,编译源码,系统不兼容,版本适配,虚拟机配置困难重重,总算是录制完成,目前应该算是全网最全的源码编译课程,如果各位喜欢,转载请注明出处,能打赏点当然更好了.多谢各位了. 转载出处:http://www.jianshu.com/p/46c63dfd5c89 android系统定制-初识源码级开发 android系统定制-Vbox及Ubuntu的安

文章转载至CSDN社区罗升阳的安卓之旅,原文地址:http://blog.csdn.net/luoshengyang/article/details/8062945 在前面两篇文章中,我们分析了SurfaceFlinger服务的启动过程以及SurfaceFlinger服务初始化硬件帧缓冲区的过程.从这两个过程可以知道,SurfaceFlinger服务在启动的过程中,一共涉及到了三种类型的线程,它们分别是Binder线程.UI渲染线程和控制台事件监控线程.在本文中,我们就将详细分SurfaceFl

Android休眠与唤醒驱动流程分析 标准Linux休眠过程: powermanagement notifiers are executed with PM_SUSPEND_PREPARE tasksare frozen targetsystem sleep state is announced to the platform-handling code devicesare suspended platform-specificglobal suspend preparation method

本文转载自:http://blog.csdn.net/mu0206mu/article/details/7465439  Android系统Recovery工作原理之使用update.zip升级过程分析(六)---Recovery服务流程细节            Recovery服务毫无疑问是Recovery启动模式中最核心的部分.它完成Recovery模式所有的工作.Recovery程序对应的源码文件位于:/gingerbread0919/bootable/recovery/recovery

通过分析update.zip包在具体Android系统升级的过程,来理解Android系统中Recovery模式服务的工作原理.我们先从update.zip包的制作开始,然后是Android系统的启动模式分析,Recovery工作原理,如何从我们上层开始选择system update到重启到Recovery服务,以及在Recovery服务中具体怎样处理update.zip包升级的,我们的安装脚本updater-script怎样被解析并执行的等一系列问题.分析过程中所用的Android源码是gin

目前update-script脚本格式是edify,其与amend有何区别,暂不讨论,我们只分析其中主要的语法,以及脚本的流程控制. 一.update-script脚本语法简介: 我们顺着所生成的脚本来看其中主要涉及的语法. 1.assert(condition):如果condition参数的计算结果为False,则停止脚本执行,否则继续执行脚本. 2.show_progress(frac,sec):frac表示进度完成的数值,sec表示整个过程的总秒数.主要用与显示UI上的进度条. 3.for

Android系统--输入系统(七)Reader_Dispatcher线程启动分析 1. Reader/Dispatcher的引入 对于输入系统来说,将会创建两个线程: Reader线程(读取事件) Dispatcher线程(分发事件) 2. Reader/Dispatcher的创建 我们知道在Android系统中,都普遍按照面向对象的思想来编写程序,对于问题,Android一般都是创建一个类去解决,在输入系统中,有两个线程,对于这两个线程,Android系统为这两个线程创建两个类,分别为Inp

Android系统--输入系统(八)Reader线程_使用EventHub读取事件 1. Reader线程工作流程 获得事件 size_t count = mEventHub->getEvents(timeoutMillis, mEventBuffer, EVENT_BUFFER_SIZE); 简单处理 processEventsLocked(mEventBuffer, count); 将事件分发给Dispatch线程处理 mQueuedListener->flush(); 2. Reader

Android系统--输入系统(九)Reader线程_核心类及配置文件 1. Reader线程核心类--EventHub 1.1 Reader线程核心结构体 实例化对象:mEventHub--表示多个输入设备,里面有数组mPendingEventItems存储多个设备 struct epoll_event mPendingEventItems[EPOLL_MAX_EVENTS]; mDevice--vector,用来表示记录多个输入设备 KeyedVector<int32_t, Device*>

Android系统--输入系统(十)Reader线程_核心类及配置文件深入分析 0. 前言 个人认为该知识点阅读Android源代码会不仅容易走进死胡同,并且效果并不好,前脚看完后脚忘记,故进行总结,希望可以更好帮助大家了解,了解之后在进行阅读源代码会有事半功倍的效果. 1. 引入 由输入系统(九)实验得出 keylayout文件:只是用来表示驱动上报的scancode对应哪一个android按键(AKEYCODE_x)只是表示按键被按下. kcm文件: 用来表示android按键(AKEYCO

Android系统--输入系统(十三)Dispatcher线程情景分析_Reader线程传递事件 1. 输入按键 我们知道Android系统的按键分为三类:(1)Global Key;(2)System Key;(3)User Key Global Key:按下一个按键,启动某个APP. 具体使用哪个按键启动哪个APP可以自己指定,修改\frameworks\base\core\res\res\xml\Global_keys.xml,接下来有一篇博文具实现,假设它是AKEYCODE_TV Sys

Android系统--输入系统(十四)Dispatcher线程情景分析_dispatch前处理 1. 回顾 我们知道Android输入系统是Reader线程通过驱动程序得到上报的输入事件,还要经过处理,才可以将输入事件发送给应用程序,现在回顾一下是具体做哪些处理. 首先Reader线程会将输入事件放入mInboundQueue队列当中,但是放入队列之前需要进行稍加处理. 1.1 处理类型 - 紧急事件,马上处理(来电振铃时,按下音量键,会马上静音) - 对输入事件添加Flag,决定输入事件是否传

本文转载自:http://blog.csdn.net/mu0206mu/article/details/7464699 以下的篇幅开始分析我们在上两个篇幅中生成的update.zip包在具体更新中所经过的过程,并根据源码分析每一部分的工作原理. 一.       系统更新update.zip包的两种方式     1.  通过上一个文档,我们知道了怎样制作一个update.zip升级包用于升级系统.Android在升级系统时获得update.zip包的方式有两种.一种是离线升级,即手动拷贝升级包到

本文转载自:http://blog.csdn.net/mu0206mu/article/details/7399822 这篇及以后的篇幅将通过分析update.zip包在具体Android系统升级的过程,来理解Android系统中Recovery模式服务的工作原理.我们先从update.zip包的制作开始,然后是Android系统的启动模式分析,Recovery工作原理,如何从我们上层开始选择system update到重启到Recovery服务,以及在Recovery服务中具体怎样处理upda

本文转载自:http://blog.csdn.net/mu0206mu/article/details/7465603       Android系统Recovery工作原理之使用update.zip升级过程分析(九)---updater-script脚本语法简介以及执行流程     目前update-script脚本格式是edify,其与amend有何区别,暂不讨论,我们只分析其中主要的语法,以及脚本的流程控制. 一.update-script脚本语法简介: 我们顺着所生成的脚本来看其中主要涉