在工作中,经常遇到需要修改apk包里的资源文件,达到检验不同配置下程序运行情况的目的. 过程如下: 1.首先连接手机,进入命令行,输入:adb root,使得adb获取root权限. 2.输入:adb shell,进入安卓shell 3.输入:mount -oremount /system,将system路径挂载为可读可执行,否则后边会报Read-only权限问题. 4.输入:chmod 777 system/,修改system及子目录为可读写执行权限. 5.输入:adb push 本地路径+a

把应用push到/system/app下面后,加载.so库的问题 01-01 00:07:08.186: E/MessageQueue-JNI(2683): java.lang.UnsatisfiedLinkError: Couldn't load DeviceAPI from loader dalvik.system.PathClassLoader[DexPathList[[zip file "/system/app/Price1.1.0.apk"],nativeLibraryDir

Service简介 1.Service 每个Service必须在manifest中 通过<service>来声明. 可以通过contect.startservice和contect.bindserverice来启动. 和其他的应用组件一样,运行在进程的主线程中.这就是说如果service需要很多耗时或者阻塞的操作,需要在其子线程中实现(或者用系统提供的IntentService,它继承了Service,它处理数据是用自身新开的线程).[当然你也可以在新的线程中startService,这样Se

序言 最近项目要实现这样一个效果:运行后,要有一个service始终保持在后台运行,不管用户作出什么操作,都要保证service不被kill,这可真是一个难题.参考了现今各种定制版的系统和安全厂商牛虻软件,如何能保证自己的Service不被杀死呢? 其实除了常规的手段,我们可以参考一下微信和360,设置-程序-正在运行,可以看到微信是同时开启了两个进程和服务: [有兴趣可以研究一下 守护进程 和 AIDL ] 我猜想它应该是相互监听,如果有一方被kill掉,另一个捕获到立即启动,以达到servi

环境:已经拥有了root权限的android系统,我们的apk是开机启动 测试:将2个相同的版本拷贝到系统system/app目录下面 adb root #获取root权限,前提是已经开放了root权限,即:debug编译的android系统 adb remount # 将系统目录可写 adb push c:/test_1_v1.apk /system/app #版本号为1,然后重启,再执行下面的步骤 adb push c:/test_2_v1.apk /system/app #版本号仍然为1

一.首先判断root权限: adb root 结果: C:\signapp>adb root restarting adbd as root # 说明有root权限 ,若是adbd cannot run as root in production builds 则说明没有root权限 二.更改system/app内容 一般情况下system/app都会出现read only,所以需要adb remount(这是一个重新mount你的分区的命令,让system分区从只读变成可读可写,获得了root

序言 最近项目要实现这样一个效果:运行后,要有一个service始终保持在后台运行,不管用户作出什么操作,都要保证service不被kill,这可真是一个难题.参考了现今各种定制版的系统和安全厂商牛虻软件,如何能保证自己的Service不被杀死呢? 其实除了常规的手段,我们可以参考一下微信和360,设置-程序-正在运行,可以看到微信是同时开启了两个进程和服务: [有兴趣可以研究一下 守护进程 和 AIDL ] 我猜想它应该是相互监听,如果有一方被kill掉,另一个捕获到立即启动,以达到servi

转发:原文链接http://blog.csdn.net/mad1989/article/details/22492519 序言 最近项目要实现这样一个效果:运行后,要有一个service始终保持在后台运行,不管用户作出什么操作,都要保证service不被kill,这可真是一个难题.参考了现今各种定制版的系统和安全厂商牛虻软件,如何能保证自己的Service不被杀死呢? 其实除了常规的手段,我们可以参考一下微信和360,设置-程序-正在运行,可以看到微信是同时开启了两个进程和服务: [有兴趣可以研

Android开发之如何保证Service不被杀掉(broadcast+system/app) 序言 最近项目要实现这样一个效果:运行后,要有一个service始终保持在后台运行,不管用户作出什么操作,都要保证service不被kill,这可真是一个难题.参考了现今各种定制版的系统和安全厂商牛虻软件,如何能保证自己的Service不被杀死呢? 其实除了常规的手段,我们可以参考一下微信和360,设置-程序-正在运行,可以看到微信是同时开启了两个进程和服务: [有兴趣可以研究一下 守护进程 和 AI

push apk的时候报错 ouyangpeng@oyp-ubuntu:~/apk升级$ adb push Settings2.apk /system/app/ failed to copy 'Settings2.apk' to '/system/app//Settings2.apk': Read-only file system 解决方法:adb remount 一下 ouyangpeng@oyp-ubuntu:~/apk升级$ adb root restarting adbd as root

这段时间由于工作需要,在对android根目录下/system/vold进行修改编译的时候,在通过adb命令将vold文件push至/system/bin目录下,adb reboot重启手机却发现一直停留在开机画面,无法正常进入系统,但是全编之后在进行down机,可以正常开机,通过与全编之前进行对比发现文件权限有所不同.单个模块下编译push的文件权限为666,而全编后down入手机的vold文件的权限为755. 因此,使用adb shell进入手机,使用root权限将system/bin中vo

安卓手机有时候安装的软件多了,用着久了就会出现卡机,死机的现象,流畅度大大的减弱了,实在是影响使用体验.对于这种情况,有的人会经常清理后台程序,可是次数多了,提速的效果也不太明显.那么,到底怎么做才能使自己的安卓手机提速,同时又可以精简系统,清理并扩大内部存储空间呢?准备工作:一.开启ROOT权限.       ROOT方法:下载一键ROOT之类的软件,根据操作步骤进行,就可以获取ROOT权限了.二.安装RE文件管理器. 清理系统自带应用一.用RE打开系统根目录下的system/app,进行精简

注意:以下代码中#开头的则为需要执行的shell命令,其他的为打印的结果.#代表需要使用ROOT权限(su)执行,所以想要修改您android手机某个目录挂载为读写,首先需要有ROOT权限! 先要得到system分区的全名 #adb shell # mount rootfs / rootfs ro 0 0 tmpfs /dev tmpfs rw,mode=755 0 0 devpts /dev/pts devpts rw,mode=600 0 0 proc /proc proc rw 0 0 s

作为移动端APP产品运营最重要的运营手段,消息推送(push)被越来越多的APP厂商所重视,在信息泛滥的移动互联网时代,手机APP应用安装得越来越多,小小的手机屏幕每天收到的消息推送也越来越多,站在用户的角度去想,你会看每一条推送的内容吗? 消息推送(push)是APP运营最优质的渠道,运用得当可以帮助产品运营人员更高效地实现运营目标,相反盲目得push也将带来反作用.APP消息推送具有以下几个特点:①量大,用户数即是可push覆盖的数量.假如一个APP有5000万的活跃用户,且都取得了用户授权

一般情况看到这种提示我们会想到需要root权限,然后敲上adb remount,但是当我们执行过adb remount后,提示成功,但执行push命令依旧无法完成push. 那么此时我们的做法应该是重新插拔USB数据线,并且对重新打开USB调试即可.

      个人建议首先依照android源码的ide/eclipse中的格式化xml和import导入到你编译的eclipse中,假设你编译的android源码是2.3以上的版本号的,建议用JDK6以上,提醒各位的是new androidProject不是Java project.      此时你导入想DeskClock.Camera等没有调用到hide标签的项目时,这些项目都不会报错,你能够直接进行对应的改动或研究.呵呵,假设对应直接在eclipse或手机上执行的话,可能会提示你数字签名不

Android中adb push和adb install的使用区别  转载 本篇文章由史迎春(@三俗小女子)投稿.转载请注明原文地址. 在Android实际开发中,经常会使用adb命令,安装应用程序可以使用adb push 或者adb install.下面就来讲讲这两种安装方式的区别. adb push 能够指定安装目录.比如执行”adb push xxx.apk system/app” 后,xxx.apk被安装到了system/app目录下,此目录下的软件为上文中提到的system appli

1.adb connect 10.100.1.772.adb -s 10.100.1.77 shell remount3.让你自己的APP成为系统应用 adb push xxx.apk system/app //此安装目录下才能成为系统应用 4.Android应用push到/system/app/后so库不能加载 需要将so文件push到系统的/system/lib/目录下(64位系统是/system/lib64/) 如: adb push *.so system/lib 5.java.lang

刚才搞了半天想pull,就是pull不成,如图: 看出哪里有问题了吗? 问题就是我不该在shell里面运行adb pull! 正确的做法: 在任意一处打开命令行比如图中的桌面, adb pull /sdcard/getroot //这会把getroot拉到桌面 adb pull /sdcard/getroot E:/ //这会把getroot拉到E盘,试了一下E后面左斜杠右斜杠都可以,图中的第2次pull后面E写成了分号所以报错 adb push的方法也在图中有了. 注意,/system/app

有时我们需要用unity开发一款Android的系统软件,很坑,步骤如下: 1.用unity打包出来,签名. 2.用解压工具打开签过名的apk. 3.将lib里面的.so文件复制出来. 4.adb root 回车,adb remount 回车,adb shell 回车,cd system/lib 回车, mkdir -p apk的名字  回车(此命令的含义是在lib下建一个名字为“apk名字”的文件夹,很重要), exit 回车. 5.adb push .so文件的路径 /system/lib/