androidservice权限
A. 针对android 有哪些关于访问访问方面的权限
Android是一个多进程系统，在这个系统中，应用程序（或者系统的部分）会在自己的进程中运行。系统和应用之间的安全性是通过Linux的facilities（工具，功能）在进程级别来强制实现的，比如会给应用程序分配user ID和Group ID。更细化的安全特性是通过"Permission"机制对特定的进程的特定的操作进行限制，而"per-URI permissions"可以对获取特定数据的access专门权限进行限制。
安全架构
Android安全架构中一个中心思想就是：应用程序在默认的情况下不可以执行任何对其他应用程序，系统或者用户带来负面影响的操作。这包括读或写用户的私有数据（如联系人数据或email数据），读或写另一个应用程序的文件，网络连接，保持设备处于非睡眠状态。
一个应用程序的进程就是一个安全的沙盒。它不能干扰其它应用程序，除非显式地声明了"permissions"，以便它能够获取基本沙盒所不具备的额外的能力。它请求的这些权限"permissions"可以被各种各样的操作处理，如自动允许该权限或者通过用户提示或者证书来禁止该权限。应用程序需要的那些"permissions"是静态的在程序中声明，所以他们会在程序安装时就被知晓，并不会再改变。
应用程序签名
所有的Android应用程序（.apk文件）必须用证书进行签名认证，而这个证书的私钥是由开发者保有的。该证书可以用以识别应用程序的作者。该证书也不需要CA签名认证（注：CA就是一个第三方的证书认证机构，如verisign等）。Android应用程序允许而且一般也都是使用self-signed证书（即自签名证书）。证书是用于在应用程序之间建立信任关系，而不是用于控制程序是否可以安装。签名影响安全性的最重要的方式是通过决定谁可以进入基于签名的permisssions，以及谁可以share 用户IDs。
用户IDs和文件存取
每一个Android应用程序（.apk文件）都会在安装时就分配一个独有的Linux用户ID，这就为它建立了一个沙盒，使其不能与其他应用程序进行接触（也不会让其它应用程序接触它）。这个用户ID会在安装时分配给它，并在该设备上一直保持同一个数值。
由于安全性限制措施是发生进程级，所以两个package中的代码不会运行在同一个进程当中，他们要作为不同的Linux用户出现。我们可以通过使用AndroidManifest.xml文件中的manifest标签中的sharedUserId属性，来使不同的package共用同一个用户ID。通过这种方式，这两个package就会被认为是同一个应用程序，拥有同一个用户ID（实际不一定），并且拥有同样的文件存取权限。注意：为了保持安全，只有当两个应用程序被同一个签名签署的时候（并且请求了同一个sharedUserId）才会被分配同样的用户ID.
所有存储在应用程序中的数据都会赋予一个属性-该应用程序的用户ID,这使得其他package无法访问这些数据。当通过这些方法getSharedPreferences(String, int), openFileOutput(String, int), or openOrCreateDatabase(String, int, SQLiteDatabase.CursorFactory)来创建一个新文件时，你可以通过使用MODE_WORLD_READABLE and/or MODE_WORLD_WRITEABLE标志位来设置是否允许其他package来访问读写这个文件。当设置这些标志位时，该文件仍然属于该应用程序，但是它的global read and/or write权限已经被设置，使得它对于其他任何应用程序都是可见的。
Using Permissions 使用权限
一个基本的Android程序通常是没有任何permissions与之关联的，这就是说它不能做任何扰乱用户或破坏数据的勾当。那么为了使用设备被保护的features，我们就必须在AndroidManifest.xml添加一个或多个<uses-permission> 标签，用以声明你的应用程序需要的permissions.
下面是个例子
For example, an application that needs to monitor incoming SMS messages would specify:
Xml代码
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.android.app.myapp" > <uses-permission android:name="android.permission.RECEIVE_SMS" /> ... </manifest>
应用程序安装的时候，应用程序请求的permissions是通过package installer来批准获取的。package installer是通过检查该应用程序的签名和/或用户的交换结果来确定是否给予该程序request的权限。在用户使用过程中不会去检查权限，也就是说要么在安装的时候就批准该权限，使其按照设计可以使用该权限；要么就不批准，这样用户也就根本无法使用该feature,也不会有任何提示告知用户尝试失败。
很多时候, 一个permission failure会导致一个SecurityException被抛回该应用程序. 但是Android并不保证这种情况会处处发生。例如，当数据被deliver到每一个receiver的时候，sendBroadcast(Intent) 方法会去检查permissions,在这个方法调用返回之后，你也不会收到任何exception。几乎绝大多数情况，一个permission failure都会打印到log当中。
Android系统定义的权限可以在Manifest.permission中找到。任何一个程序都可以定义并强制执行自己独有的permissions，因此Manifest.permission中定义的permissions并不是一个完整的列表（即有肯能有自定义的permissions)。
一个特定的permission可能会在程序操作的很多地方都被强制实施：
当系统有来电的时候，用以阻止程序执行其它功能；
启动一个activity的时候，会控制谁可以启动你的Acitivity；
在发送和接收广播的时候，去控制谁可以接收你的广播或谁可以发送广播给你；
当进入并操作一个content provider的时候；
当绑定或开始一个service的时候。
声明和使用Permissions
为了实现你自己的permissions，你必须首先在AndroidManifest.xml文件中声明该permissions.通常我们通过使用一到多个<permission> tag来进行声明。
下面例子说明了一个应用程序它想控制谁才可以启动它的Activity：
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.me.app.myapp" > <permissionandroid:name="com.me.app.myapp.permission.DEADLY_ACTIVITY" android:label="@string/permlab_deadlyActivity"android:description="@string/permdesc_deadlyActivity" android:permissionGroup="android.permission-group.COST_MONEY" android:protectionLevel="dangerous" /> ... </manifest>
这里<protectionLevel>属性是需要声明的（通常系统自有的permission都会有它对应的protection level，而我们自己定义的permission一般都需要定义protecdtion level， 若不去定义，则默认为normal）。通过声明该属性，我们就可以告知系统如何去通告用户以及通告哪些内容，或者告知系统谁才可以拥有该permission。具体请参看链接的文档。
这我多说两句啊，这个protectionLevel分四个等级，分别是Normal, Dangerous, Signature, SignatureOrSystem,越往后安全等级越高。
这个<permissionGroup>属性是可选项, 只是用于帮助系统显示permissions给用户（实际是告知系统该permission是属于哪个permission group的）。你通常会选择使用标准的system group来设定该属性，或者用你自己定义的group（更为罕见）。通常使用一个已经存在的group会更合适，因为这样UI显示的时候会更简单。
需要注意的是label和description都是需要为permission提供的。这些都是字符串资源，当用户去看permission列表(android:label)或者某个permission的详细信息(android:description)时，这些字符串资源就可以显示给用户。label应当尽量简短，之需要告知用户该permission是在保护什么功能就行。而description可以用于具体描述获取该permission的程序可以做哪些事情，实际上让用户可以知道如果他们同意程序获取该权限的话，该程序可以做什么。我们通常用两句话来描述permission，第一句描述该permission，第二句警告用户如果批准该权限会可能有什么不好的事情发生。下面是一个描述CALL_PHONE permission的label和description的例子：
<string name="permlab_callPhone">directly call phone numbers</string> <string name="permdesc_callPhone">Allows the application to call phone numbers without your intervention. Malicious applications may cause unexpected calls on your phone bill. Note that this does not allow the application to call emergency numbers.</string>
你可以通过shell指令 adb shell pm list permissions 来查看目前系统已有的permissions. 特别的，"-s"选项会以一种用户会看到的格式一样的格式来显示这些permissions.
在AndroidManifest.xml中强制使用Permissions
通过AP的AndroidManifest.xml文件可以设置该AP中各个组件的访问权限，包括Activity，
Service，BroadcastReceiver，ContentProvider。这些组件中都包含android:permission属性，设置这个属性就可以控制访问该组件的权限。
Activity permissions权限限制了谁才可以启动相应的activity。Permission会在Context.startActivity()和Activity.startActivityForResult()的时候进行检查，如果caller没有所需的权限，则会抛出一个SecurityException。
Service permissions用于限制谁才可以start或bind该service。在Context.startService() , Context.stopService() 和 Context.bindService() 调用的时候会进行权限检查。如果caller没有所需的权限，则会抛出一个SecurityException。
BroadcastReceiver permissions用于限制谁才可以向该receiver发送广播。权限检查会在Context.sendBroadcast() 返回时进行，由系统去发送已经提交的广播给相应的Receiver。最终，一个permission failure不会再返回给Caller一个exception；它只是不会去deliver该Intent而已。同样地，Context.registerReceiver() 也可以有自己permission用于限制谁才可以向一个在程序中注册的receiver发送广播。另一种方式是，一个permission也可以提供给Context.sendBroadcast() 用以限制哪一个BroadcastReceiver才可以接收该广播。
ContentProvider permission用于限制谁才可以访问ContentProvider提供的数据。（Content providers有一套另外的安全机制叫做URI permissions，这些在稍后讨论）不同于其它的Components，这里有两种不同的permission属性可以设置: android:readPermission 用于限制谁可以读取provider中的数据，而 android:writePermission 用于限制谁才可以向provider中写入数据。需要注意的是如果provider既被read permission保护，也被write permission保护的话，如果这时只有write permission并不意味着你就可以读取provider中的数据了。当你第一次获取provider的时候就要进行权限检查（如果你没有任何permission，则会抛出SecurityException）。当使用ContentResolver.query() 时需要读权限，而当使用 ContentResolver.insert() , ContentResolver.update() , ContentResolver.delete() 时需要写权限。在所有这些情况下，没有所需的permission将会导致SecurityException被抛出。
在Sending Broadcasts时强制使用Permissions
除了之前说过的Permission（用于限制谁才可以发送广播给相应的broadcastReceiver），你还可以在发送广播的时候指定一个permission。在调用Context.sendBroadcast() 的时候使用一个permission string，你就可以要求receiver的宿主程序必须有相应的permission。值得注意的是Receiver和broadcaster都可以要求permission。当这种情况发生时，这两种permission检查都需要通过后才会将相应的intent发送给相关的目的地。
其它强制使用Permissions的方式
在调用service的过程中可以设置任意的fine-grained permissions（这里我理解的是更为细化的权限）。这是通过Context.checkCallingPermission(String) 方法来完成的。呼叫的时候使用一个想得到的permission string，并且当该权限获批的时候可以返回给呼叫方一个Integer（没有获批也会返回一个Integer）。需要注意的是这种情况只能发生在来自另一个进程的呼叫，通常是一个service发布的IDL接口或者是其他方式提供给其他的进程。
Android提供了很多其他的方式用于检查permissions。如果你有另一个进程的pid，你就可以通过context method Context.checkPermission(String, int, int) 去针对那个pid去检查permission。如果你有另一个应用程序的package name，你可以直接用PackageManager method PackageManager.checkPermission(String, String) 来确定该package是否已经拥有了相应的权限。
URI Permissions
到目前为止我们讨论的标准的permission系统对于content provider来说是不够的。一个content provider可能想保护它的读写权限，而同时与它对应的直属客户端也需要将特定的URI传递给其它应用程序，以便其它应用程序对该URI进行操作。一个典型的例子就是邮件程序处理带有附件的邮件。进入邮件需要使用permission来保护，因为这些是敏感的用户数据。然而，如果有一个指向图片附件的URI需要传递给图片浏览器，那个图片浏览器是不会有访问附件的权利的，因为他不可能拥有所有的邮件的访问权限。
针对这个问题的解决方案就是per-URI permission: 当启动一个activity或者给一个activity返回结果的时候，呼叫方可以设置Intent.FLAG_GRANT_READ_URI_PERMISSION 和/或 Intent.FLAG_GRANT_WRITE_URI_PERMISSION . 这会使接收该intent的activity获取到进入该Intent指定的URI的权限，而不论它是否有权限进入该intent对应的content provider。
这种机制允许一个通常的capability-style模型， 这种模型是以用户交互（如打开一个附件, 从列表中选择一个联系人）为驱动，特别获取更细粒化的权限。这是一种减少不必要权限的重要方式，这种方式主要针对的就是那些和程序的行为直接相关的权限。
这些URI permission的获取需要content provider（包含那些URI）的配合。强烈推荐在content provider中提供这种能力，并通过android:grantUriPermissions 或者<grant-uri-permissions> 标签来声明支持。
更多的信息可以参考Context.grantUriPermission() , Context.revokeUriPermission() , and Context.checkUriPermission() methods.
转载
B. Android中怎么启动关闭Service及功能解释
启动：
//首先注册服务
<service
android:name="com.wangdeyu.service.MusicService"
android:exported="false" >
<intent-filter>
<action android:name="com.abc" />
</intent-filter>
</service>
//启动服务
Intent service=new Intent(" com.abc");
startService(service);
//Service生命周期
①onCreate() 创建Service
②onStart(Intent intent, int startId) 启动Service
③onDestroy() 销毁Service
//关闭服务
stopService(service);
Service的生命周期方法比Activity少一些，只有onCreate, onStart, onDestroy
我们有两种方式启动一个Service,他们对Service生命周期的影响是不一样的。
1 通过startService,就是上面这种
Service会经历 onCreate --> onStart
stopService的时候直接onDestroy
如果是 调用者 直接退出而没有调用stopService的话，Service会一直在后台运行。
下次调用者再起来仍然可以stopService。
2 通过bindService
Service只会运行onCreate， 这个时候 调用者和Service绑定在一起
调用者退出了，Srevice就会调用onUnbind-->onDestroyed
所谓绑定在一起就共存亡了。
注意：Service的onCreate的方法只会被调用一次，
就是你无论多少次的startService又 bindService，Service只被创建一次。
如果先是bind了，那么start的时候就直接运行Service的onStart方法，
如果先是start，那么bind的时候就直接运行onBind方法。如果你先bind上了，就stop不掉了，
只能先UnbindService, 再StopService,所以是先start还是先bind行为是有区别的。
Android中的服务和windows中的服务是类似的东西，服务一般没有用户操作界面，它运行于系统中不容易被用户发觉，可以使用它开发如监控之类的程序。
服务不能自己运行，需要通过调用Context.startService()或Context.bindService()方法启动服务。
这两个方法都可以启动Service，但是它们的使用场合有所不同。使用startService()方法启用服务，调用者与服务之间没有关连，
即使调用者退出了，服务仍然运行。使用bindService()方法启用服务，调用者与服务绑定在了一起，调用者一旦退出，服务也就终止，大有“不求同时生，必须同时死”的特点。
如果打算采用Context.startService()方法启动服务，在服务未被创建时，系统会先调用服务的onCreate()方法，
接着调用onStart()方法。如果调用startService()方法前服务已经被创建，多次调用startService()方法并不会导致多次创建服务，
但会导致多次调用onStart()方法。采用startService()方法启动的服务，只能调用Context.stopService()方法结束服务，服务结束时会调用onDestroy()方法。
如果打算采用Context.bindService()方法启动服务，在服务未被创建时，系统会先调用服务的onCreate()方法，
接着调用onBind()方法。这个时候调用者和服务绑定在一起，调用者退出了，系统就会先调用服务的onUnbind()方法，
接着调用onDestroy()方法。如果调用bindService()方法前服务已经被绑定，
多次调用bindService()方法并不会导致多次创建服务及绑定(也就是说onCreate()和onBind()方法并不会被多次调用)。
如果调用者希望与正在绑定的服务解除绑定，可以调用unbindService()方法，调用该方法也会导致系统调用服务的onUnbind()-->onDestroy()方法.
C. Android 服务的限制
Google官网将Android服务分为了三种，前台服务，后台服务和绑定服务：
前台服务执行一些用户能注意到的操作。例如，音频应用会使用前台服务来播放音频曲目。前台服务必须显示 通知 。即使用户停止与应用的交互，前台服务仍会继续运行。
后台服务执行用户不会直接注意到的操作。例如，如果应用使用某个服务来压缩其存储空间，则此服务通常是后台服务。
当应用组件通过调用 bindService() 绑定到服务时，服务即处于 绑定 状态。绑定服务会提供客户端-服务器接口，以便组件与服务进行交互、发送请求、接收结果，甚至是利用进程间通信 (IPC) 跨进程执行这些操作。仅当与另一个应用组件绑定时，绑定服务才会运行。多个组件可同时绑定到该服务，但全部取消绑定后，该服务即会被销毁。
我个人理解服务可以分为两种， 前台 和 后台 ，而 绑定 应该是被当作一种状态，因为 前台服务 和 后台服务 都可以进行绑定。
基于这个理解，我们将限制分成了前台和后台两个部分：
从 Android 5.0（API 级别 21）开始，如果使用隐式 Intent 调用 bindService() ，则系统会抛出异常。为确保应用的安全性，在启动 Service 时，请始终使用显式 Intent，且不要为服务声明 Intent 过滤器。
在后台中运行的 Service 会消耗设备资源，这可能会降低用户体验。 为了缓解这一问题，系统对这些 Service 施加了一些限制。
处于前台时，应用可以自由创建和运行前台与后台 Service。
Android 8.0 开始：系统不允许后台应用创建后台 Service。否则该函数将引发一个 IllegalStateException。
Android 8.0 开始：进入后台时，在一个持续数分钟的时间窗内，应用仍可以创建和使用 Service。 在该时间窗结束后，应用将被视为处于 空闲 状态。 此时，系统将停止应用的后台 Service，就像应用已经调用 Service 的 Service.stopSelf() 方法一样。
为了解除这种限制，可以使用 JobScheler 作业替换后台 Service。
在 Android 8.0 之前，创建前台 Service 的方式通常是先创建一个后台 Service，然后将该 Service 推到前台。
而在Android 8.0 之后，系统不允许后台应用创建后台 Service。
解决方案：调用 startForegroundService() ，以在前台启动新 Service。
在系统创建 Service 后，应用有五秒的时间来调用该 Service 的 startForeground() 方法以显示新 Service 的用户可见通知。 如果应用在此时间限制内 未 调用 startForeground() ，则系统将停止此 Service 并声明此应用为 ANR 。
前台服务必须显示优先级为 PRIORITY_LOW 或更高的 状态栏通知 ，这有助于确保用户知道应用正在执行的任务。如果某操作不是特别重要，因而您希望使用最低优先级通知，则可能不适合使用服务；相反，您可以考虑使用 计划作业 。
在 Android 9 (API 28)之后，使用前台服务必须申请 FOREGROUND_SERVICE 权限，否则会报 SecurityException 。 这是普通权限，因此，系统会自动为请求权限的应用授予此权限。
每个运行服务的应用都会给系统带来额外负担，从而消耗系统资源。如果应用尝试使用低优先级通知隐藏其服务，则可能会降低用户正在主动交互的应用的性能。因此，如果某个应用尝试运行拥有最低优先级通知的服务，则系统会在抽屉式通知栏的底部调用出该应用的行为。
以 Android 12 为目标平台的应用在后台运行时无法再启动 前台服务 。
在 Android 11 及以后，系统对前台服务何时可以访问设备的位置、摄像头或麦克风进行了限制。
如果您的应用以 Android 11 或更高版本为目标平台，且在前台服务中访问摄像头或麦克风，则必须添加 前台服务类型 camera 和 microphone 。
如果你的应用 在后台运行时启动了某项前台服务 ：
如果某服务的功能（位置、麦克风 和 相机）受到了限制，则Logcat中会打印如下语句：
D. 我在android框架层中自定义了一个service，请教一下，该在哪个文件中添加相关权限
也是在AndroidManifest中，service注册后写在 <service >标签里衫帆
application页面application Nodes中点击你要更改的services，右让乱边的permission中改也行。
比如 android.intent.action.ACTION_DATE_CHANGE 即可允许修改系坦塌档统日期
E. Android中怎么启动关闭Service及功能解释
下面根据问题，作出详细解答：
Service不是分离开的进程，除非其他特殊情况，它不会运行在自己的进程，而是作为启动运行它的进程的一部分。
Service不是线程，这意味着它将在主线程里劳作。
启动service有两种方法：
Context.startService()调用者与服务之间没有关联，即使调用者退出，服务仍可运行
Context.bindService() 调用者与服务绑定在一起，调用者一旦退出，服务也就终止
Service的生命周期
如果使用startService()启动service，系统将通过传入的Intent在底层搜索相关符合Intent里面信息的service。如果服务没有启动则先运行onCreate，然后运行onStartCommand （可在里面处理启动时传过来的Intent和其他参数），直到明显调用stopService或者stopSelf才将停止Service。无论运行startService多少次，只要调用一次stopService或者stopSelf，Service都会停止。使用stopSelf(int)方法可以保证在处理好intent后再停止。
控制service运行的主要方式有两种，主要是根据onStartCommand方法返回的数值。方法：
START_STICKY
START_NOT_STICKY or START_REDELIVER_INTENT
这里主要解释这三个变量的意义：
START_STICKY
在运行onStartCommand后service进程被kill后，那将保留在开始状态，但是不保留那些传入的intent。不久后service就会再次尝试重新创建，因为保留在开始状态，在创建 service后将保证调用onstartCommand。如果没有传递任何开始命令给service，那将获取到null的intent
START_NOT_STICKY
在运行onStartCommand后service进程被kill后，并且没有新的intent传递给它。Service将移出开始状态，并且直到新的明显的方法（startService）调用才重新创建。因为如果没有传递任何未决定的intent那么service是不会启动，也就是期间onstartCommand不会接收到任何null的intent。
START_REDELIVER_INTENT
在运行onStartCommand后service进程被kill后，系统将会再次启动service，并传入最后一个intent给onstartCommand。直到调用stopSelf(int)才停止传递intent。如果在被kill后还有未处理好的intent，那被kill后服务还是会自动启动。因此onstartCommand不会接收到任何null的intent。
客户端也可以使用bindService来保持跟service持久关联。谨记：如果使用这种方法，那么将不会调用onstartCommand（跟startService不一样，下面例子注释也有解析，大家可试试）。客户端将会在onBind回调中接收到IBinder接口返回的对象。通常IBinder作为一个复杂的接口通常是返回aidl数据。
Service也可以混合start和bind一起使用。
要运行service，首先必须在AndroidManifest.xml里申明<service>标签。
Service能够保护个人的IPC调用，所以在执行实现该调用时前先使用checkCallingPermission(String) 方法检查是否有这个权限。
进程生命周期
当service运行在低内存的环境时，将会kill掉一下存在的进程。因此进程的优先级将会很重要：
如果service当前正在执行onCreate、onStartCommand、onDestroy方法，主进程将会成为前台进程来保证代码可以执行完成避免被kill
如果service已经启动了，那么主进程将会比其他可见的进程的重要性低，但比其他看不见的进程高。因为只有少部分进程始终是用户可见的，因此除非在极度低内存的时候，不然 service是不会被kill的。
如果有客户端关联到service，那么service永远比客户端重要。也就是说客户端可见，那么service也可见（我理解这里的可见并不是可以看到，而是重要性，因为可见往往就表示重要性高）。
Service可以使用startForeground API将service放到前台状态。这样在低内存时被kill的几率更低，但是文档后面又写了，如果在极度极度低内存的压力下，该service理论上还是会被kill掉。但这个情况基本不用考虑。
当然如果service怎么保持还是被kill了，那你可以通过重写onStartCommand返回变量来设置它的启动方式。比如：START_STICKY、START_REDELIVER_INTENT等等，前面已经讨论了它们的作用，这里就不再累赘了
另外：
service 的onCreate和onStartCommand 是运行在主线程的，所以如果里面有处理耗时间的任务。两种处理：
请将它们都挪到新的线程里。
用系统提供的IntentService，它继承了Service，它处理数据是用自身新开的线程。
F. android调用webservice怎么授权
具体调用调用webservice的方法为：
（1） 指定webservice的命名空间和调用的方法名，如：
SoapObject request =new SoapObject(http://service,”getName”);
SoapObject类的第一个参数表示WebService的命名空间，可以从WSDL文档中找到WebService的命名空间。第二个参数表示要调用的WebService方法名。
（2） 设置调用方法的参数值，如果没有参数，可以省略，设置方法的参数值的代码如下：
Request.addProperty(“param1”,”value”);
Request.addProperty(“param2”,”value”);
要注意的是，addProperty方法的第1个参数虽然表示调用方法的参数名，但该参数值并不一定与服务端的WebService类中的方法参数名一致，只要设置参数的顺序一致即可。
（3） 生成调用Webservice方法的SOAP请求信息。该信息由SoapSerializationEnvelope对象描述，代码为：
SoapSerializationEnvelope envelope=new
SoapSerializationEnvelope(SoapEnvelope.VER11);
Envelope.bodyOut = request;
创建SoapSerializationEnvelope对象时需要通过SoapSerializationEnvelope类的构造方法设置SOAP协议的版本号。该版本号需要根据服务端WebService的版本号设置。在创建SoapSerializationEnvelope对象后，不要忘了设置SOAPSoapSerializationEnvelope类的bodyOut属性，该属性的值就是在第一步创建的SoapObject对象。
（4） 创建HttpTransportsSE对象。通过HttpTransportsSE类的构造方法可以指定WebService的WSDL文档的URL：
HttpTransportSE ht=new HttpTransportSE(“http://192.168.18.17:80
/axis2/service/SearchNewsService?wsdl”);
(5)使用call方法调用WebService方法，代码：
ht.call（null，envelope）；
Call方法的第一个参数一般为null，第2个参数就是在第3步创建的SoapSerializationEnvelope对象。
（6）使用getResponse方法获得WebService方法的返回结果，代码：
SoapObject soapObject =( SoapObject) envelope.getResponse();
G. Android应用程序怎样获取root权限
一般来说， Android 下的应用程序可以“直接”得到的最大的权限为 system ，但是如果我们需要在程序中执行某些需要 root 权限的命令，如 ifconfig 等，就需要 root 权限了。按照 Simon 的文章中提到的，应用程序有以下两种办法临时获得 root 权限：
1) 实现一个 init 实现一个 Service ，来帮助 Android 应用程序执行 root 权限的命令。
2) 实现一个虚拟设备，这个设备帮助 Android 应用程序执行 root 权限的命令。
第二种办法我这里没有尝试，暂时也不会。这里讲讲我在实现第一种办法的过程和遇到的一些问题。
1. 将我们要执行的命令写成脚本，或者可执行程序。
下面是我的脚本 ifconfig_test.sh ：
# ！ /system/bin/sh
ifconfig
注意： 脚本的第一行必须为 # ！ /system/bin/sh ，否则无法执行，通过 dmesg 可以查看到信息内容为 cannot execve ./ifconfig_test.sh: Exec format error
也可以采用 C/C++ 编写需要执行的命令或者程序，并在编译 image 的时候编译成可执行程序。
2. 在 init.rc 中注册 service
Android 中的 service 需要在 init.rc 中注册， Init.rc 中定义的 Service 将会被 init 进程创建，这样将可以获得 root 权限。当得到相应的通知（通过属性设置）后， init 进程会启动该 service 。
本文中注册的内容如下：
service ifconfig_test /system/etc/ifconfig_test.sh
oneshot
disabled
其中， oneshot 表示程序退出后不再重新启动， disabled 表示不在系统启动时启动。
注意： 这里 service name 不能超过 16 个字符。我之前的 service name 由于定义的比较长， 18 个字符，设置属性通知 service 启动后查看 dmesg 可以看到提示： init: no such service 。查看 /system/core/init/parser.c 的源代码，在 parse_service->valid_name 函数中可以看到如下内容： if (strlen(name) > 16) { return 0; } ，证明 service 的名字的确不能超过 16 个字符。
3. 将 Android 应用程序提升为 system 权限
既然应用程序可以通过启动 service 获得 root 权限，那么岂不是很不安全。 Android 考虑到了这点，规定只有 system 权限的应用程序才能设置属性，通知 service 启动。关于提升 system 权限的文章网上已有很多，这里就不再细说，
4. 在应用程序中添加属性设置代码
前面已经提到，对于 Android 来说，应用程序通知 init 启动 service 是通过设置系统属性来完成的，具体为设置 System 系统属性 “ctl.start” 为 “ifconfig_test” ，这样 Android 系统将会帮我们运行 ifconfig_test 这个 service 了。
对该系统属性的设置有三种方法，分别对应三种不同的应用程序：
1) Java 代码
Android 在 Java 库中提供 System.getProperty 和 System.setProperty 方法， Java 程序可以通过他们来设置和获得属性。代码如下：
SystemProperties.set("ctl.start", "ifconfig_test");
上面的代码是通知 Android 执行 ifconfig_test service ，如果需要查询当前 service 执行的状态，如是否执行完毕，可以通过如下代码查询：
ret = SystemProperties.get("init.svc. ifconfig_test ", "");
if(ret != null && ret.equals("stopped"))
{
return true;
}
2） JNI 代码
当编写 NDK 的程序时，可以使用 property_get 和 property_set 这两个 API 来获得和设置属性。使用这两个 API 必须要包含头文件 cutils/properties.h 和链接 libcutil 库。
3） Shell 脚本
Android 提供了命令行 setprop 和 getprop 来设置和获取属性，他们可以在脚本中被使用。
由于我的程序是在 JNI 中调用脚本，脚本中又执行 ifconfig ，因此我将设置属性的部分放在了脚本中完成，代码如下：
setprop ctl.start ifconfig_test
#wait for the service until it stops
ret=1
while [ $ret -ne 0 ]
do
getprop | grep "$ENABLE_MAPPER_SRV" | grep stopped
ret=$?
done
通过上面 4 个步骤， Android 应用程序就获得了 root 权限，更具体的说，是在执行我们需要执行的命令时临时获得了 root 权限。