符合中小企业对网站设计、功能常规化式的企业展示型网站建设
本套餐主要针对企业品牌型网站、中高端设计、前端互动体验...
商城网站建设因基本功能的需求不同费用上面也有很大的差别...
手机微信网站开发、微信官网、微信商城网站...
在PowerManager的API文档中,给出了一个关机/重启接口:
成都创新互联是一家集网站建设,山阴企业网站建设,山阴品牌网站建设,网站定制,山阴网站建设报价,网络营销,网络优化,山阴网站推广为一体的创新建站企业,帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿,时刻以成就客户成长自我,坚持不断学习、思考、沉淀、净化自己,让我们为更多的企业打造出实用型网站。
public void reboot (String reason)
对于这个接口的描述很简单,就是几句话。
接口的作用就是重启设备,而且,就算重启成功了也没有返回值。
需要包含REBOOT权限,也就是android.permission.REBOOT
唯一参数reason代表需要的特定重启模式,比如recovery,当然也可以为null。
1.frameworks/base/core/java/android/os/PowerManager.java
2.frameworks/base/core/java/android/os/IPowerManager.aidl
3.frameworks/base/services/java/com/android/server/PowerManagerService.java
4.frameworks/base/services/java/com/android/server/pm/ShutdownThread.java
5.frameworks/base/services/jni/com_android_server_PowerManagerService.cpp
---------------------》
6.system/core/libcutils/android_reboot.c
7.bionic/libc/unistd/reboot.c
8.__reboot通过syscall来到内核
9.kernel/sys.c
frameworks/base/core/java/android/os/PowerManager.java
mService为IPowerManager Binder接口服务。
frameworks/base/core/java/android/os/IPowerManager.aidl
frameworks/base/services/java/com/android/server/PowerManagerService.java
frameworks/base/services/java/com/android/server/pm/ShutdownThread.java
这里说明是需要重启,且不是安全模式,重启参数为传递下来的reason,shutdownInner的confirm参数是用来设置是否有确认提示框的,通过reboot接口调用重启是没有的,为false。
重启的实现在run()中,因为ShutdownThread是Thread的扩展,所以run会自动运行。
frameworks/base/services/java/com/android/server/pm/ShutdownThread.java
在重启前会将重启原因写入sys.shutdown.requested,如果没有则为空,如果是安全模式还会将persist.sys.safemode置1,之后会进行一些关机前的预处理,关闭ActivityManager以及MountService,最终调用rebootOrShutdown进行关机操作。
如果确认重启,则调用PowerManagerService的lowLevelReboot函数,参数就是传递下来的reason,稍后分析。如果不是重启,即mReboot=false,那就是需要关机了,在shutdown函数中就能够知道。
frameworks/base/services/java/com/android/server/PowerManagerService.java
frameworks/base/services/jni/com_android_server_PowerManagerService.cpp
可以看到无论是关机还是重启,都是调用android_reboot来实现的,只是参数不一样而已。
system/core/libcutils/android_reboot.c
以reboot recovery为例,arg即为recovery,所在在第五步的时候会传入ANDROID_RB_RESTART2。到了android_reboot函数中,会看到这样的定义#ifdef RECOVERY_PRE_COMMAND,即属于重启前会执行的命令,如果定义了就会执行。
下面也是做了一些关机重启前的预处理工作,sync()作用是将缓存中的信息写入磁盘,以免程序异常结束导致文件被损坏,linux系统关机前会做几次这样的动作;而remount_ro()作用是通过调用emergency_remount()强制将文件系统挂载为只读,不再允许任何写入操作,同时会通过检查/proc/mounts的设备状态来确认是否当前的所有写入工作已经完成,这个检查过程是阻塞操作。
接下来才是对参数的解析处理:
1)普通重启 ANDROID_RB_RESTART, reason = RB_AUTOBOOT;
2)关机 ANDROID_RB_POWEROFF, 无需reason,直接调用reboot进行关机;
3)带参数的特殊重启 ANDROID_RB_RESTART2, reason 将为默认值 -1
这里又出现一个#ifdef RECOVERY_PRE_COMMAND_CLEAR_REASON,如果定义了它,则无论上层传下来的参数是什么样的,最终都只是普通重启而已。定义它的方式是在BoardConfig.mk中加入TARGET_RECOVERY_PRE_COMMAND_CLEAR_REASON := true,应该有厂商会喜欢这么做的,毕竟除了普通重启,都可能带给用户一定的风险。
最后会对reason进行一个检测,那么通过上边的分析,其实只有带参数的特殊重启才会为-1,而不等于-1的情况中有普通重启和关机,而关机已经自行解决了……所以,不等于-1的情况到了这里也只有普通重启了。最终这里就是区分普通重启与特殊重启的地方了。这里再插入一个问题,其他的几个cmd都是什么值呢?答案在bionic/libc/include/sys/reboot.h中:
reboot(reason) - reboot(RB_AUTOBOOT) - __reboot( LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_RESTART, NULL )
__reboot通过syscall来到内核bionic/libc/arch-arm/syscalls/__reboot.S
其被指定了一个固定的偏移量,在被调用的时候就是通过这个偏移量去内核中寻找对应的入口的,由此可见,内核中一定有着相同的定义,否则将不能成功调用。内核中对syscall偏移量的定义在内核源码中的arch/arm/include/asm/unistd.h,相关信息完全一致。
已经找到了内核中的对应映射,那么下一步就要去找寻真正的实现函数了,在include/asm-generic/unistd.h中可以找到内核对__NR_reboot的syscall函数映射,即
同时,能够发现如此温馨的一幕,内核已经指引我们下一步该去哪里寻找sys_reboot,即kernel/sys.c。
include/linux/syscalls.h
与__reboot的调用参数一致。
进入sys.c文件后,并没有找到名为sys_reboot的函数,而通过仔细查找,发现一个很有趣的函数,其定义为SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd, void __user *, arg),对比__reboot的参数,能够符合。究竟是不是这个函数?
同样在include/linux/syscalls.h文件中,能够找到这样几个定义:
而pm_power_off为空的话,就把用户的关机命令转换为挂起:
arch/arm/kernel/process.c
pm_power_off = msm_pm_power_off;
SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd, void __user *, arg)
这个过程是用reboot_mutex互斥锁来进行保护的,以保证同一时间只可能有一个解析过程,避免冲突。
bionic/libc/include/sys/reboot.h 中可以看到android定义的启动方式
RESTART
POWER_OFF
RESTART2
对框架进行赋值,qcom 平台 845上已经不是这函数,自己查找
arm_pm_restart = msm_pm_restart;
下面是qcom 实现,每个平台不同
可以在跟踪这个流程的过程中会发现,确实是有存在关机的相关接口的。那么关机该怎么用呢?
frameworks/base/services/java/com/android/serverBatteryService.java
重启方式: 最后就是设定寄存器,Uboot 解析不同寄存器的值进入不同的启动模式
recovery 如果传下来的字符串是recovery那么,就在RTC寄存器里设置某个特定值,当uboot里读取RTC寄存器的时候如果获取了这个特定值,那就可以起recovery这个动作了。
Ref:
上面主要讲到流程,在实际开发中, 主动调用系统开机关机如何做
(Ref: )
一. 发送系统广播方式
二. 通过init.rc启动系统服务来运行sh文件
三. Runtime调用Linux-shell
四 . PowerManager reboot以及反射调用PowerManagerService shutdown
五.使用ShutdownThread (尝试不成功,但想法觉得可行)
Intent.java位于源码/frameworks/base/core/java/android/content/Intent.java下面
脚本方式,实际都是基于指令的
使用PowerManager 或ShutdownThread 都是基于关机流程
1、手机重启的主要原因是系统问题,而内存卡导致系统出现问题的概率较大。
2、除了购买品牌内存卡之外,安装软件或者游戏到内存卡上也需要注意,这里建议使用link2sd工具,该工具可以将软件产生的数据文件挂载到内存卡上,一方面可以尽量避免占用手机自带内存,另一方面可以避免系统数据错误而导致安卓系统问题。
3、对于已经出现了手机自动重启的问题,可以进入手机的recovery模式,清除系统缓存和系统数据,再次重启手机,一般的问题都可以解决。
4、进入recovery模式之后,选择:wipe data/factory reset 和 wipe cache partition,按下电源键确认选择。
5、等待清除系统数据和系统缓存之后,回到主菜单,选择第一项重启手机。
6、此时手机会有一个较长的进入系统的时间,需要耐心等待,等手机进入系统之后,再试试,看是否非常流畅呢
Android 系统重启原因分析
重启原因分类
1.上层造成重启
system_server被杀
watchdog重启
重要线程阻塞
2.kernel造成重启
空指针
非法地址
3.kernel watchdog 造成重启,原因不确定
内存原因
nand驱动