Android SystemBar启动流程分析
android systemui statusbar的层级原理

android systemui statusbar的层级原理Android SystemUI Statusbar的层级原理:Android的SystemUI是一个系统级应用程序,它包含了许多重要的组件,其中之一就是StatusBar(状态栏)。
StatusBar位于屏幕顶部,为用户提供了显示通知、调整音量、查看时间等功能。
StatusBar的层级原理主要涉及到WindowManager和View的概念。
Android的WindowManager负责管理屏幕上的窗口,而View则负责显示界面上的视图元素。
StatusBar的层级通过youtParams来确定。
StatusBar以youtParams.TYPE_STATUS_BAR的类型添加到WindowManager中,并且将其放置在屏幕顶部。
这个类型指定了StatusBar的层级,使其始终显示在其他窗口之上。
在StatusBar的层级中,各个视图元素以View的方式进行展示。
例如,状态栏中的通知图标、时间、电池电量等元素都是以View的方式添加到StatusBar中的。
这些视图元素可以通过设置不同的LayoutParams,并且使用addView()方法添加到StatusBar的布局中。
除了基本的视图元素之外,StatusBar还可以添加自定义的视图,例如用户自定义的快捷开关、应用程序图标等。
这些自定义视图同样可以通过View的方式添加到StatusBar中,并设置合适的LayoutParams进行定位。
总结一下,Android SystemUI Statusbar的层级原理是通过WindowManager来管理StatusBar的窗口类型,在屏幕顶部以独立的层级显示,而StatusBar中的各个视图元素则以View的方式进行添加和展示。
这种层级结构保证了StatusBar的持续显示,并且可以添加自定义的功能和视图元素。
Android8.1SystemUI源码分析之Notification流程

Android8.1SystemUI源码分析之Notification流程代码流程1、先看UI显⽰,StatuBar加载 CollapsedStatusBarFragment 替换 status_bar_container(状态栏通知显⽰区域)SystemUI\src\com\android\systemui\statusbar\phone\StatusBar.javaFragmentHostManager.get(mStatusBarWindow).addTagListener(CollapsedStatusBarFragment.TAG, (tag, fragment) -> {CollapsedStatusBarFragment statusBarFragment =(CollapsedStatusBarFragment) fragment;statusBarFragment.initNotificationIconArea(mNotificationIconAreaController);mStatusBarView = (PhoneStatusBarView) fragment.getView();mStatusBarView.setBar(this);mStatusBarView.setPanel(mNotificationPanel);mStatusBarView.setScrimController(mScrimController);mStatusBarView.setBouncerShowing(mBouncerShowing);setAreThereNotifications();checkBarModes();/// M: add for plmn display feature @{attachPlmnPlugin();///@}}).getFragmentManager().beginTransaction().replace(R.id.status_bar_container, new CollapsedStatusBarFragment(),CollapsedStatusBarFragment.TAG).commit();statusBarFragment.initNotificationIconArea(mNotificationIconAreaController) 初始化通知栏区域,这是我们关⼼的mStatusBarView.setBar(this) 传递statusBar处理下拉事件mStatusBarView.setPanel(mNotificationPanel) 传递 NotificationPanelView 显⽰下拉UI控制2、跟进 CollapsedStatusBarFragment 中,先看布局⽂件 status_bar.xml1、notification_lights_out---ImageView默认gone2、status_bar_contents--LinearLayoutnotification_icon_area--FrameLayoutsystem_icon_area--LinearLayoutsystem_icons.xml(蓝⽛、wifi、VPN、⽹卡、SIM卡信号、飞⾏模式等) 电池clock--Clock.java3、emergency_cryptkeeper_text--ViewStub(延迟加载紧急电话⽂字)这就是我们看到的statusBar的布局,本篇只关⼼ notification_icon_area,其它的以后再进⾏分析。
todo高通AndroidUEFI中的LCD分析(1):启动流程分析

todo⾼通AndroidUEFI中的LCD分析(1):启动流程分析背景之前学习的lk阶段点亮LCD的流程算是⽐较经典,但是⾼通已经推出了很多种基于UEFI⽅案的启动架构。
所以需要对这块⽐较新的技术进⾏学习。
同事遇到了⼀个UEFI阶段LCD显⽰异常,⽽kernel正常的问题;但我解决不了。
分析在⾼通UEFI架构中,通过Protocol来调⽤对应的功能。
因此实际上的函数调⽤并不是显式的,⽽是包裹在Protocol中进⾏。
⾼通UEFI显⽰有关的⽂件有:BOOT.XF.4.1/boot_images/QcomPkg/Drivers/DisplayDxe/DisplayDxe.cBOOT.XF.4.1/boot_images/QcomPkg/Application/QcomChargerApp/QcomChargerAppDisplay.cBOOT.XF.4.1/boot_images/QcomPkg/Application/QcomChargerApp/QcomChargerAppDisplay.hBOOT.XF.4.1/boot_images/QcomPkg/Drivers/DisplayDxe/DisplayDxe.cBOOT.XF.4.1/boot_images/QcomPkg/Drivers/DisplayDxe/DisplayDxe.hBOOT.XF.4.1/boot_images/QcomPkg/Drivers/DisplayDxe/DisplayDxe.infBOOT.XF.4.1/boot_images/QcomPkg/Drivers/DisplayDxe/DisplayPwrCtrlProtocol.cBOOT.XF.4.1/boot_images/QcomPkg/Drivers/DisplayDxe/DisplayPwrProtocol.cBOOT.XF.4.1/boot_images/QcomPkg/Include/Library/BootDisplay.hBOOT.XF.4.1/boot_images/QcomPkg/Include/Library/DisplayLib.hBOOT.XF.4.1/boot_images/QcomPkg/Include/Library/DisplayUtils.hBOOT.XF.4.1/boot_images/QcomPkg/Include/Library/ExternalDisplayDriver.hBOOT.XF.4.1/boot_images/QcomPkg/Include/Protocol/EFIDisplayPwr.hBOOT.XF.4.1/boot_images/QcomPkg/Include/Protocol/EFIDisplayPwrCtrl.hBOOT.XF.4.1/boot_images/QcomPkg/Include/Protocol/EFIDisplayUtils.hBOOT.XF.4.1/boot_images/QcomPkg/Library/BootDisplayLib/BootDisplay.cBOOT.XF.4.1/boot_images/QcomPkg/Library/BootDisplayLib/BootDisplayLib.infBOOT.XF.4.1/boot_images/QcomPkg/Library/DisplayLib/DisplayLib.cBOOT.XF.4.1/boot_images/QcomPkg/Library/DisplayLib/DisplayLib.infBOOT.XF.4.1/boot_images/QcomPkg/Library/ExternalDisplayLib/ExtDisplay_driver.cBOOT.XF.4.1/boot_images/QcomPkg/Library/ExternalDisplayLib/ExternalDisplayLib.decBOOT.XF.4.1/boot_images/QcomPkg/Library/ExternalDisplayLib/ExternalDisplayLib.infBOOT.XF.4.1/boot_images/QcomPkg/Library/ExternalDisplayLib/ExternalDisplayLibStub.infBOOT.XF.4.1/boot_images/QcomPkg/Include/Library/HALMDPLib.hBOOT.XF.4.1/boot_images/QcomPkg/Include/Library/MDPLib.hBOOT.XF.4.1/boot_images/QcomPkg/Include/Library/MDPPeripherals.hBOOT.XF.4.1/boot_images/QcomPkg/Include/Library/MDPPlatformLib.hBOOT.XF.4.1/boot_images/QcomPkg/Include/Library/MDPSystem.hBOOT.XF.4.1/boot_images/QcomPkg/Include/Library/MDPTypes.hBOOT.XF.4.1/boot_images/QcomPkg/Library/MDPLib/DisplayUtils.cBOOT.XF.4.1/boot_images/QcomPkg/Library/MDPLib/MDPClocks.cBOOT.XF.4.1/boot_images/QcomPkg/Library/MDPLib/MDPClocksBoot.cBOOT.XF.4.1/boot_images/QcomPkg/Library/MDPLib/MDPConfig.cBOOT.XF.4.1/boot_images/QcomPkg/Library/MDPLib/MDPEDID.cBOOT.XF.4.1/boot_images/QcomPkg/Library/MDPLib/MDPLib.cBOOT.XF.4.1/boot_images/QcomPkg/Library/MDPLib/MDPLib.infBOOT.XF.4.1/boot_images/QcomPkg/Library/MDPLib/MDPLibBoot.infBOOT.XF.4.1/boot_images/QcomPkg/Library/MDPLib/MDPLib_i.hBOOT.XF.4.1/boot_images/QcomPkg/Library/MDPLib/MDPPanel.cBOOT.XF.4.1/boot_images/QcomPkg/Library/MDPLib/MDPPeripherals.cBOOT.XF.4.1/boot_images/QcomPkg/Library/MDPLib/MDPSystem.cBOOT.XF.4.1/boot_images/QcomPkg/Library/MDPLib/MDPSystemBoot.cBOOT.XF.4.1/boot_images/QcomPkg/Library/MDPLib/MDPVersion.cBOOT.XF.4.1/boot_images/QcomPkg/Library/NullLibs/MDPPlatformLibNull/MDPPlatformLibNull.cBOOT.XF.4.1/boot_images/QcomPkg/Library/NullLibs/MDPPlatformLibNull/MDPPlatformLibNull.infBOOT.XF.4.1/boot_images/QcomPkg/SocPkg/AgattiPkg/Library/MDPPlatformLib/MDPPlatformLib.cBOOT.XF.4.1/boot_images/QcomPkg/SocPkg/AgattiPkg/Library/MDPPlatformLib/MDPPlatformLib.infBOOT.XF.4.1/boot_images/QcomPkg/SocPkg/AgattiPkg/Library/MDPPlatformLib/MDPPlatformLibPanelCommon.cBOOT.XF.4.1/boot_images/QcomPkg/SocPkg/AgattiPkg/Library/MDPPlatformLib/MDPPlatformLibPanelCommon.hBOOT.XF.4.1/boot_images/QcomPkg/SocPkg/AgattiPkg/Library/MDPPlatformLib/MDPPlatformLibPanelConfig.hBOOT.XF.4.1/boot_images/QcomPkg/SocPkg/AgattiPkg/Library/MDPPlatformLibBoot/MDPPlatformLib.cBOOT.XF.4.1/boot_images/QcomPkg/SocPkg/AgattiPkg/Library/MDPPlatformLibBoot/MDPPlatformLibBoot.infBOOT.XF.4.1/boot_images/QcomPkg/SocPkg/KamortaPkg/Library/MDPPlatformLib/MDPPlatformLib.cBOOT.XF.4.1/boot_images/QcomPkg/SocPkg/KamortaPkg/Library/MDPPlatformLib/MDPPlatformLib.infBOOT.XF.4.1/boot_images/QcomPkg/SocPkg/KamortaPkg/Library/MDPPlatformLib/MDPPlatformLibPanelCommon.cBOOT.XF.4.1/boot_images/QcomPkg/SocPkg/KamortaPkg/Library/MDPPlatformLib/MDPPlatformLibPanelCommon.hBOOT.XF.4.1/boot_images/QcomPkg/SocPkg/KamortaPkg/Library/MDPPlatformLib/MDPPlatformLibPanelConfig.hBOOT.XF.4.1/boot_images/QcomPkg/SocPkg/KamortaPkg/Library/MDPPlatformLibBoot/MDPPlatformLib.cBOOT.XF.4.1/boot_images/QcomPkg/SocPkg/KamortaPkg/Library/MDPPlatformLibBoot/MDPPlatformLibBoot.inf对外的Protocol有关⽂件:BOOT.XF.4.1/boot_images/QcomPkg/Include/Protocol/EFIDisplayPwr.hBOOT.XF.4.1/boot_images/QcomPkg/Include/Protocol/EFIDisplayPwrCtrl.hBOOT.XF.4.1/boot_images/QcomPkg/Include/Protocol/EFIDisplayUtils.hProtocol接⼝学习UEFI,⽐较关键的是:0、了解UEFI是如何实现的1、了解XXX_PROTOCOL定义中有什么接⼝可以使⽤:⽅便我们找到实现的原型2、找到对应的XXX_PROTOCOL_GUID是多少:⽅便我们找到哪⾥调⽤了对应的接⼝EFIDisplayPwr.h路径:BOOT.XF.4.1/boot_images/QcomPkg/Include/Protocol/EFIDisplayPwr.h声明了对应的EFI_DISPLAY_POWER_PROTOCOL_GUID,但没有调⽤。
Android之Activity启动流程详解(基于api28)

Android之Activity启动流程详解(基于api28)前⾔Activity作为Android四⼤组件之⼀,他的启动绝对没有那么简单。
这⾥涉及到了系统服务进程,启动过程细节很多,这⾥我只展⽰主体流程。
activity的启动流程随着版本的更替,代码细节⼀直在进⾏更改,每次都会有很⼤的修改,如android5.0 android8.0。
我这⾥的版本是基于android api28,也是⽬前我可以查得到的最新源码了。
事实上⼤题的流程是相同的,掌握了⼀个版本,其他的版本通过源码也可以很快地掌握。
因为涉及到不同的进程之间的通信:系统服务进程和本地进程,在最新版本的android使⽤的是AIDL来跨进程通信。
所以需要对AIDL有⼀定的了解,会帮助理解整个启动流程。
源码部分的讲解涉及到很多的代码讲解,可能会有⼀点不适,但还是建议看完源码。
源码的关键代码处我都会加上注释,⽅便理解。
代码不会过分关注细节,只注重整体流程。
想知道具体细节可以去查看源码。
每份代码所在的路径我都会在代码前⾯标注出来,各位可以去查看相对应的源码。
每部分源码前我都会放流程图,⼀定要配合流程图⾷⽤,不然可能会乱。
整体流程概述这⼀部分侧重于对整个启动流程的概述,在⼼中有⼤体的概念,这样可以帮助对下⾯具体细节流程的理解。
普通Activity的创建普通Activity创建也就是平常我们在代码中采⽤startActivity(Intent intent)⽅法来创建Activity的⽅式。
总体流程如下图:启动过程设计到两个进程:本地进程和系统服务进程。
本地进程也就是我们的应⽤所在进程,系统服务进程为所有应⽤共⽤的服务进程。
整体思路是:1. activity向Instrumentation请求创建2. Instrumentation通过AMS在本地进程的IBinder接⼝,访问AMS,这⾥采⽤的跨进程技术是AIDL。
3. 然后AMS进程⼀系列的⼯作,如判断该activity是否存在,启动模式是什么,有没有进⾏注册等等。
android启动流程

android启动流程Android启动流程:Android是一款广泛使用的移动操作系统,其启动流程是一个相对复杂的过程,涉及到多个模块的加载和启动。
下面将详细介绍Android的启动流程。
1、开机自检(Boot)当手机开机时,首先进行开机自检。
在这个阶段,系统会检测硬件设备的状态,包括电池是否齐全、屏幕是否正常等。
如果硬件设备通过了自检,系统将会开始启动。
2、引导加载程序(Bootloader)开机自检完成后,系统会加载引导加载程序(Bootloader)。
引导加载程序是硬件平台的一部分,其主要作用是启动操作系统。
在加载引导加载程序的过程中,系统会自动检测手机的存储器设备,确定存储设备中是否有可用的引导文件。
3、Linux内核加载一旦引导加载程序找到可用的引导文件,系统将会加载Linux内核。
Linux内核是Android系统的核心组件,负责管理内存、文件系统、驱动程序等。
4、文件系统加载一旦Linux内核加载完成,系统将会加载文件系统。
Android系统使用的是基于Linux的文件系统,在这个过程中,系统会加载并初始化各个文件系统,包括根文件系统、系统文件系统、数据文件系统等。
5、初始化进程(Init)一旦文件系统加载完成,系统将会启动初始化进程(Init)。
初始化进程是Android系统的第一个进程,其作用是启动系统的各个进程和服务。
6、启动用户空间(System Server)在初始化进程启动后,系统会启动用户空间,加载系统的用户界面等组件。
7、启动应用程序一旦用户空间加载完成,系统将会启动应用程序。
应用程序是Android系统的核心功能,包括系统应用程序和用户安装的应用程序。
系统应用程序包括电话、短信、浏览器等,而用户安装的应用程序则是用户根据自己的需求下载和安装的。
8、应用程序启动完成一旦应用程序启动完成,系统将进入正常运行状态,用户可以通过界面操作手机。
总结:Android系统的启动流程是一个复杂而严密的过程,经过开机自检、引导加载程序、Linux内核加载、文件系统加载、初始化进程、启动用户空间、启动应用程序等多个步骤,最终实现用户界面的显示和应用程序的运行。
systemplatform中文说明书

systemplatform中文说明书标题:SystemPlatform中文说明书一、简介SystemPlatform是一款功能强大的系统管理工具,它能够帮助用户进行各种复杂的系统操作。
这份说明书将详细解释如何使用SystemPlatform的各种功能。
二、安装与启动1. 下载最新版本的SystemPlatform安装包,双击运行。
2. 按照提示完成安装过程,建议选择默认设置。
3. 安装完成后,点击桌面图标启动SystemPlatform。
三、界面介绍SystemPlatform的主界面主要包括菜单栏、工具栏、工作区和状态栏四个部分。
四、主要功能1. 系统监控:可以实时查看系统的各项指标,如CPU使用率、内存使用情况等。
2. 进程管理:可以查看并管理当前运行的进程,包括结束进程、调整进程优先级等。
3. 服务管理:可以查看并管理系统的各项服务,包括启动、停止、暂停服务等。
4. 文件管理:提供文件的创建、删除、复制、移动等基本操作,支持网络文件操作。
五、高级功能1. 软件更新:自动检测并更新SystemPlatform到最新版本。
2. 系统优化:提供一系列系统优化工具,提高系统的运行效率。
3. 数据备份:可以对重要的数据进行备份,防止数据丢失。
4. 系统修复:在系统出现问题时,可以帮助用户快速定位并解决问题。
六、注意事项1. 在进行系统操作前,请确保您有充分的理解和准备,避免误操作导致的数据丢失或系统故障。
2. 使用SystemPlatform过程中遇到任何问题,都可以通过我们的客服渠道获取帮助。
七、联系方式如果您有任何关于SystemPlatform的问题或建议,欢迎联系我们:电话:+86-0000-0000邮箱:**************************地址:中国XX省XX市XX区XX路XX号感谢您选择SystemPlatform,我们将竭诚为您服务!以上就是SystemPlatform的中文说明书,希望对您的使用有所帮助。
Android从上层到底层完整流程

Android 上层界面到内核代码的完整的流程分析,以alarm为例子很久之前写的一个流程文档,从上层界面一直调用到内核的过程,最近同事跟我要,我看了下又在整理了下,纯属个人分析(不过都运行验证过),不对的请大牛指出。
Alarm调用流程,alarm的流程实现了从上层应用一直到下面driver的调用流程,下面简单阐述:涉及代码;./packages/apps/DeskClock/src/com/android/deskclock/Alarms.java ./frameworks/base/core/java/android/app/AlarmManager.java./frameworks/base/services/java/com/android/server/AlarmManage rService.java./frameworks/base/services/jni/com_android_server_AlarmManagerS ervice.cpp./kernel/kernel/drivers/rtc/alarm-dev.c./kernel/kernel/include/linux/android_alarm.h./kernel/kernel/drivers/rtc/alarm.c./kernel/kernel/drivers/rtc/interface.c./kernel/kernel/drivers/rtc/rtc-pcf8563.c/packages/apps/DeskClock/src/com/android/deskclock/AlarmRecei ver.java./kernel/arch/arm/configs/mmp2_android_defconfig./kernel/kernel/kernel/.config点击Clock应用程序,然后设置新闹钟,会调到Alarms.java里面的publicstaticlongsetAlarm(Contextcontext,Alarmalarm){....setNextAlert(context);....}然后这里面也会调用到publicstaticvoid setNextAlert(finalContextcontext){if(!enableSnoozeAlert(context)){Alarmalarm=calculateNextAlert(context);//new一个新的alarmif(alarm!=null){enableAlert(context,alarm,alarm.time);}else{disableAlert(context);}}}然后继续调用到privatestaticvoid enableAlert(Contextcontext,finalAlarmalarm,finallo ngatTimeInMillis){.......am.set(AlarmManager.RTC_WAKEUP,atTimeInMillis,sender);//这里是RTC_WAKEUP,这就保证了即使系统睡眠了,都能唤醒,闹钟工作(android平台关机闹钟好像不行).....}然后就调用到了AlarmManager.java里面方法publicvoid set(inttype,longtriggerAtTime,PendingIntentoperation){ try{mService.set(type,triggerAtTime,operation);}catch(RemoteExceptionex){}}然后就调用到了AlarmManagerService.java里面方法publicvoid set(inttype,longtriggerAtTime,PendingIntentoperation){ setRepeating(type,triggerAtTime,0,operation);}然后继续调用publicvoid setRepeating(inttype,longtriggerAtTime,longinterval, PendingIntentoperation){.....synchronized(mLock){Alarmalarm=newAlarm();alarm.type=type;alarm.when=triggerAtTime;alarm.repeatInterval=interval;alarm.operation=operation;//Removethisalarmifalreadyscheduled.removeLocked(operation);if(localLOGV)Slog.v(TAG,"set:"+alarm);intindex=addAlarmLocked(alarm);if(index==0){setLocked(alarm);}}}然后就调用到privatevoid setLocked(Alarmalarm){......//mDescriptor这里的文件是/dev/alarmset(mDescriptor,alarm.type,alarmSeconds,alarmNanoseconds);.....}这里就调用到jni了privatenativevoid set(intfd,inttype,longseconds,longnanosecon ds);这就调用到了com_android_server_AlarmManagerService.cpp里面static JNINativeMethodsMethods[]={/*name,signature,funcPtr*/{"init","()I",(void*)android_server_AlarmManagerService_init},{"close","(I)V",(void*)android_server_AlarmManagerService_close}, {"set","(IIJJ)V",(void*)android_server_AlarmManagerService_set}, {"waitForAlarm","(I)I",(void*)android_server_AlarmManagerService _waitForAlarm},{"setKernelTimezone","(II)I",(void*)android_server_AlarmManager Service_setKernelTimezone},};set对应的是android_server_AlarmManagerService_set,具体是staticvoid android_server_AlarmManagerService_set(JNIEnv*env, jobjectobj,jintfd,jinttype,jlongseconds,jlongnanoseconds){#ifHAVE_ANDROID_OSstructtimespects;_sec=seconds;_nsec=nanoseconds;intresult=ioctl(fd,ANDROID_ALARM_SET(type),&ts);if(result<0){LOGE("Unabletosetalarmto%lld.%09lld:%s\n",seconds,nanosecon ds,strerror(errno));}#endif}然后ioctl就调用到了alarm-dev.cstaticlong alarm_ioctl(structfile*file,unsignedintcmd,unsignedlong arg){....caseANDROID_ALARM_SET(0):if(copy_from_user(&new_alarm_time,(void__user*)arg,sizeof(new_ alarm_time))){rv=-EFAULT;gotoerr1;}from_old_alarm_set:spin_lock_irqsave(&alarm_slock,flags);pr_alarm(IO,"alarm%dset%ld.%09ld\n",alarm_type,new_alarm__sec,new_alarm__nsec);alarm_enabled|=alarm_type_mask;alarm_start_range(&alarms[alarm_type],timespec_to_ktime(new_alarm_time),timespec_to_ktime(new_alarm_time));spin_unlock_irqrestore(&alarm_slock,flags);if(ANDROID_ALARM_BASE_CMD(cmd)!=ANDROID_ALARM_SET_ AND_WAIT(0)&&cmd!=ANDROID_ALARM_SET_AND_WAIT_OLD) break;/*fallthough*/....caseANDROID_ALARM_SET_RTC:if(copy_from_user(&new_rtc_time,(void__user*)arg,sizeof(new_rtc_time))){rv=-EFAULT;gotoerr1;}rv=alarm_set_rtc(new_rtc_time);spin_lock_irqsave(&alarm_slock,flags);alarm_pending|=ANDROID_ALARM_TIME_CHANGE_MASK;wake_up(&alarm_wait_queue);spin_unlock_irqrestore(&alarm_slock,flags);if(rv<0)gotoerr1;break;....}然后这边就调用到了alarm_start_range设置闹钟,alarm_set_rtc设置RTC这两个函数在android_alarm.h声明,在alarm.c里实现。
SystemUI简介

SystemUI简介目录1.SystemUI界面组成 (3)TitleBar状态栏 (3)ToolBar工具栏 (3)StatusBarExpanded通知栏下拉时候的扩展界面 (4)RecentsPanel面板(长按Home键显示出) (4)2.SystemUI代码路径及安装路径 (4)SystemUI根目录 (4)TitleBar目录 (4)ToolBar目录 (4)StatusBarExpanded目录 (4)RecentPanel目录 (4)SystemUI.apk安装目录 (4)3.TitleBar标题栏分析布局简介 (5)控制各布局对应的java类 (5)4.ToolBar工具栏分析 (4)布局简介 (5)控制各布局对应的java类 (6)Android 4.1 (6)Android 4.2 (7)5.RecentsPanel分析 (9)控制各布局对应的java类 (9)6.SystemUI的启动流程 (11)启动流程 (11)7.WiFi,McWill,SIM状态的控制 (12)接收广播的方式来获取各开关状态的变化 (12)titlebar状态图标的设置与移除 (12)titlebar状态图标的设置与移除 (5)一、SystemUI界面组成首先从视沉角度面认识下SystemUI组那几部分组成,都长啥样。
●TitleBar状态栏,在Android 4.1 与Android 4.2相同的●ToolBar工具栏●RecentsPanel面板(长按Home键显示出),在Android 4.1 与Android 4.2相同的二、SystemUI代码路径●SystemUI根目录frameworks/base/packages/SystemUI●TitleBar目录frameworks/base/packages/SystemUI/src/com/android/systemui/statusbarframeworks/base/packages/SystemUI/src/com/android/systemui/statusbar/phone●ToolBar目录frameworks/base/packages/SystemUI/src/com/android/systemui/statusbar/toolbar●StatusBarExpanded目录frameworks/base/packages/SystemUI/ src/com/android/systemui/statusbar●RecentPanel目录frameworks/base/packages/SystemUI/ src/com/android/systemui/recent●SystemUI.apk安装目录安装在手机中的/system/app目录下adb push out/target/product/***/system/app/SystemUI.apk /system/app三、titleBar 标题栏分析●布局简介红色:notificationIcons,通知图标,比如我们常见的360以及QQ等等,都会在这里显示自己的图标;紫色:statusIcons,状态图标,这里会放置系统的一些状态图标,比如像蓝牙、闹钟、耳机插入等等;绿色:信号以及电量图标,这里主要放置了wifi以及手机信号和电池电量的图标;此处图标的动态切换是在TelephonyIcons.java中控制。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Android SystemBar启动流程分析
SystemBars的服务被start时,最终会调用该类的onNoService()方法。
@Override
public void start() {
if (DEBUG) Log.d(TAG, "start");
ServiceMonitor mServiceMonitor = new ServiceMonitor(TAG, DEBUG,
mContext, Settings.Secure.BAR_SERVICE_COMPONENT, this);
mServiceMonitor.start(); // will call onNoService if no remote service is found }
@Override
public void onNoService() {
if (DEBUG) Log.d(TAG, "onNoService");
createStatusBarFromConfig(); // fallback to using an in-process implementation }
private void createStatusBarFromConfig() {
…
mStatusBar = (BaseStatusBar) cls.newInstance();
…
mStatusBar.start();
}
BaseStatusBar是一个抽象类,故调用其子类的PhoneStatusBar的start 函数。
@Override
public void start() {
…
super.start();
…
}
子类的start又调用了父类的start
public void start() {
…
createAndAddWindows();
…
}
protected abstract void createAndAddWindows();
父类的start调用了一个createAndAddWindows()方法,此方法是抽象方法,最终调用的还是PhoneStatusBar的createAndAddWindows方法。
@Override
public void createAndAddWindows() {
addStatusBarWindow();
}
调用addStatusBarWindow()方法
private void addStatusBarWindow() {
makeStatusBarView();
mStatusBarWindowManager = new StatusBarWindowManager(mContext);
mRemoteInputController = new RemoteInputController(mStatusBarWindowManager);
mStatusBarWindowManager.add(mStatusBarWindow, getStatusBarHeight());
}
调用makeStatusBarView();方法,该方法调用后会生成信号栏的view,并且为这些信号的显示添加相应的控制对象。
在这里,创建了mMSimNetworkController对象。
PhoneStatusBarView makeStatusBarView() {
…
mMSimNetworkController = new MSimNetworkControllerImpl(mContext, mSignalThread.getLooper());
…
}
在MSimNetworkControllerImpl类的构造函数中,初始化了卡、信号以及数据的状态,并注册了状态变化的监听。
public MSimNetworkControllerImpl(Context context, Looper bgLooper) {
super(context, bgLooper);
initUIState();
mBackgroundHandler.post(new Runnable() {
@Override
public void run() {
registerPhoneStateListener(mContext);
}
});
registerBroadcastReceive(context);
resetVoLTEStateChangeObserver();
resetTurAccShowStateChangeObserver();
resetSimCardActiveStateChangeObserver();
resetAirplaneChangeObserver();
}。