androidapi对应

⑴ android api 签名是什么意思

首先我们得知道什么是摘要，摘要是指采用单向Hash函数对数据进行计算生成的固定长度的Hash值，摘要算法有Md5，Sha1等，Md5生成的Hash值是128位的数字，即16个字节，用十六进制表示是32个字符，Sha1生成的Hash值是160位的数字，即20个字节，用十六进制表示是40个字符。我们是不能通过摘要推算出用于计算摘要的数据，如果修改了数据，那么它的摘要一定会变化(其实这句话并不正确，只是很难正好找到不同的数据，而他们的摘要值正好相等)。摘要经常用于验证数据的完整性，很多下载网站都会列出下载文件的md5值或者sha1值。
摘要和签名没有任何关系，网上常常将摘要和签名混为一谈，这是错误的。签名和数字签名是同一个概念，是指信息的发送者用自己的私钥对消息摘要加密产生一个字符串，加密算法确保别人无法伪造生成这段字符串，这段数字串也是对信息的发送者发送信息真实性的一个有效证明。其他发送者用他们的私钥对同一个消息摘要加密会得到不同的签名，接收者只有使用发送者签名时使用的私钥对应的公钥解密签名数据才能得到消息摘要，否则得到的不是正确的消息摘要。
数字签名是非对称密钥加密技术+数字摘要技术的结合。
数字签名技术是将信息摘要用发送者的私钥加密，和原文以及公钥一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的信息摘要，然后接收者用相同的Hash函数对收到的原文产生一个信息摘要，与解密的信息摘要做比对。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改；不同则说明信息被修改过，因此数字签名能保证信息的完整性。并且由于只有发送者才有加密摘要的私钥，所以我们可以确定信息一定是发送者发送的。
另外还需要理解一个概念：数字证书。数字证书是一个经证书授权中心数字签名的包含公钥及其拥有者信息的文件。数字证书的格式普遍采用的是X.509V3国际标准，一个标准的X.509数字证书包含以下一些内容：证书的版本信息:
1)证书的序列号，每个证书都有一个唯一的证书序列号；
2)证书所使用的签名算法；
3)证书的发行机构名称，命名规则一般采用X.500格式；
4)证书的有效期，通用的证书一般采用UTC时间格式，它的计时范围为1950-2049；
5)证书所有人的名称，命名规则一般采用X.500格式；
6)证书所有人的公开密钥；
7)证书发行者对证书的签名。
CERT.RSA包含了数字签名以及开发者的数字证书。CERT.RSA里的数字签名是指对CERT.SF的摘要采用私钥加密后的数据，Android系统安装apk时会对CERT.SF计算摘要，然后使用CERT.RSA里的公钥对CERT.RSA里的数字签名解密得到一个摘要，比较这两个摘要便可知道该apk是否有正确的签名，也就说如果其他人修改了apk并没有重新签名是会被检查出来的。
需注意Android平台的证书是自签名的，也就说不需要权威机构签发，数字证书的发行机构和所有人是相同的，都是开发者自己，开发者生成公私钥对后不需要提交到权威机构进行校验。

⑵ Android 13 适配指南

2022 的Google I/O 发布了 Android 13 beta 2 和 Android 13 Beta 1 国内厂商的设备支持列表，虽然按照惯例， Android 13 应该是年末才发布正式版，但是相信有的开发者已经收到了平台的 Android13 的适配要求，所以本篇也是结合 Oppo 的 Android 13 应用兼容性适配指导 和官方提供的一些文档内容做一个整理测试。

目前 Android 13 主要的兼容问题还是在于隐私权限上，所以本次的适配指南相关内容也是着重在这一部分， 这里涉及面比较广的应该就是相册和通知权限 。

这个动图大家可能看到过， 这是 Android 13 上提供的系统图片选择器，通过 Intent(MediaStore.ACTION_PICK_IMAGES); 就可以打开，支持视频、音频、图片分类，支持多选和单选 ，另外官方也表示过，这个特性不仅仅会在 Android 13 中出现，谷歌还会将其放置到 Play 商店中，向 Android 11 和 Android 12 设备推送。

我们通过调整 TargetSDK 设置为 PreView ，然后运行到 Tiramisu 的模拟器上进行测试，主要测试 TargetSDK 在低于 "Tiramisu" 和等于 "Tiramisu" 时的不同情况。

如下图所示：

总结： 所以如果是 TargetSDK 在 Android 13 以下，不需要处理，如果在 Android 13 以及以上 ，需要增加申请权限 。

在 Android R 上设置里开始支持在设置里对应用的通知权限进行管理，但是应用自身是无法修改应用级别的通知权限，所以 App 无法知道自身有没有发送通知的权限

所以在 Android 13 里增加了通知的运行时权限 ，其中 Android 13 (33) 的通知会根据正在运行的应用程序的目标 API 级别进行不同的处理， 不过不管应用程序的目标API级别如何，Android 13 都会提示用户授予应用程序发送通知的权限 。

例如下图，是 targetSdk 30 运行在 Android 13 模拟器上，依然会弹出让用户是否允许推送 。

当然，系统也会根据应用程序的目标 API 级别处理通知访问:

如果是 现有应用更新 ，程序的目标 API 级别为：

最后测试和总结一下：

由于 Android 之前可以通过跟踪附近的 Wi-Fi AP 和蓝牙设备来推断设备的位置，所以这次谷歌决定禁止应用程序 访问蓝牙 结果，除非这类应用需要声明 ACCESS_FINE_LOCATION 权限。

在 Android 13 中，Google 将 Wi-Fi 扫描与位置相关内容分离， Android 13 为管理设备与周围 Wi-Fi 热点连接的应用添加 NEARBY_WIFI_DEVICES 运行时权限 (属于 NEARBY_DEVICES 权限组)，从而在不需要 ACCESS_FINE_LOCATION 权限的情况下，也可以让应用访问附近的 Wi-Fi 设备。

此前，对于仅需要连接 Wi-Fi 设备，但实际上并不需要了解设备位置的应用来说，以 Android 13 (33)为目标平台的应用现在可以通过 “ neverForLocation ” 属性来完善申请 NEARBY_WIFI_DEVICES 权限。

这项新权限会影响几个不同的 Wi-Fi 用例，包括以下用例：

所以开发需要区分不同api对应的权限；

由于 NEARBY_WIFI_DEVICES 权限仅适用于 Android 13 或更高版本， 如果是 Android12L(32) 以及以下的 App 应保留对 ACCESS_FINE_LOCATION 的所有声明：

以 Android 13(33) 为目标平台时，如果应用不会通过 Wi-Fi API 推导物理位置，请在清单文件中将 usesPermissionFlags 属性设为 neverForLocation。

所以总结： 以 Android 13(33) 为目标平台的应用程序，访问附近的 WI-FI 设备。除特例API需要申请ACCESS_FINE_LOCATION外，其他需要申请 android.permission.NEARBY_WIFI_DEVICES 运行时权限 ；

Android 13 中引入了 “在使用时” 访问身体传感器（例如心率、体温和血氧饱和度）的概念，此访问模式与 Android 10（API 级别 29）系统为位置信息 引入的模式非常相似。

如果你的 App 以 Android 13(33) 为目标平台，并且在后台运行时需要访问身体传感器信息，那么除了现有的 BODY_SENSORS 权限外，还必须声明新的 BODY_SENSORS_BACKGROUND 权限 。

当 App 以 Android 13(33) 或更高版本为 Target 的其他应用的导出组件发送 intent 时，仅当该 intent 与接收应用中的 <intent-filter> 元素匹配时，系统才会传送该 intent，换言之系统会屏蔽所有不匹配的 intent，但以下情况除外：

为了帮助提高运行时接收器的安全性，Android 13 允许你指定 App 中的特定广播接收器是否应被导出以及是否对设备上的其他应用可见，此变更是 Android 12 更安全的组件 的延续；

以 Android 13(33) 或更高版本为目标平台的应用，必须为每个广播接收器指定 RECEIVER_EXPORTED 或 RECEIVER_NOT_EXPORTED ，否则当 App 尝试注册广播接收器时，系统会抛出 SecurityException

在 Android 13中，谷歌添加了一个新的API，允许开发者降级权限。

应用程序可以触发撤销授予调用 API 的包的一个或多个运行时权限，不需要访问特定运行时权限控制 API 的应用程序可以自行撤销这些权限，这样用户就可以确保这些应用程序不会在不知情的情况下使用这些API。

如需撤消特定运行时权限，请将该权限的名称传入 revokeOwnPermissionOnKill() 方法，如需同时撤消一组运行时权限，请将这组权限的名称传入 revokeOwnPermissionsOnKill() 。

系统只有在安全的情况下才会触发撤消操作，也就是当有应用组件仍在前台运行，或者有另一个应用正在访问你应用的组件（如 content provider）时不会发生撤消。

Android 之前一直提供了一个剪贴板服务，所有 App 都可以使用它来放置和检索文本。

尽管从技术上讲，任何应用都可以清除全局剪贴板中的主内容（只要它们是前台应用或 Android 10+ 上的默认输入法），但 Android 本身不会自动清除剪贴板。

这意味着任何留在全局剪贴板中的剪贴板内容，都可以在以后被应用程序读取，尽管 Android 的剪贴板访问有 toast 消息可能会提醒用户。

Android 13 增加了剪贴板自动清除功能，此功能在默认情况下处于禁用状态，在经过设定的时间后，将自动从全局剪贴板中清除主剪辑， 默认情况下经过3600000毫秒（60分钟）后，剪贴板将被清除。

每次执行复制/读取（写入剪贴板 setPrimaryClip ，读 getPrimaryClip ）时，会重置一个消息 timeout（60min），之后会自动清除剪贴板内存中的内容，即60min内，如果一直没有写入剪贴板的操作，剪贴板的内容会被自动清除。

Android 13 的新前台服务（ Foreground Services：FGS）任务管理器显示当前运行前台服务的应用程序列表，此列表称为活动应用程序，可以通过下拉通知抽屉并点击启示来访问，这时候每个应用程序旁边都会有一个“停止”按钮。

利用 JobScheler，应用可使用 JobInfo.Builder.setPrefetch() 将特定作业标记为“预提取”，这意味着理想情况下这些作业应该在应用下一次启动前提前一点运行，以提升用户体验。

过去，JobScheler 仅使用该信号让预提取作业有机会使用免费或多余的数据，在 Android 13 中系统现在会尝试确定应用下次启动的时间，并根据该估算值运行预提取作业，应用应尝试使用“预提取”来完成他们想要在下次应用启动前完成的任何工作。

Android 13 中引入了 电池资源利用率 功能，以便为系统提供多种方法来更好地管理设备电池续航时间：

⑶ Android之隐藏api介绍

..

Android P 引入了针对非 SDK 接口（俗称为隐藏API）的使用限制。这是继 Android N上针对 NDK 中私有库的链接限制之后的又一次重大调整。

从今以后，不论是native层的NDK还是 java层的SDK，我们只能使用Google提供的、公开的标准接口。这对开发者以及用户乃至整个Android生态，当然是一件好事。

但这也同时意味着Android上的各种黑科技有可能会逐渐走向消亡。

公共 SDK 接口是在 Android 框架软件包索引 中记录的那些接口

从 Android Pie 开始，对某些隐藏类、方法和字段的访问受到限制在 Pie 之前，通过简单地使用反射来使用这些隐藏的非 SDK 组件非常容易。

但是，现在当尝试访问时，面向 API 28 (Pie) 或更高版本的应用程序将遇到 ClassNotFoundException、NoSuchMethodError 或 NoSuchFieldException Activity#createDialog() 。

先来看看系统是如何实现这个限制的。

通过反射或者JNI访问非公开接口时会触发警告/异常等，那么不妨跟踪一下反射的流程，看看系统到底在哪一步做的限制。

先来看一下 java.lang.Class.getDeclaredMethod(String) ：

其中看一下 ShouldBlockAccessToMember 的调用，如果它返回false，那么直接返回 nullptr ，上层就会抛 NoSuchMethodXXX 异常；也就触发系统的限制了。

源码如下：

继续跟踪下 GetMemberAction方法 ：

继续跟踪GetMemberActionImpl方法：

其中调用到了

只要 IsExempted 方法返回 true，就算这个方法在黑名单中，依然会被放行然后允许被调用。

IsExempted 方法：

继续跟踪传递进来的参数 runtime->GetHiddenApiExemptions() 发现也是 runtime 里面的一个参数.

这样就可以直接修改 hidden_api_exemptions_ 绕过去限制。

Java 层的，有一个对应的 VMRuntime.setHiddenApiExemptions 方法,通过 VMRuntime.setHiddenApiExemptions 设置下豁免条件，就能愉快滴使用反射了。

IsExempted 方法里面调用 DoesPrefixMatch 方法。DoesPrefixMatch是对方法签名进行前缀匹配。所有Java方法类的签名都是以 L 开头，这样就可以直接传个 L 进去，所有的隐藏API全部被赦免了！

另一种绕过 Android P以上非公开API限制的办法

⑷ 如何理解android中的api level

就是安卓开发包的版本号，比如安卓4.0对应的level是14，5.0对应的level是19

⑸ api28是安卓什么版本

api28每一个系统版本都对应一个编号的，21代表安卓5.0系统，23代表安卓6.0系统。

api28使用国内镜像，镜像地址在附件中端口80。使用工具进行连接；设置Eclipse的更新地址，将地址设置为本机8580；重新打开SDK Manager 将需要更新或者下载的选项勾上并按 Install Packages即可。

api28常见问题：

api28假设你想在你的窗体模块中声明一个函数，粘贴然后运行，VB会告诉你：编译错误...Declare 语句不允许作为类或对象模块中的Public(公共的) 成员。看起来很糟糕，其实你需要做的只是在声明前面添加一个Private(私有的)。

api28可是这将使该函数只在该窗体模块可用。在有些情况下，你会得到"不明确的名称"这样的提示，这是因为函数、常量或其他的什么东西共用了一个名称。

api28由于绝大多数的函数都进行了别名化，亦即意味着你可以通过Alias子句使用其它的而不是他们原有的名称，你只需简单地改变一下函数名称而它仍然可以正常运行。

⑹ android引用API是不是需要先导入对应的jar包API与jar是什么关系

API 是应用程序编程接口，是一些预先定义的类（java、class文件），我们写程序的时候可以直接使用这些已经被打包（jar包）的类来做具体的应用。我们在搭建jdk开发环境的时候就包含了API。

⑺ Android SDK对应API级别以及版本说明

Android 11 (API 级别 30)

如需详细了解平台变更，请参阅  Android 11 文档 。

Android 10（API 级别 29）

如需详细了解平台变更，请参阅 面向开发者的 Android 10 。

修订版 5（2020 年 7 月）

此修订版本添加了 Android Automotive OS 桩。

Android 9（API 级别 28）

如需详细了解平台变更，请参阅 面向开发者的 Android 9 。

修订版 1（2018 年 8 月）

已发布为稳定版（不再处于预览状态）。

Android 8.1（API 级别 27）

如需详细了解平台变更，请参阅 面向开发者的 Android 8.1 。

修订版 1（2017 年 12 月）

已发布为稳定版（不再处于预览状态）。

Android 8.0（API 级别 26）

如需详细了解平台变更，请参阅 面向开发者的 Android 8.0 。

修订版 2（2017 年 8 月）

Android 7.1（API 级别 25）

如需详细了解平台变更，请参阅 面向开发者的 Android 7.1 。

修订版 3（2016 年 12 月） 修订版 2（2016 年 11 月） 修订版 1（2016 年 10 月）

Android 7.0（API 级别 24）

如需详细了解平台变更，请参阅 面向开发者的 Android 7.0 。

修订版 1（2016 年 8 月）

Android 6.0（API 级别 23）

如需详细了解平台变更，请参阅  Android 6.0 变更 和  Android 6.0 API 。

修订版 2（2015 年 11 月） 修订版 1（2015 年 8 月）

Android 5.1（API 级别 22）

如需详细了解平台变更，请参阅  Lollipop 概览 和  Android 5.1 API 变更 。

修订版 1（2015 年 3 月）

Android 5.0（API 级别 21）

如需详细了解平台变更，请参阅  Lollipop 概览 和  Android 5.0 API 变更 。

修订版 2（2014 年 12 月） 修订版 1（2014 年 10 月）

Android 4.4W（API 级别 20）

此版本使 KitKat 支持 Android Wear。

修订版 2（2014 年 10 月） 修订版 1（2014 年 6 月）

Android 4.4（API 级别 19）

如需详细了解平台变更，请参阅  KitKat 概览 和  Android 4.4 API 变更 。

修订版 2（2013 年 12 月） 修订版 1（2013 年 10 月）

Android 4.3（API 级别 18）

如需详细了解平台变更，请参阅  Jelly Bean 概览 和  Android 4.3 API 变更 。

修订版 2（2013 年 8 月） 修订版 1（2013 年 7 月）

Android 4.2（API 级别 17）

如需详细了解平台变更，请参阅  Jelly Bean 概览 和  Android 4.2 API 变更 。

修订版 2（2013 年 2 月） 修订版 1（2012 年 11 月）

Android 4.1（API 级别 16）

如需详细了解平台变更，请参阅  Jelly Bean 概览 和  Android 4.1 API 变更 。

修订版 3（2012 年 10 月） 修订版 2（2012 年 7 月） 修订版 1 （2012 年 6 月）

Android 4.0.3（API 级别 15）

修订版 3（2012 年 3 月） 修订版 2（2012 年 1 月） 修订版 1（2011 年 12 月）

Android 4.0（API 级别 14）

Android 4.0，修订版 2（2011 年 12 月） Android 4.0，修订版 1（2011 年 10 月）

Android 3.2（API 级别 13）

Android 3.2，修订版 1（2011 年 7 月）

Android 3.1（API 级别 12）

Android 3.1，修订版 3（2011 年 7 月） Android 3.1，修订版 2（2011 年 5 月） Android 3.1，修订版 1（2011 年 5 月）

Android 3.0（API 级别 11）

Android 3.0，修订版 2（2011 年 7 月） Android 3.0，修订版 1（2011 年 2 月）

Android 2.3.3（API 级别 10）

Android 2.3.3，修订版 2（2011 年 7 月） Android 2.3.3，修订版 1（2011 年 2 月）

Android 2.3（API 级别 9）

Android 2.3，修订版 1（2010 年 12 月）

授人以鱼不如授人以渔

https://developer.android.com/studio/releases/platforms?hl=zh-cn

⑻ android 17是哪个版本

Android-17不是手机型号，是android的api版本，意思就是当前Android系统的版本是4.2.2
补充：
android系统版本对应的API定义就是andorid-X，其中X是数字。一个API版本对应一个系统版本。

⑼ android的sdk和api是什么意思

SDK就是Kit，工具箱嘛，IOS平台上就是XCode，一系列的工具组合在一起，比如你在编辑器里敲代码的时候它会自动补全代码，自动错误检查，你点一下Run，它会调用编译器来自动编译，编译完它会调用iPhone的模拟器来运行，这就是SDK，提供整套的开发工具供开发者使用。
OpenAPI就是网站提供的接口，比如你想开发一个围脖的手机客户端，你从哪里读取数据写入数据呢？总不能从Web版里调用吧？那里是一堆一堆的html代码啊，所以OpenAPI就是网站提供的接口，供开发者接入用的，比如聚合数据平台。

SDK (Software Development Kit)翻译成中文就是"软体开发工具组"
是用来帮一个 产品 或 平台 开发应用程式的工具组，由产品的厂商提供给开发者使用的。
通常是 某一家厂商 针对某一 平台 或 系统 或 硬体 所发布出来用以开发应用程式的工具组，
在这个工具包里面，可能包含了各式各样的开发工具，模拟器等。
例如：给 Android平台 使用的 Android SDK 就是用来开发 Android系统上面的应用程式。
API (Application Programming Interface)
翻译成中文就是"应用程式接口"，其实这样翻译不好，应该说是"程式沟通接口"。
翻译为接口，顾名思义就要沟通两个不同的东西用的，通常由一组函式库所组成。
在一个 同一个平台 下的 两个不同东西(程式 or 系统)，为了能取用对方的功能等等，
所以一个 X程式 写了一组函式，让 同一平台的其他程式 取用 X程式 的功能，
那组函式就可以说是那个 X程式 对外开放的 API。
例如：我要在 自己的网页 上加入 google map网页的功能，就使用 "google map API"

有时候 SDK(开发者工具包) 里也会带有些许 API 用来调用一些系统平台程式提供的功能
例如说：视窗显示，图形特效等等。
以下举一个实际例子来说明，调用系统程式功能的API 是怎麽一回事
开发Windows应用程式的SDK(开发者工具包) 里就包含 Win32 API
说明： Win32 API 是一个函式库，可以给Windows应用程式 调用 Windows系统的功能
在PTT看到有人问了差异性，我的看法是
SDK是用来开发某一个平台的程式的工具包，API 是让同一平台下的程式取用它的功能的函式库。
以及下面的评论
1.API 通常大家都不会弄错，的确就是以功能为导向的"方法"或"函式"清单，
看程式语言或平台而定( Methods, Functions... )，
而每个 API 主要都是为了达成某特定功能所设计的。
开发商可以为了不同平台，设计相同的 API 让开发者使用，
也可能会因应不同平台，制作不同的 API 让开发者使用。
2.当 API 数量够多功能够繁复并且可交互为用的时候，
( 例如为了达成某些功能，常需要同时引用某些 APIs 来完成 )
开发商就会为了开发便利，而预先撰写好一些组合好 APIs 的 API
供开发者使用，来统一有特定需求的开发者能有一致的开发与使用体验，
( 例如让使用"网路连线"的开发者不需自己处理网路的基础沟通信息，
与错误处理方式，使 API 在应用的时候有一定程度的便利性等 )
然后，也陆续发展出测试、除错工具，甚至是设计不同平台开发环境所需的套件，
尤其针对不同平台，更是设计了对应的工具来协助开发、除错；
SDK 名词之所以出现，俨然是为了汇整上述这些资源而诞生的，
我想也可以说成是 API 的包含者(直接使用)与应用者(以便加速开发)，
也因此可以说这两个是属于不同层级的东西...