在上一篇文章中已经提到,Android系统加载应用程序之后,首先会读取该应用程序的AndroidManifest.xml清单文件,之后根据该清单文件加载后边的东西.所以要开发应用程序,自然要先知道清单文件中都记录了什么东西.一般地,在清单文件中声明定义的内容,称为静态注册,相对应地,可以在代码中定义的内容,称为动态注册. 清单文件的存储位置就是应用程序的根目录,而且文件名也是固定的,必须为AndroidManifest.xml,清单文件中所包含的内容在Android官网应用清单文件中可查.其中的…
上回说到应用初始化加载及其生命周期,在Android系统调用Applicaiton.onCreate()之后,继续创建并加载清单文件中注册的首个界面即主Activity,也可称之为入口界面.主Activity的确定规则在Android系统编程入门系列之清单文件有介绍,本文主要介绍Android系统创建Activity之后的生命周期流程. 在清单文件中所注册的界面均为自定义Activity,其父类往上追溯,必须继承自android.content.Activity. 生命周期 Activity作为…
    作为移动端操作系统,目前最新的Android 11.0已经发展的比较完善了,现在也到了系统的整理一番的时间,接下来的系列文章将以Android开发者为中心,争取用归纳总结的态度对初级入门者所应掌握的基础知识聊以标记. 应用环境     Android系统是Google基于Linux系统开发的一套移动系统,不仅应用于手机,还有穿戴设备,TV大屏设备等多种移动场景,其优势是使得硬件具有人性化的界面(Activity),并行的服务(Service),高效的数据存储(ContentProvide…
现在的SIM卡通常具备基站定位.语音通话.短信消息.网络流量这四大功能,而在移动端是无法对SIM卡使用基站定位功能的,所以这里只介绍移动端如何使用SIM卡实现语音通话.短信消息.数据流量三个功能. 语音通话 Android系统中提供了通话服务,同时自带系统级应用可以通过该通话服务使用SIM卡的通话功能.因此在第三方应用中使用语音通话功能,有两种思路.其一是通过应用间唤起,由第三方应用传入指定的Intent意图对象调起系统电话应用,之后在系统电话应用操作完成后返回第三方应用:其二是在第三方应用中直…
应用中关于数据的持久化保存,不管是简单的SharedPreferences还是数据库SQLiteDatabase,本质上都是将数据保存到系统的某种类型的文件中.因此可以直接使用java.io.File文件类将数据以任意类型存取. 在获取到File文件类的对象后,就可以使用其相关方法执行对文件的读写等相关操作,这部分属于Java语言开发或Kotlin语言开发的基础知识,不再多言.而在Android系统上因为各种原因,获取File对象的方式有所区别,本文将重点介绍. 这里需要注意,File文件类不仅…
在上篇文章了解到应用级文件只能被其所创建的应用程序所访问,那么其他应用程序是不是就无论如何都无法访问了呢?肯定不是的,只要文件经过其创建的应用程序授权,还是可以被其他应用程序所访问的.这也就是应用级文件的共享. 系统只允许共享包含实际数据的纯文件类型,而不推荐共享包含文件的目录类型. 对于文件的访问可以使用java.io.File系统文件类,但是如果想将该文件分享出去,则需要借助android.net.Uri路径定位符类.Uri类是Android系统下自定义的路径定位符规则,其符合Java中定义…
上篇文章介绍了应用程序内对用户操作响应的相关方法位置,简单的响应逻辑可以是从一个界面Activity跳转到另一个界面Activity,也可以是某些视图View的相对变化.然而不管是启动一个界面执行新界面Activity的生命周期方法,还是视图的相对变化,都需要一段时间,所以在响应的最终结果完成之前是有一段空白时间的.而在这段或长或短的时间里,该怎么给用户展示界面呢?这就用到Android系统推荐的动画流程了. 广义上说,Android系统在屏幕上绘制展示给用户的内容发生变化时,都可以使用相关动画…
之前几篇文章简单梳理了在Android系统的四大组件之一,最主要的界面Activity中,使应用程序与用户进行交互响应的相关知识点,那对于应用程序中不需要与用户交互的逻辑,又要用到哪些内容呢?本文开始将介绍应用程序无需界面交互的内部交互相关知识点,首先从另外一个四大组件之一的服务Service开始. 在清单文件一文的组件声明中,已经知道服务Service与界面Activity一样,都要在清单文件中注册声明.同样的,每个注册声明的服务Service类向上追溯都必须继承自android.app.Se…
在前边几篇关于Android系统两个重要组件的介绍中,界面Activity负责应用程序与用户的交互,服务Service负责应用程序内部线程间的交互或两个应用程序进程之间的数据交互.看上去这两大组件就能满足日常应用程序的开发需求了,可是应用程序之间的交互,如果都使用服务Service中的AIDL规范,那每个应用程序本身岂不是要声明其他应用程序中的一些接口?这对两个属于不同开发者的应用程序来说很不友好.所以Android系统还提供了称为广播接收者BoradcastReceiver的组件,采用广播机制…
内容提供者ContentProvider与前文的界面Activity.服务Service.广播接收者BroadcastReveiver,并列称为Android的四大组件,均是需要自定义子类继承上述组件类,并在清单文件中静态注册或逻辑代码中动态注册才能正常使用. android.content.ContentProvider内容提供者类,是用来对其他应用程序提供分享数据内容的组件类,在应用程序间的文件共享一文中,针对Android7.0以上版本所注册的FileProvider文件提供者,便是已经定…