android - Ice Cream Sandwich 严格模式

Question

我在使用 ICS 和 Widgets 时偶然发现了一个我似乎无法正确调试的问题。

该应用程序有一个主 Activity (WidgetActivity)、一个小部件配置 (WidgetConfigure) 和一个提供程序 (WidgetProvider)。小部件的布局(下面的代码)有一个父 LinearLayout 和两个子 LinearLayout。这两个 child 都设置为不可见。在我的提供商的 onUpdate 中，我实例化了该小部件的 RemoteViews 对象，并尝试将第一个 LinearLayout 设置为可见。

当放置在主屏幕上时，小部件会显示，但两个 child 不会(预期)。当调用 onUpdate 时，子项未设置为可见。我在 adb 中得到的是一堆来自 StrictMode 的关于小部件无法将其状态写入磁盘的警告。存在读写策略违规。由于我实际上并没有在任何地方进行任何读写操作，因此我假设这是一个操作系统调用。

我的问题 - 这种 StrictMode 会导致我的视​​图不改变可见性吗？我理解，在粗略的、高层次上，StrictMode 允许我识别我的 UI 线程中哪里有慢速代码。但我不想在不了解发生了什么的情况下盲目地覆盖或设置新的 StrictMode 设置。

如 adb 所示，我的 onReceive 被调用(如果您再次等待 180000 毫秒)，但我的 subview 未设置为可见。我不确定为什么。

这是代码。小部件布局 xml、提供程序、adb 跟踪:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:background="#FFF"
    android:orientation="vertical" >

    <include layout="@layout/widget_next_season" />

    <include layout="@layout/widget_upcoming_game" />

</LinearLayout>

---

public class WidgetProvider extends AppWidgetProvider {

    private static String TAG = "### WidgetProvider";

    public void onUpdate(Context context, AppWidgetManager appWidgetManager, int[] appWidgetIds) {
        super.onUpdate(context, appWidgetManager, appWidgetIds);
        Log.d(TAG, "onUpdate");

        RemoteViews views = new RemoteViews(context.getPackageName(), R.layout.widget);
        Log.d(TAG, "Got Views");
        views.setViewVisibility(R.id.layout_one, View.VISIBLE);
        Log.d(TAG, "Should've set visibility");
    }
}

---

D/### WidgetProvider(  522): onUpdateD/### WidgetProvider(  522): Got ViewsD/### WidgetProvider(  522): Should've set visibilityI/ActivityManager(   84): Start proc com.android.quicksearchbox for broadcast com.android.quicksearchbox/.CorporaUpdateReceiver: pid=536 uid=10011 gids={3003}D/dalvikvm(   34): GC_EXPLICIT freed 37K, 4% free 9901K/10243K, paused 4ms+6msD/dalvikvm(   84): GC_CONCURRENT freed 496K, 5% free 12726K/13383K, paused 11ms+43msD/StrictMode(   84): StrictMode policy violation; ~duration=2436 ms: android.os.StrictMode$StrictModeDiskReadViolation: policy=151 violation=2D/StrictMode(   84):    at android.os.StrictMode$AndroidBlockGuardPolicy.onReadFromDisk(StrictMode.java:1074)D/StrictMode(   84):    at libcore.io.BlockGuardOs.open(BlockGuardOs.java:94)D/StrictMode(   84):    at libcore.io.IoBridge.open(IoBridge.java:390)D/StrictMode(   84):    at java.io.FileOutputStream.(FileOutputStream.java:88)D/StrictMode(   84):    at com.android.server.AppWidgetService.writeStateToFileLocked(AppWidgetService.java:1220)D/StrictMode(   84):    at com.android.server.AppWidgetService.saveStateLocked(AppWidgetService.java:1204)D/StrictMode(   84):    at com.android.server.AppWidgetService$2.onReceive(AppWidgetService.java:1503)D/StrictMode(   84):    at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:728)D/StrictMode(   84):    at android.os.Handler.handleCallback(Handler.java:605)D/StrictMode(   84):    at android.os.Handler.dispatchMessage(Handler.java:92)D/StrictMode(   84):    at android.os.Looper.loop(Looper.java:137)D/StrictMode(   84):    at com.android.server.ServerThread.run(SystemServer.java:744)D/StrictMode(   84): StrictMode policy violation; ~duration=2301 ms: android.os.StrictMode$StrictModeDiskWriteViolation: policy=151 violation=1D/StrictMode(   84):    at android.os.StrictMode$AndroidBlockGuardPolicy.onWriteToDisk(StrictMode.java:1048)D/StrictMode(   84):    at libcore.io.BlockGuardOs.write(BlockGuardOs.java:178)D/StrictMode(   84):    at libcore.io.IoBridge.write(IoBridge.java:447)D/StrictMode(   84):    at java.io.FileOutputStream.write(FileOutputStream.java:187)D/StrictMode(   84):    at com.android.internal.util.FastXmlSerializer.flushBytes(FastXmlSerializer.java:212)D/StrictMode(   84):    at com.android.internal.util.FastXmlSerializer.flush(FastXmlSerializer.java:233)D/StrictMode(   84):    at com.android.internal.util.FastXmlSerializer.endDocument(FastXmlSerializer.java:183)D/StrictMode(   84):    at com.android.server.AppWidgetService.writeStateToFileLocked(AppWidgetService.java:1266)D/StrictMode(   84):    at com.android.server.AppWidgetService.saveStateLocked(AppWidgetService.java:1204)D/StrictMode(   84):    at com.android.server.AppWidgetService$2.onReceive(AppWidgetService.java:1503)D/StrictMode(   84):    at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:728)D/StrictMode(   84):    at android.os.Handler.handleCallback(Handler.java:605)D/StrictMode(   84):    at android.os.Handler.dispatchMessage(Handler.java:92)D/StrictMode(   84):    at android.os.Looper.loop(Looper.java:137)D/StrictMode(   84):    at com.android.server.ServerThread.run(SystemServer.java:744)

Answer 1

事实上，原因是 StrictMode。我通过确保我的网络代码在 Service 中而不是在小部件的 onUpdate 中解决了这个问题。尽管如此，Android 仍然提示违反了网络和光盘访问的 StrictMode。

为了解决这个问题，我修改了 StrictMode 策略，并在完成后重置它。我只是围绕网络代码调用这些函数。

/**
 * Prevent exceptions from doing disk and network operations in a service
 */
protected static void setPermissiveThreadPolicy() {
    // set StrictMode to allow network/disk in service
    oldThreadPolicy = StrictMode.getThreadPolicy();
    StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder(oldThreadPolicy).permitNetwork().permitDiskReads().permitDiskWrites().build());
}

/**
 * Reset thread policy to previously known state for consistency
 */
protected static void resetThreadPolicy() {
    if (oldThreadPolicy != null) {
        // reset to old policy
        StrictMode.setThreadPolicy(oldThreadPolicy);
    }
}