j2me 如何修改manifest.mf文件

MANIFESTMF

用记事本打开修改就行了，前面的项目不可以随便改，有些是一定要有的，有些可以删除，你可以看看人相关说明文档了解各个定义。

如果我们把MANIFEST中的配置信息进行分类，可以归纳出下面几个大类：

一 一般属性

1 Manifest-Version

用来定义manifest文件的版本，例如：Manifest-Version: 10

2 Created-By

声明该文件的生成者，一般该属性是由jar命令行工具生成的，例如：Created-By: Apache Ant 151

3 Signature-Version

定义jar文件的签名版本

4 Class-Path

应用程序或者类装载器使用该值来构建内部的类搜索路径

二 应用程序相关属性

1 Main-Class

定义jar文件的入口类，该类必须是一个可执行的类，一旦定义了该属性即可通过 java -jar xjar来运行该jar文件。

三 小程序(Applet)相关属性

1 Extendsion-List

该属性指定了小程序需要的扩展信息列表，列表中的每个名字对应以下的属性

2 <extension>-Extension-Name

3 <extension>-Specification-Version

4 <extension>-Implementation-Version

5 <extension>-Implementation-Vendor-Id

5 <extension>-Implementation-URL

四 扩展标识属性

1 Extension-Name

该属性定义了jar文件的标识，例如Extension-Name: Struts Framework

五 包扩展属性

1 Implementation-Title 定义了扩展实现的标题

2 Implementation-Version 定义扩展实现的版本

3 Implementation-Vendor 定义扩展实现的组织

4 Implementation-Vendor-Id 定义扩展实现的组织的标识

5 Implementation-URL : 定义该扩展包的下载地址(URL)

6 Specification-Title 定义扩展规范的标题

7 Specification-Version 定义扩展规范的版本

8 Specification-Vendor 声明了维护该规范的组织

9 Sealed 定义jar文件是否封存，值可以是true或者false (这点我还不是很理解)

六 签名相关属性

签名方面的属性我们可以来参照JavaMail所提供的mailjar中的一段

Name: javax/mail/Addressclass

Digest-Algorithms: SHA MD5

SHA-Digest: AjR7RqnN//cdYGouxbd06mSVfI4=

MD5-Digest: ZnTIQ2aQAtSNIOWXI1pQpw==

这段内容定义类签名的类名、计算摘要的算法名以及对应的摘要内容(使用BASE64方法进行编码)

七自定义属性

除了前面提到的一些属性外，你也可以在MANIFESTMF中增加自己的属性以及响应的值，例如J2ME程序jar包中就可能包含着如下信息

MicroEdition-Configuration: CLDC-10

MIDlet-Name: J2ME_MOBBER Midlet Suite

MIDlet-Info-URL: >

怎么在androidmanifest中配置读取联络人许可权

<uses-permission android:name="androidpermissionREAD_CONTACTS"/>

怎么开启读取联络人许可权

苹果的系统没办法，安卓的可以在设定，然后找应用程式，找对应的应用程式，点选进去之后看许可权的各个选项，改他的许可权。

lg手机怎么读取联络人许可权

lg手机怎么读取联络人许可权

你说的这个检视手机获取ROOT许可权了你可以用软体来看啦。

我的手机是用PC版应用宝进行的ROOT，然后用这个软体就可以看啦。

你就先在电脑上安这个软体，开启手机的USB除错，连线之后，

在我的手机选项里面找到工具箱，在工具箱里面可以看到一键ROOT，

进去之后如果你的手机已经ROOT，那会他就会提示你已经ROOT了。

vivo如何读取联络人许可权

请问您是不是指设定联络人隐私许可权的呢，设定联络人隐私许可权，建议您可以进入手机i管家--隐私空间--设定--密码安全设定中设定相应的密码和安全问题的，然后进入i管家软体管理--软体锁--输入您设定的隐私密码--点选电话&联络人右边的锁进行加锁保护的。

禁止读取联络人许可权在哪设定

设定，隐私，把你不想读取联络人许可权的软体关掉。

应用读取联络人许可权，点选某加粉软体时说请先开启应用读取联络人许可权，不知在哪

进入安全中心之类的管理软体，找到应用许可权管理，点选所有英语，找到你想修改许可权的应用，将其读取联络人许可权改为允许就可以了，希望对你有所帮助。

手打不易，还请采纳一下呗(๑>؂<๑）

vivo x5设定了读取联络人许可权后怎么解除

进入手机i管家---软体管理--软体许可权管理将该程式禁止访问联络人即可。

vivoY51应用读取联络人许可权在哪

进入i管家--软体管理--软体许可权管理--访问联络人--将所需要访问联络人的软体开启即可。

oppoa33读取联络人许可权在哪里

A33进入手机安全中心--许可权管理--应用许可权管理，即可设定软体许可权。

软体许可权的设定方法：

ColorOS 30版本，进入手机管家--许可权隐私--应用许可权管理--需要修改许可权的应用进行修改；

ColorOS 21版本，安全中心--许可权隐私--应用许可权管理；

ColorOS 20版本，安全中心--许可权管理--应用许可权管理；

ColorOS 10版本，安全服务--个人资讯保安--按应用程式管理。

请先开启应用读取联络人许可权

说的不明白啊，什么机子 安全中心--授权管理--应用许可权管理--开启联络人许可权

应添加有同样的签名。在Androidstudio11版本中，可以相互读取数据的条件是：有同样的签名，并且AndroidManifestxml文件中配置的android:sharedUserId属性值相同，那么就可以运行在同一个进程中，可以互相访问任意数据。

首面的设置，然后，点击“设置”，“应用和通知”。点击“应用和通知”后出现“权限管理”，点击“权限管理”后，点击你想要设置权限的软件。最后，我们这里选择的是“百度翻译”，可以根据自己的需要在“存储”、“您的位置”、“电话”等选项后进行打开或者关闭。其他软件的权限设置也跟这个是一样的。权限 的目的是保护Android用户的隐私。Android应用必须获得访问敏感用户数据（例如联系人和SMS）以及某些系统功能（例如摄像头和互联网）的权限。根据功能的不同，系统可能会自动授予权限，或者可能提示用户批准请求。

Android安全体系结构的中心设计要点是，默认情况下，没有任何应用程序有权执行任何会对其他应用程序， *** 作系统或用户产生不利影响的 *** 作。这包括读取或写入用户的私人数据（例如联系人或电子邮件），读取或写入其他应用程序的文件，执行网络访问，使设备保持苏醒等。

该页面概述了Android权限的工作方式，包括：如何向用户显示权限，安装时和运行时权限请求之间的区别，权限的执行方式以及权限的类型及其组。如果您只想要使用应用程序权限的使用指南，请参阅“ 请求应用程序权限”。在应用权限的定义与申请一文中，已经将权限分为普通权限与危险权限，而且所有权限都必须静态或动态申请。那么应用程序申请某些权限后可以执行什么 *** 作呢？本文将详细介绍。

对于Android系统中的相关权限，可以参考官方权限列表文档。如在前文提到的外部存储读权限ManifestpermissionREAD_EXTERNAL_STORAGE获取后，应用程序就可以读取外部存储设备上的文件信息、网络访问权限ManifestpermissionINTERNET获取后，应用程序就可以访问互联网、读取联系人权限ManifestpermissionREAD_CONTACTS获取后，应用程序就可以读取手机中保存的联系人列表、等等、系统权限的相关内容便不再赘述。

除此之外，应用程序也可以自定义权限，以对其他使用方提供权限校验。自定义权限的相关定义，同样在应用程序的清单文件中。

使用<permission />标签声明一条自定义权限信息。

在该标签内部，android:name属性可以设置权限名称的字符串，由于应用程序所安装的系统中所有权限都是唯一的，所以权限名称通常以应用程序包名前缀；

还必需设置android:protectionLevel权限级别属性，该属性值只能是系统已经定义的normal普通权限级别、signature签名权限级别、dangerous危险权限级别、或appop特殊权限级别；

另外还有android:label权限标签和android:description权限描述两个属性，均必须以字符串内容赋值，用来介绍权限的相关信息，其中标签属性值要尽可能简短，而描述属性值要尽可能详细。这两个属性在应用程序的权限管理中展示给用户查看。

在该标签中，还可以设置android:permissionGroup权限分组属性，系统权限已经分别归入系统分组中，各系统组别由androidManifestpermission_group静态类中的各字符串常量定义。或者使用标签<permission-group />定义一个新的分组。

不管是系统权限，还是自定义权限，声明方式都是遵循上篇文章中的步骤。

一般在需要系统权限的地方，系统都已经提前写好了相关需求。

而需要自定义权限的相关地方，需要应用程序提前写明。通常是在清单文件中关于四大组件的标签中定义需求权限。在<activity />、<service />、<receiver />中使用android:permission所需权限属性，但是在<provider />有包括android:readPermission读取权限和android:writePermission写入权限两个属性对读取数据和写入数据分别提出权限需求。

这样，其他应用程序或进程在申请启动该组件时，就必须先申请其需求权限，才能正常启动该组件，不然将会抛出javalangSecurityException安全异常。

Android为了保证系统及应用的安全性，在安装APK的时候需要校验包的完整性，同时，对于覆盖安装的场景还要校验新旧是否匹配，这两者都是通过Android签名机制来进行保证的，本文就简单看下Android的签名与校验原理，分一下几个部分分析下：

签名是摘要与非对称密钥加密相相结合的产物，摘要就像内容的一个指纹信息，一旦内容被篡改，摘要就会改变，签名是摘要的加密结果，摘要改变，签名也会失效。Android APK签名也是这个道理，如果APK签名跟内容对应不起来，Android系统就认为APK内容被篡改了，从而拒绝安装，以保证系统的安全性。目前Android有三种签名V1、V2（N）、V3（P），本文只看前两种V1跟V2，对于V3的轮密先不考虑。先看下只有V1签名后APK的样式：

再看下只有V2签名的APK包样式：

同时具有V1 V2签名：

可以看到，如果只有V2签名，那么APK包内容几乎是没有改动的，META_INF中不会有新增文件，按Google官方文档：在使用v2签名方案进行签名时，会在APK文件中插入一个APK签名分块，该分块位于zip中央目录部分之前并紧邻该部分。在APK签名分块内， 签名和签名者身份信息会存储在APK签名方案v2分块中，保证整个APK文件不可修改 ，如下图：

而V1签名是通过META-INF中的三个文件保证签名及信息的完整性：

V1签名是如何保证信息的完整性呢？V1签名主要包含三部分内容，如果狭义上说签名跟公钥的话，仅仅在rsa文件中，V1签名的三个文件其实是一套机制，不能单单拿一个来说事，

如果对APK中的资源文件进行了替换，那么该资源的摘要必定发生改变，如果没有修改MANIFESTMF中的信息，那么在安装时候V1校验就会失败，无法安装，不过如果篡改文件的同时，也修改其MANIFESTMF中的摘要值，那么MANIFESTMF校验就可以绕过。

CERTSF个人觉得有点像冗余，更像对文件完整性的二次保证，同绕过MANIFESTMF一样，SF校验也很容易被绕过。

CERTRSA与CERTSF是相互对应的，两者名字前缀必须一致，不知道算不算一个无聊的标准。看下CERTRSA文件内容：

CERTRSA文件里面存储了证书公钥、过期日期、发行人、加密算法等信息，根据公钥及加密算法，Android系统就能计算出CERTSF的摘要信息，其严格的格式如下：

从CERTRSA中，我们能获的证书的指纹信息，在微信分享、第三方SDK申请的时候经常用到，其实就是公钥+开发者信息的一个签名：

除了CERTRSA文件，其余两个签名文件其实跟keystore没什么关系，主要是文件自身的摘要及二次摘要，用不同的keystore进行签名，生成的MANIFESTMF与CERTSF都是一样的，不同的只有CERTRSA签名文件。也就是说前两者主要保证各个文件的完整性，CERTRSA从整体上保证APK的来源及完整性，不过META_INF中的文件不在校验范围中，这也是V1的一个缺点。V2签名又是如何保证信息的完整性呢？

前面说过V1签名中文件的完整性很容易被绕过，可以理解 单个文件完整性校验的意义并不是很大 ，安装的时候反而耗时，不如采用更加简单的便捷的校验方式。V2签名就不针对单个文件校验了，而是 针对APK进行校验 ，将APK分成1M的块，对每个块计算值摘要，之后针对所有摘要进行摘要，再利用摘要进行签名。

也就是说，V2摘要签名分两级，第一级是对APK文件的1、3 、4 部分进行摘要，第二级是对第一级的摘要集合进行摘要，然后利用秘钥进行签名。安装的时候，块摘要可以并行处理，这样可以提高校验速度。

APK是先摘要，再签名，先看下摘要的定义：Message Digest：摘要是对消息数据执行一个单向Hash，从而生成一个固定长度的Hash值，这个值就是消息摘要，至于常听到的MD5、SHA1都是摘要算法的一种。理论上说，摘要一定会有碰撞，但只要保证有限长度内碰撞率很低就可以，这样就能利用摘要来保证消息的完整性，只要消息被篡改，摘要一定会发生改变。但是，如果消息跟摘要同时被修改，那就无从得知了。

而数字签名是什么呢（公钥数字签名），利用非对称加密技术，通过私钥对摘要进行加密，产生一个字符串，这个字符串+公钥证书就可以看做消息的数字签名，如RSA就是常用的非对称加密算法。在没有私钥的前提下，非对称加密算法能确保别人无法伪造签名，因此数字签名也是对发送者信息真实性的一个有效证明。不过由于Android的keystore证书是自签名的，没有第三方权威机构认证，用户可以自行生成keystore，Android签名方案无法保证APK不被二次签名。

知道了摘要跟签名的概念后，再来看看Android的签名文件怎么来的？如何影响原来APK包？通过sdk中的apksign来对一个APK进行签名的命令如下：

其主要实现在 android/platform/tools/apksig 文件夹中，主体是ApkSignerjava的sign函数，函数比较长，分几步分析

先来看这一步，ApkUtilsfindZipSections，这个函数主要是解析APK文件，获得ZIP格式的一些简单信息，并返回一个ZipSections，

ZipSections包含了ZIP文件格式的一些信息，比如中央目录信息、中央目录结尾信息等，对比到zip文件格式如下：

获取到 ZipSections之后，就可以进一步解析APK这个ZIP包，继续走后面的签名流程，

可以看到先进行了一个V2签名的检验，这里是用来签名，为什么先检验了一次？第一次签名的时候会直接走这个异常逻辑分支，重复签名的时候才能获到取之前的V2签名，怀疑这里获取V2签名的目的应该是为了排除V2签名，并获取V2签名以外的数据块，因为签名本身不能被算入到签名中，之后会解析中央目录区，构建一个DefaultApkSignerEngine用于签名

先解析中央目录区，获取AndroidManifest文件，获取minSdkVersion(影响签名算法)，并构建DefaultApkSignerEngine，默认情况下V1 V2签名都是打开的。

第五步与第六步的主要工作是：apk的预处理，包括目录的一些排序之类的工作，应该是为了更高效处理签名，预处理结束后，就开始签名流程，首先做的是V1签名（默认存在，除非主动关闭）：

步骤7、8、9都可以看做是V1签名的处理逻辑，主要在V1SchemeSigner中处理，其中包括创建META-INFO文件夹下的一些签名文件，更新中央目录、更新中央目录结尾等，流程不复杂，不在赘述，简单流程就是：

这里特殊提一下重复签名的问题： 对一个已经V1签名的APK再次V1签名不会有任何问题 ，原理就是：再次签名的时候，会排除之前的签名文件。

可以看到目录、META-INF文件夹下的文件、sf、rsa等结尾的文件都不会被V1签名进行处理，所以这里不用担心多次签名的问题。接下来就是处理V2签名。

V2SchemeSigner处理V2签名，逻辑比较清晰，直接对V1签名过的APK进行分块摘要，再集合签名，V2签名不会改变之前V1签名后的任何信息，签名后，在中央目录前添加V2签名块，并更新中央目录结尾信息，因为V2签名后，中央目录的偏移会再次改变：

签名校验的过程可以看做签名的逆向，只不过覆盖安装可能还要校验公钥及证书信息一致，否则覆盖安装会失败。签名校验的入口在PackageManagerService的install里，安装官方文档，70以上的手机优先检测V2签名，如果V2签名不存在，再校验V1签名，对于70以下的手机，不存在V2签名校验机制，只会校验V1，所以，如果你的App的miniSdkVersion<24(N)，那么你的签名方式必须内含V1签名：

校验流程就是签名的逆向，了解签名流程即可，本文不求甚解，有兴趣自己去分析，只是额外提下覆盖安装，覆盖安装除了检验APK自己的完整性以外，还要校验证书是否一致只有证书一致（同一个keystore签名），才有可能覆盖升级。覆盖安装同全新安装相比较多了几个校验

这里只关心证书部分：

Android V1及V2签名签名原理简析

仅供参考，欢迎指正

以上就是关于j2me 如何修改manifest.mf文件全部的内容，包括:j2me 如何修改manifest.mf文件、如何获取电脑端软件的渠道号我查到android是在manifest文件里，但是电脑端的在manifest文件找不到、怎么在androidmanifest中配置读取联络人许可权等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！