MTK8382/8121平台。
描述：将自定义图片设置成壁纸后，横屏显示时，旋转为竖屏，图片由于分辨率过小，会拉伸；再旋转为横屏，拉伸不恢复。
这两天正在解这个问题，研究了很久，走了不少弯路，最后发现是Launcher读取SharePreferences时的一个bug。
bug是这样产生的：
Launcher3设置完自定义壁纸（系统自带壁纸不会记录）的时候，会在com.android.launcher3.WallpaperCropActivity.xml中记录被设置壁纸的分辨率，并提交分辨率给WallpaperManager（通过suggestWallpaperDimension()）。具体函数是：WallpaperCropActivity.java中的updateWallpaperDimensions()，它被WallpaperCropActivity.java的setWallpaper()调用；
Launcher3每次旋转后会重新执行onCreate()，同时会提交当前壁纸的分辨率给WallpaperManager，提交分辨率的函数在Workspace.java中的setWallpaperDimension()中。问题在这里：setWallpaperDimension()无法获取之前updateWallpaperDimensions()修改的SharedPreferences，导致它提交的是默认的壁纸分辨率1920×1080，从而导致低分辨率的壁纸拉伸。
解决此问题的方法是：修改Workspace.java中的setWallpaperDimension()中的getSharedPreferences()的flag，把MODE_PRIVATE改为MODE_MULTI_PROCESS。修改后成功访问。
我的问题是：
根据Android Developer的解释：
MODE_PRIVATE：
File creation mode: the default mode, where the created file can only be accessed by the calling application (or all applications sharing the same user ID).
即MODEL_PRIVATE只能被同一个application或者同一个userID的application调用。按这个说法，这两个Activity应该是可以共同访问的。（Workspace.java使用的是Launcher.java的context，两个Activity pid不一样，uid一样）
同时我还看了MODE_MULTI_PROCESS的解释：
MODE_MULTI_PROCESS：
SharedPreference loading flag: when set, the file on disk will be checked for modification even if the shared preferences instance is already loaded in this process. This behavior is sometimes desired in cases where the application has multiple processes, all writing to the same SharedPreferences file. Generally there are better forms of communication between processes, though.
This was the legacy (but undocumented) behavior in and before Gingerbread (Android 2.3) and this flag is implied when targetting such releases. For applications targetting SDK versions greater than Android 2.3, this flag must be explicitly set if desired.
意思是这个flag用于给拥有多个进程的application共同访问同一个SharedPreferences使用的。按照这个说法，似乎又确实应该使用MODEL_MULTI_PROCESS。
于是我想找到getSharedPreference实现代码，看看它怎么处理这几个flag。可恶的是，从Activity父类一级一级往上找，都找不到实现的方法，直到找到这篇文章：
http://blog.csdn.net/qinjuning/article/details/7310620
才知道ContextImpl实现了Context的具体方法，进而找到了答案：
ContextImpl类中有getSharedPreferences的实现。里面说明了在MODE_MULTI_PROCESS标志中，getSharedPreferences会进行reload。换言之MODE_PRIVATE不会重新读取SharedPreferences。
这里终于搞懂他的意思：在之前的bug，并不是SharedPreferences获取失败，而是因为没有reload所以没有获取到新写入的分辨率信息。因为之前没有注意到这个问题，所以走了弯路。
不过还有问题：每次Launcher旋转的时候都会重新启动Activity调用onCreate，为什么我getSharePreferences还是旧的呢？继续观察android.app.ContextImpl的getSharedPreferences：
@Override public SharedPreferences getSharedPreferences(String name, int mode) { Log.w("Launcher", "contextImpl: " + this, new RuntimeException("getSp").fillInStackTrace()); SharedPreferencesImpl sp; synchronized (ContextImpl.class) { if (sSharedPrefs == null) { Log.e("Launcher", "all init"); sSharedPrefs = new ArrayMap<String, ArrayMap<String, SharedPreferencesImpl>>(); } final String packageName = getPackageName(); ArrayMap<String, SharedPreferencesImpl> packagePrefs = sSharedPrefs.get(packageName); if (packagePrefs == null) { Log.e("Launcher", "package init"); packagePrefs = new ArrayMap<String, SharedPreferencesImpl>(); sSharedPrefs.put(packageName, packagePrefs); } // At least one application in the world actually passes in a null // name. This happened to work because when we generated the file name // we would stringify it to "null.xml". Nice.
if (mPackageInfo.getApplicationInfo().targetSdkVersion < Build.VERSION_CODES.KITKAT) { if (name == null) { name = "null"; } } sp = packagePrefs.get(name); if (sp == null) { File prefsFile = getSharedPrefsFile(name); sp = new SharedPreferencesImpl(prefsFile, mode); packagePrefs.put(name, sp); Log.e("Launcher", "new sp"); return sp; } Log.e("Launcher", "old sp"); } if ((mode & Context.MODE_MULTI_PROCESS) != 0 || getApplicationInfo().targetSdkVersion < android.os.Build.VERSION_CODES.HONEYCOMB) { // If somebody else (some other process) changed the prefs // file behind our back, we reload it. This has been the // historical (if undocumented) behavior.
sp.startReloadIfChangedUnexpectedly(); Log.e("Launcher", "reload"); } return sp; }
里面Log.e(“Launcher”, …);是我自己加的调试信息。首先会判断sSharedPrefs是否有内容，然后从中获取对应package的prefsFile。如果sSharedPrefs找不到，才从xml文件中重新读取。最后加了一个判断，如果设置了MODE_MULTI_PROCESS变量，或者Android 2.2以下的系统，会默认从xml文件中重新reload，以保持最新的SharedPreferences数据。
注意这里的sSharedPrefs变量，它只在getSharedPreferences中有赋值，也就是说SharedPreferences的数据一直跟随着ContextImpl实例走，只从getSharedPreferences()方法中获取数据。也就是说，当旋转屏幕的时候，我们调用getSharedPreferences()获取的数据都是从这个sSharedPrefs变量中取出来的。实际从下面Log信息也可以看到，旋转并不会有”new sp”的Log打印，只有对Launcher3在设置中force stop和clear data的时候才会出现”new sp”。
旋转的Log提示：
09-11 08:47:19.599: E/Launcher(4628): launcher:com.android.launcher3.Launcher@42392ac8 09-11 08:47:19.599: E/Launcher(4628): mBase:android.app.ContextImpl@424c1898 09-11 08:47:19.608: E/Launcher(4628): old sp 09-11 08:47:19.727: E/Launcher(4628): old sp 09-11 08:47:19.731: E/Launcher(4628): reload 09-11 08:47:19.932: E/Launcher(4628): old sp
force stop的提示：
09-11 08:48:29.456: E/Launcher(5271): launcher:com.android.launcher3.Launcher@4238f220 09-11 08:48:29.456: E/Launcher(5271): mBase:android.app.ContextImpl@42391ab8 09-11 08:48:29.489: E/Launcher(5271): all init 09-11 08:48:29.489: E/Launcher(5271): package init 09-11 08:48:29.493: E/Launcher(5271): new sp 09-11 08:48:29.679: E/Launcher(5271): new sp 09-11 08:48:29.766: E/Launcher(5271): old sp 09-11 08:48:29.767: E/Launcher(5271): old sp 09-11 08:48:29.790: E/Launcher(5271): old sp
里面三个连着的old sp，只有第二个是读取分辨率的，其他两个分辨是LauncherAppState的SharedPreferences。因为此时Launcher3代码已经被我修改为MODE_MULTI_PROCESS，所以旋转会打出”reload”信息。
也就是说，旋转的时候sSharedPrefs的值是一直保存着的。可是通过Log打印信息，我们发现，每一次的getSharedPreferences()的contextImpl都是不一样的！
这里要注意的是，执行方法的context是Activity的父类ContextThemeWrapper的mBase私有成员执行的，获取mBase可以在getSharedPreferences()中打印this出来，也可以在Activity中进行反射，这里用的是反射方法：
try { Log.e("Launcher", "launcher:" + this); java.lang.reflect.Field f = Activity.class.getSuperclass().getDeclaredField("mBase"); f.setAccessible(true); Context s = (Context) f.get(this); Log.e("Launcher", "mBase:" + s); } catch(Exception e) { e.printStackTrace(); }
contextImpl不一样了，但是sSharedPrefs数据还保存着，且sSharedPrefs不能通过其他方法赋值，只能猜测在旋转的时候通过原型模式把原来的context传进去了。Launcher3的旋转处理，我只找到ACTION_CONFIGURATION_CHANGE这个广播，但是我把里面的代码注释了，依然可以正常工作。估计是更底层的代码控制的。
具体代码还没找到，因为还要搬砖。有空再研究吧！
版权所有，转载请注明出处：
http://sickworm.com/?p=17