android:sharedUserId
当APK安装的时候，userid这个标志就会产生。APK在设备上的整个生命周期中，这个ID不再改变。不同设备上同一个应用包可能有不同的userid，重要的是在给定的设备上，每个应用包有自己独立的userid。
userid的特点：
1. 作为APK身份的标识 2. userid对应一个Linux用户，所以不同APK(用户)间互相访问数据默认是禁止的.
那么不同APK之间想要互相访问数据应该怎么办呢？
Android为我们提供了两种数据互访的方法：
一是使用Share Preference. / Content Provider
APK通过指定接口和数据供其它APK读取，开发者需要实现接口和指定share的数据。【此方法后面再详细讲解】
二是在配置文件manifest中配置相同的UserId
通过共享userid,拥有相同userid的用户可以配置成运行在同一进程当中，因此默认就是可以互相访问任意数据的
也可以配置为不同进程当中，彼此之间就像访问自己的数据一样访问彼此的数据库和文件。
例子：
应用程序1：com.wirelessqa.sqlite
01
<manifestxmlns:android="http://schemas.android.com/apk/res/android"
02
package="com.wirelessqa.sqlite"
03
04
android:versionCode="1"
05
06
android:versionName="1.0"
07
08
android:sharedUserId="wirelessqa.com"
09
10
>
应用程序2：com.wirelessqa.activity
1
<manifestxmlns:android="http://schemas.android.com/apk/res/android"
2
package="com.wirelessqa.activity"
3
android:versionCode="1"
4
android:versionName="1.0"
5
android:sharedUserId="wirelessqa.com"
6
>
这两个应用程序的userid相同，都为wirelessqa.com,因此两个应用程序共享userid,如果1想访问2的数据怎么办呢？
Content content = this.createPackageContent(“com.wirelessqa.activity”,Content.CONTENT_IGNORE_SECURITY);
这样通过content可以获取到应用2中的资源，包括：数据库，preference，资源文件等等
注意：
基于安全考虑，两个package需要有相同的签名，否则没有验证，应用程序一旦设置了shareuserid,当程序被破解，其它应用也可以访问我们的数据，数据不安全设置共享也就没有多大意义了。
总结：
如果想要不同的APK之间共享数据需要满足以下条件：
1.APK的签名必须相同
2.android:shareUserId的值必须相同
3.如果想要运行在同一个进行当中，必须设置android:process的值相同。
application设置应用程序的全部组件都运行在某个线程中
1
<application android:allowBackup="true" android:icon="@drawable/ic_launcher" android:label="@string/app_name"
2
3
android:theme="@style/AppTheme" android:process="wqa.com">
android:sharedUserLabel
这个属性给共享的userid定义了一个用户可读的标签。这个标签必须用字符串资源来设置，不能使用原生的字符串。
这个属性在API Level 3中被引入，只有在sharedUserId属性被设置，这个属性才有意义。
android:clearTaskOnLaunch
默认情况下，android:clearTaskOnLaunch的值是false
此时，比如你的应用里有N个Activity，其中有个是设置页面，你从主页面进入到设置页面设置了一些东西之后，突然，按了下Home键，回到了Android的Home，这时候你做了些别的事情，然后你再次点击你的应用程序图标进入你的应用程序的时候，依旧是回到设置页面，继续先前的工作，这也是大多数应用的情况。
但是，如果你把android:clearTaskOnLaunch的值设为true呢？顾名思义，它就在启动的时候把Task给清空了，就是你再次点击应用程序图标进入你的应用程序的时候是回到应用程序的第一个页面，而不会回到先前的设置页面。也就是说不保存先前的设置状态。
至于，什么情况下要这么用，我还没想到，像谷歌的Zxing项目，也就是Android上的“条码扫描器”，它就是这样的，不管你什么时候重新进入该应用，它显示的都是扫描的界面。
不过呢，我也发现了个意外情况，就是即使你把android:clearTaskOnLaunch的值设为了true，但是在Home界面长按Home键，可以调出一个你最近进行的任务，从那个里面点击你的应用是可以回到先前保留的状态的，也就是无视android:clearTaskOnLaunch了，至于为什么，目前还没搞明白，有兴趣的可以去官方查看一下文档，我没有仔细去看。
android:allowTaskReparenting
这个属性用来标记一个Activity实例在当前应用退居后台后，是否能从启动它的那个task移动到有共同affinity的task，“true”表示可以移动，“false”表示它必须呆在当前应用的task中，默认值为false。如果一个这个Activity的元素没有设定此属性，设定在上的此属性会对此Activity起作用。例如在一个应用中要查看一个web页面，在启动系统浏览器Activity后，这个Activity实例和当前应用处于同一个task，当我们的应用退居后台之后用户再次从主选单中启动应用，此时这个Activity实例将会重新宿主到Browser应用的task内，在我们的应用中将不会再看到这个Activity实例，而如果此时启动Browser应用，就会发现，第一个界面就是我们刚才打开的web页面，证明了这个Activity实例确实是宿主到了Browser应用的task内。
android:alwaysRetainTaskState
这个属性用来标记应用的task是否保持原来的状态，“true”表示总是保持，“false”表示不能够保证，默认为“false”。此属性只对task的根Activity起作用，其他的Activity都会被忽略。 默认情况下，如果一个应用在后台呆的太久例如30分钟，用户从主选单再次选择该应用时，系统就会对该应用的task进行清理，除了根Activity，其他Activity都会被清除出栈，但是如果在根Activity中设置了此属性之后，用户再次启动应用时，仍然可以看到上一次操作的界面。 这个属性对于一些应用非常有用，例如Browser应用程序，有很多状态，比如打开很多的tab，用户不想丢失这些状态，使用这个属性就极为恰当。
