Android自动弹出软键盘实例方法

本文章来给各位同学介绍Android自动弹出软键盘实例方法，有需要了解的同学可进入参考。

在AndroidManifest.xml文件，对应Activity处增加：android:windowSoftInputMode="stateVisible|adjustResize"

stateVisible：打开Activity时自动弹出软键盘 adjustResize：Acitivity根据屏幕中的软键盘而调整大小，可以让软键盘始终显示在屏幕下方，并且不会将操作按钮覆盖住。

一个超简单的方法可快速实现WebView自适应屏幕宽度,希望此方法对各位同学有所帮助。

// 让网页自适应屏幕宽度

代码如下	复制代码
WebSettings webSettings= webView.getSettings(); webSettings.setLayoutAlgorithm(LayoutAlgorithm.SINGLE_COLUMN);

LayoutAlgorithm是一个枚举，用来控制html的布局，总共有三种类型： NORMAL：正常显示，没有渲染变化。 SINGLE_COLUMN：把所有内容放到WebView组件等宽的一列中。 NARROW_COLUMNS：可能的话，使所有列的宽度不超过屏幕宽度。

 

安卓手机安装软件提示“您的设备不支持add-on属性”的解决方法,有碰此此类问题的朋友可参考本文章来解决，

园子今天使用安卓手机安装游戏时，遇到了提示“您的设备不支持add-on属性”的情况，出现提示后软件就安装不了了。本文分享下使用安卓手机安装软件时出现“您的设备不支持add-on属性”的解决方法。

在网上搜索一番，发现有不少机友也出现了类似情况。出现这种错误提醒大多是因为安装的软件带有运动追踪器、基站定位等功能的软件，主要原因是因为手机中缺少谷歌的服务造成的。使用安卓手机的机友一般比较喜欢刷机，刷的ROM包很多都去掉了谷歌服务套件，部分软件中所带有的类似运动追踪的功能，缺少谷歌服务是无法运行的。下面的方法就是重新把安装此类软件所必须的谷歌服务文件恢复到手机中来解决的。

安卓手机安装软件提示“您的设备不支持add-on属性”的解决方法

1.首页需要 ROOT 你的手机，不清楚如何 ROOT 请自行搜索相关教程。

2.在本文下方下载运行该类软件所必须的谷歌的套件包，解压后得到三个文件。

3.使用RE管理器，把解压后的三个文件分别复制到相应的目录，如果没有，请新建该目录。三个文件对应的目录如下所示：

代码如下	复制代码
/system/framework/com.google.android.maps.jar /system/etc/permission/com.google.android.maps.xml /data/app_s/NetworkLocation.apk

4.修改三个文件的权限，修改方法为：使用RE管理器，挂载读写权限，在对应文件上长按选择“权限”命令。修改后的权限应为：左边全选，中间最上面选上，右边全空。如下图所示：

5.重新启动手机，再次安装该类软件或游戏时，就可以完美安装运行了。

经过以上简单的五步，就完美解决了安卓手机安装软件时提示“您的设备不支持add-on属性”的问题，园子使用的手机型号为中兴U880，其他手机型号请各位自行测试，如遇到问题请留言给我。

本文章来给大家介绍Android的程序解码与XML文件解码详解，有需要了解的同学可参考参考。

首先,怀着无比激动的心情写下这篇日志.....
Googles真的很给力....让我有幸看到ANDROID应用程序的内部源码....
下面开始言归正传:
ANDROID的应用程序是由两部分组成的.
1.*.class文件
2.*.xml文件  解码时候需要使用到不同的工具...
下面开始介绍*.class(类文件的解码)
需要用到的工具:
dex2jar和JD-GUI
dex2jar下载地址：http://laichao.googlecode.com/files/dex2jar-0.0.7-SNAPSHOT.zip
JD-GUI下载地址：
windows版JD-GUI：http://laichao.googlecode.com/files/jdgui.zip
Linux版JD-GUI：http://laichao.googlecode.com/files/jd-gui-0.3.2.linux.i686.tar.gz
 
A:将*.apk文件的后缀修改成*.zip,然后解压,会在文件夹内发现一个叫classes.dex的文件
B:将dex2jar解压后放到C盘根目录,然后将classe.dex放到这个文件夹中来
然后在开始运行中输入CMD,
将路径定位到dex2jar.bat所在的文件夹(dex2jar.bat为dex2jar解压后文件夹内存在的一个*.BAT文件)
然后输入:dex2jar.bat classes.dex
(这里有可能会报错,如果报错好好看一下JAVA的环境变量是什么,配置的对不对)
C:如果一切正常就会解码出来一个*.jar文件
D:用刚才提及到的JD-GUI来解码*.jar文件 (windows环境的直接拖上去可以)
E:很多公司开发出来的源码都是修改了类名,方法名的- -这个比较恶心,也没有什么好办法,只能费点眼神仔细看了....
 
下面是*.xml文件的解码
需要用到的工具:
apktool1.4.1.tar.bz2
apktool-install-windows-r04-brut1.tar.bz2
这两个工具可以在Google官方提供的URL地址:http://code.google.com/p/android-apktool/
上下载
然后解压,
A:两个压缩包内的所有文件都要放在同一个路径下,本人放的还是C盘根目录
B:将需要解码的*.apk文件放到和步骤A中解压的文件相同的路径下(本人放的依旧是C盘根目录)
C:开始--->运行输入CMD,然后定位到C盘,在命令提示框内输入:apktool d C:*.apk  C:***
(*.apk为需要解码的应用程序,***为文件夹名称)
D:解码后就能清晰的看到程序内所有用到的*.XML文件啦...包括布局文件和AndroidManifest.xml文件

ndroid的应用被限制为最多占用16m的内存，至少在T-Mobile G1上是这样的（当然现在已经有几百兆的内存可以用了——译者注）。它包括电话本身占用的和开发者可以使用的两部分。即使你没有占用全部内存的打算，你也应该尽量少的使用内存，以免别的应用在运行的时候关闭你的应用。Android能在内存中保持的应用越多，用户在切换应用的时候就越快。作为我的一项工作，我仔细研究了Android应用的内存泄露问题，大多数情况下它们是由同一个错误引起的，那就是对一个上下文（Context）保持了长时间的引用。

在Android中，上下文（Context）被用作很多操作中，但是大部分是载入和访问资源。这就是所有的widget都会在它们的构造函数中接受一个上下文（Context）参数。在一个合格的Android应用中，你通常能够用到两种上下文（Context）：活动（Activity）和应用（Application）。活动（Activity）通常被传递给需要上下文（Context）参数的类或者
方法：

代码如下	复制代码
@Override protected void onCreate(Bundle state) { super.onCreate(state); TextView label = new TextView(this); label.setText("Leaks are bad"); setContentView(label); }

这就意味着那个View有一个对整个活动（Activity）的引用并且对这个活动（Activity）中保持的所有对象有保持了引用；通常它们包括整个View的层次和它的所有资源。因此，如果你“泄露”了上下文（Context）（这里“泄露”的意思是你保持了一个引用并且组织GC收集它），你将造成大量的内存泄露。如果你不够小心的话，“泄露”一整个活动（Activity）是件非常简单的事情。

当屏幕的方向改变时系统会默认的销毁当前的活动（Activity）并且创建一个新的并且保持了它的状态。这样的结果就是Android会从资源中重新载入应用的UI。现在想象一下，你写了一个应用，有一个非常大的位图，并且你并不想在每次旋转时都重新载入。保留它并且每次旋转不重新加载的最简单的办法就是把它保存在一个静态字段上：

代码如下	复制代码
private static Drawable sBackground; @Override protected void onCreate(Bundle state) { super.onCreate(state); TextView label = new TextView(this); label.setText("Leaks are bad"); if (sBackground == null) { sBackground = getDrawable(R.drawable.large_bitmap); } label.setBackgroundDrawable(sBackground); setContentView(label); }

这段代码非常快，同时也错的够离谱。它泄露了当第一次屏幕角度改变时创建的第一个活动（Activity）。当一个Drawable被附加到一个View，这个View被设置为drawable的一个回调。在上面的代码片断中，这意味着这个Drawable对TextView有一个引用，同时这个TextView对Activity（Context对象）保持着引用，同时这个Activity对很多对象又有引用（这个多少还要看你的代码了）。

这个例子是造成Context泄露的最简单的一个原因，你可以看一下我们在主屏幕源码（查看unbindDrawables()方法）中是通过在Activity销毁时设置保存过的Drawable的回调为空来解决这个问题的。更为有趣的是，你可以创建一个context泄露的链，当然这非常的糟糕。它们可以让你飞快的用光所有的内存。

有两种简单的方法可以避免与context相关的内存泄露。最明显的一个就是避免在context的自身的范围外使用它。上面的例子展示了在类内部的一个静态的引用和它们对外部类的间接引用是非常危险的。第二个解决方案就是使用Application Context。这个context会伴随你的应用而存在，并且不依赖Activity的的生命周期。如果你计划保持一个需要context的长生命周期的对象，请记得考虑Application对象。你可以非常方便的通过调用Context.getApplicationContext() 或者 Activity.getApplication()获取它。

总之，为了避免涉及到context的内存泄露，请记住如下几点：

1.不要对一个Activity Context保持长生命周期的引用（一个对Activity的引用应该与Activity自身的生命周期相同）
2.尝试使用应用上下文（context-application）代替活动上下文（context-activity）
3.如果你不能控制它们的生命周期，在活动（Activity）中避免使用不是静态的内部类，使用静态类并且使用弱引用到活动（Activity）的内部。对于这个问题的解决方法是使用静态的内部类与一个弱引用（WeakReference）的外部类。就像ViewRoot和它的W内部类那么实现的。
4.垃圾回收器对于内存泄露来说并不是百分百保险的。