强制app使用32位.so库

最新推荐文章于 2021-05-27 17:48:13 发布

大叔小树

最新推荐文章于 2021-05-27 17:48:13 发布

阅读量3k

点赞数 1

分类专栏： android 文章标签： android so 64位

本文链接：https://blog.youkuaiyun.com/wwwbjj1988/article/details/52850842

版权

android 专栏收录该内容

41 篇文章

订阅专栏

当项目里的.so 不支持64位时，可以进行如下设置强制app使用32位.so

defaultConfig {
  ......

    ndk {
        abiFilters "armeabi", "armeabi-v7a", "x86", "mips"
    }


}

gradle.properties 中加入

Android.useDeprecatedNdk=true

然后重新编译就OK了

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

大叔小树

关注关注

1
点赞
踩
5

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

MTK Android12 系统中应用加载 .so 文件的问题分析

我其实什么都不会

08-06

551

在本篇博客中，我将详细总结在 Android 12 系统上进行的几个实验，包括如何加载自定义 JAR 文件、如何解压和确认 .so 文件，以及如何验证系统报错提示。本文将介绍使用 PathClassLoader 和 DexClassLoader 动态加载类的实验，分析系统报错信息，并最终得出结论。

【我的Android进阶之旅】NDK开发引入第三方so库（比如assimp和opencv库）常出现的几个问题：missing and no known rule to make it等

字节卷动

12-13

2047

引入第三方so库遇到的常见错误：错误一、ninja: error: 'xxx.so', needed by 'yyy.so', missing and no known rule to make it 错误二 error: undefined reference to 错误三 java.lang.UnsatisfiedLinkError: dlopen failed: library "libassimp.so" not found

参与评论您还未登录，请先登录后发表或查看评论

Android 64bit系统中app以32bit运行

jiuxin的博客

07-24

8850

Android L后开始支持64位的。大部分系统默认都是以64位进行运行，但是在很多时候我们还是希望我们的app在系统中以32位运行。对于app来说，32bit和64bit主要区别就是JAVA加载so的规则：如果APP需要加载的所有so都是32bit，则使用32bit方式加载so库；如果APP需要加载的so库中只要有一个so是64bit的，则必须以64bit方式加载so库；不能同时加载32bit和64bit的so库。对于系统应用来说，so一般放到 /system/lib/ 或者 /system/li

Android编译32位,android源码用64位系统编译了肿么运行在32位的手机上

weixin_36295555的博客

05-26

464

android源码编译64位改成32位的办法(转载)You are attempting to build on a 32-bit system.Only 64-bit build environments are supported beyond froyo/2.2.需要进行如下修改即可，将./external/clearsilver/cgi/Android.mk./external/clear...

强制生成32位arm程序_苹果微软后，下一代Android也将放弃对32位应用的支持

weixin_39765209的博客

11-24

176

根据开发者的爆料，Android 12的x86_64模拟器已经停止对32位APP的支持，而在2019年8月份谷歌play已经开始强制要求开发者换到64位程序了，这也是为了Android 12提前做准备。来源：鲁大师官方受32位的固有限制影响，不少主流操作系统已经切换到64位环境，比如iOS 11、macOS Catalina等，Windows 10也自v2004版本开始停止向OEM分发3...

android64位机子兼容32位 so库文件,怎样在64位安卓系统中使用32位SO库

weixin_35860804的博客

05-27

2624

满意答案t5858582017.01.25采纳率：46%等级：6已帮助：307人关键点：JAVA编译不分32bit和64bit(APK，JAR)可执行文件，默认编译64位动态库和静态库，默认同时编译32bit和64bit版本通过LOCAL_MULTILIB可以指定特定模块编译32bit或64bit或都编译JAVA加载JNI库(so文件)的规则：如果APP需要加载的所有so都是32bit，则...

解决安卓32位so兼容问题

Android菜鸟的专栏

04-26

1万+

本人遇到的问题为：AndroidStudio更新到最新版本，Gradle插件什么的都更新到了最新版本，运行项目，发现找不到so文件，根据异常信息提示，它是去64位的文件夹里去找so了，这肯定找不到啊，因为我项目的so是32位的，64位的手机不是兼容32位的嘛，而且之前项目运行也好好的，怎么更新开发工具之后出问题了呢？百度里找到了解决方案，但是只说怎么解决，没说原因，为什么会这样？最后还是在Andr...

Android强制安装高版本app,Android adb安装时强制应用App以32位或者64位运行

weixin_35453718的博客

05-27

7619

Android adb安装时强制应用App以32位或者64位运行前言如果只想看结论，请跳转到最后，如果想看看这其中的曲折历程那就按照正常的流程就好了。不要问我为什么会写这么奇葩的博客问题，因为我这是被客户的应用给揉捏的啊。我们的终端是Android 64位的，然后客户提供了一个应用说怎么在我们的终端上运行不了！好吗，那就适配一下就好了吗，可是客户一口肯定的说适配了64位的so库，是我们提供的api...

AndroidStudio打包.so库

tianmao111的专栏

03-17

5770

AndroidStudio版本：2.3 打包方式：CMake 需要的插件：NDK，LLDB 首先下载好以上环境如果上图列表中没有CMake,LLDB等选项，很可能的原因是Android SDK Tools有问题，需要重新下载Android SDK Tools。需要打包的.so库关系比较复杂，出现了动态库依赖动态库的情况，

关于Android的.so文件

jennyliliyang的博客

12-07

619

关于Android的.so文件 CPU架构与ABI的关系 Android系统目前支持以下七种不同的CPU架构：ARMv5，ARMv7 (从2010年起)，x86 (从2011年起)，MIPS (从2012年起)，ARMv8，MIPS64和x86_64 (从2014年起)，每一种都关联着一个相应的ABI。应用程序二进制接口（Application Binary Interface）定义了二进制文件...

如何让 app 支持32位和64位

月落轩痕的专栏

11-07

3673

让App支持32-bit和64-bit基本步骤 1.确保Xcode版本号>=5.0.1 2.更新project settings, minimum deployment target >= 5.1.1 3.改变Architectures为 Standard architectures（include 64-bit） 4.运行测试代码，解决编译warnings and err

针对有些sdk只提供了32位so库问题的处理

qq_22780533的博客

02-03

1060

在做ucloudsdk集成时，由于只提供了32位的so库，所以在jniLibs应该只存在32位的文件夹，即 "armeabi", "armeabi-v7a", "x86", "mips" 但是系统还是会默认的去需找64位的，怎么办呢，那我们就得通知程序我只加载32位的。解决方案也很简单，在build.gradle中加上，这句话的意思大概就是，告诉程序加载如下的so文件 defau

记一篇android加载so文件问题

ZyClient的博客

06-12

1139

前言：在项目中我们不免很多时候需要集成第三方SDK，比如：环信，友盟，七牛云等等，一般来说集成以及初始化SDK按照第三方SDK官方文档来基本上就没什么问题。最近在项目中加载so文件的时候遇到一些问题，在此记录下来希望可以帮助到大家. so文件如果说对so文件分类的话大致就64和32位so文件了，在android的libs或者jnilibs目录下你可能会发现这几种存放so文件的目录。what？这么多目录到底加载哪个目录下的so文件呐？骚年别急嘛。老弟就给你举个列子. android资源文件加载:

Android: 第三方jar打包进APK

TODO: Android; Linux; Cloud;

01-22

1325

Android.mk LOCAL_PATH:= $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE_TAGS := optional LOCAL_SRC_FILES := $(call all-subdir-java-files) LOCAL_PACKAGE_NAME := ACharDemo LOCAL_CE

android 32位so库,couldn't find "libxxx.so"和 Android 8.1 预置32位so库

weixin_29793587的博客

05-27

445

第一步:htmlAndroid studio添加第三方库和soandroid在工程的build.gradle下以下uidefaultConfig {ndk {abiFilters "armeabi", "armeabi-v7a", "x86", "mips"}}而后在工程根目录下的gradle.properties文件中加入：android.useDeprecatedNdk=true.net第二步...

关于 apk 的 native 库加载 32bit/64bit 选择

leonxu_sjtu的博客

04-17

2621

之前跟的项目，那些号称64位 CPU的主控，跑的软件全是 32位的；我仍然很清楚的记得，当年 CEO 在给大家讲解财报，描述技术蓝图的时候，宣称 64bit 软件的运行效率其实远不如预期，因为所有的代码要备两份存储，代码可能要两次加载过程， cache 利用率不高，软件修改量却很大... 好吧，以这位 CEO 后来所表现出来的 RP，他的话应该是一个字也不能信的，我们所知

ANDROID动态加载使用SO库时要注意的一些问题

weixin_34329187的博客

06-04

1184

基本信息作者：kaedea 项目：android-dynamical-loading Android项目里的SO库正好动态加载系列文章谈到了加载SO库的地方，我觉得这里可以顺便谈谈使用SO库时需要注意的一些问题。或许这些问题对于经常和SO库开发打交道的同学来说已经是老生长谈，但是既然要讨论一整个动态加载系列，我想还是有必要说说使用...

如何在64位安卓系统中使用32位SO库

最新发布

03-31

<think>嗯，用户现在遇到了另一个问题，是关于在CentOS 7上运行dotnet时出现的GLIBCXX版本缺失的问题。之前他们可能已经按照之前的指导安装了.NET SDK，但现在运行的时候报错缺少GLIBCXX_3.4.20和3.4.21。我需要先理解这个错误的原因。首先，GLIBCXX是GNU C++标准库的一部分，这些版本符号通常由libstdc++.so.6提供。CentOS 7自带的GCC版本可能比较旧，导致支持的GLIBCXX版本不够新。而.NET SDK 8.0可能需要更新的C++库支持，所以才会出现这个问题。接下来，我需要考虑用户的系统环境。CentOS 7默认的GCC版本是4.8.5，对应的libstdc++.so.6可能只支持到GLIBCXX_3.4.19，而用户需要的3.4.20和3.4.21可能需要更高版本的GCC，比如GCC 5或更高版本。因此，解决方案可能需要升级libstdc++或者安装更新的GCC版本。但CentOS 7的官方仓库可能不提供这些较新的软件包，所以用户可能需要启用额外的仓库，比如EPEL或者第三方仓库如SCL（Software Collections）。或者，用户可能需要手动编译安装GCC，但这比较复杂，容易出错。另外，用户可能已经尝试过安装.NET SDK，但此时遇到了依赖问题，所以需要给出明确的步骤来检查和升级这些库。我需要列出具体的命令，比如如何检查当前支持的GLIBCXX版本，如何安装devtoolset-9或更高版本，或者如何手动下载更新的libstdc++库。此外，还要考虑到用户可能不希望升级整个系统的GCC，所以使用SCL可能是一个更安全的选择，允许他们在需要时启用新版本的GCC而不影响系统全局。同时，需要提醒用户如果手动替换libstdc++.so.6可能会有风险，导致系统不稳定，所以要谨慎操作，并建议备份。还有一种可能是用户的环境中没有正确配置动态库路径，可能需要更新ldconfig或者设置LD_LIBRARY_PATH，但这种情况相对较少。另外，容器化部署也是一个备选方案，比如使用Docker镜像，这样可以避免系统库的兼容性问题。总结下来，我需要分步骤引导用户：首先检查当前GLIBCXX版本，然后通过安装更高版本的GCC工具链来获取所需的库，或者手动安装更新的libstdc++，最后验证是否解决。同时，提供备用方案如容器化部署，以防前面的方法不可行。</think>在CentOS 7系统中运行.NET时出现`GLIBCXX_3.4.20`或`GLIBCXX_3.4.21`缺失的报错，是由于**系统默认GCC运行时库（libstdc++）版本过低**导致。以下是详细解决方案： --- ### **1. 原因分析** - **核心问题**：`.NET 8`依赖的`libstdc++.so.6`需要`GLIBCXX_3.4.20+`，而CentOS 7默认GCC 4.8.5仅支持到`GLIBCXX_3.4.19` - **直接表现**： ```bash strings /lib64/libstdc++.so.6 | grep GLIBCXX # 检查当前支持的版本 ``` 输出中缺少`GLIBCXX_3.4.20`及更高版本 --- ### **2. 标准解决方案：升级GCC工具链** #### 2.1 安装新版GCC（推荐使用SCL仓库） ```bash # 启用Software Collections (SCL) sudo yum install centos-release-scl # 安装GCC 9工具链（提供GLIBCXX_3.4.25） sudo yum install devtoolset-9-gcc devtoolset-9-gcc-c++ # 临时启用新工具链（当前会话生效） scl enable devtoolset-9 bash # 永久启用（所有用户生效） echo "source /opt/rh/devtoolset-9/enable" | sudo tee -a /etc/profile ``` #### 2.2 验证libstdc++版本 ```bash # 检查新版本路径 ls /opt/rh/devtoolset-9/root/usr/lib64/libstdc++.so.6 # 强制链接到系统库目录（谨慎操作！） sudo cp /opt/rh/devtoolset-9/root/usr/lib64/libstdc++.so.6* /usr/lib64/ sudo rm -f /usr/lib64/libstdc++.so.6 sudo ln -s /usr/lib64/libstdc++.so.6.0.28 /usr/lib64/libstdc++.so.6 # 更新动态链接库缓存 sudo ldconfig ``` --- ### **3. 替代方案：手动更新libstdc++** 若无法升级GCC，直接替换库文件： ```bash # 下载预编译的libstdc++.so.6.0.28（兼容CentOS 7） wget http://mirror.centos.org/centos/7/os/x86_64/Packages/libstdc++-4.8.5-44.el7.x86_64.rpm wget http://mirror.centos.org/centos/7/os/x86_64/Packages/libstdc++-devel-4.8.5-44.el7.x86_64.rpm # 强制安装（可能破坏依赖关系！） sudo rpm -Uvh --force libstdc++-*.rpm # 验证版本 strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX ``` --- ### **4. 容器化部署方案** 若系统升级风险过大，建议使用Docker容器： ```dockerfile # Dockerfile示例 FROM mcr.microsoft.com/dotnet/sdk:8.0-jammy AS build WORKDIR /src COPY . . RUN dotnet publish -c Release -o /app FROM mcr.microsoft.com/dotnet/aspnet:8.0-jammy WORKDIR /app COPY --from=build /app . ENTRYPOINT ["dotnet", "YourApp.dll"] ``` Ubuntu Jammy基础镜像已包含所需依赖。 --- ### **5. 关键风险提示** | 操作 | 风险等级 | 缓解措施 | |-----------------------|----------|------------------------------| | 强制替换libstdc++ | ⚠️ 高危 | 提前备份`/usr/lib64/libstdc++*` | | 启用SCL工具链 | ⚠️ 中低 | 仅限开发环境，生产环境建议容器化 | | 系统级GCC升级 | ⚠️ 高危 | 可能导致其他依赖链断裂 | --- ### **验证修复** ```bash # 检查GLIBCXX版本 strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX # 验证.NET运行 dotnet --list-runtimes dotnet your_app.dll ``` --- ### **最终建议** 1. **开发环境**：优先使用`devtoolset-9`临时工具链 2. **生产环境**：强制推荐容器化部署（Docker/Podman） 3. **长期方案**：考虑升级到CentOS Stream 8/9或迁移至Ubuntu LTS 通过以上步骤可解决GLIBCXX版本缺失问题。若仍有异常，建议检查`LD_LIBRARY_PATH`环境变量是否包含新版库路径。