eclipseで制作していて、上の図のようにLogCatがエラーを起こし表示できなく
なることがありました。
この解決方法はworkspaceにある
.metadata\.plugins\org.eclipse.core.runtime\.settingsフォルダ 内、
com.android.ide.eclipse.ddms.prefsをエディタで開きます。

com.android.ide.eclipse.ddms.logcat.filters=??という行があり、
「|」区切りでフィルタの設定が記述されていて、
１データは「aaaaa\:2\: aaaaa\:」のように「\:」で３つに区切られていますが、
エラーを起こす場合、「aaaaa\:\:2\: aaaaa\:」のように区切りが多い部分が
あると思います。ここを削除。
（\はバックスラッシュ）

この後、eclipseを再起動するとLogCatが正常に動作するようになります。
原因としてはフィルタリングする文字列に「:」を使用していた際に起こるようです。

参考：Logcat View fails with "Could not create the view: For input string: "our" "

はい、HomeはOpenHomeの有料版、スキンはDark Hero、7画面で4画面目がホーム。
設定のPersist ModeはONです。このモードをONにするとホームがかなり高速化されるのですが、バックグラウンドのサービスの殺される頻度が増加するという問題が発生します。
負荷テストにちょうどいいのですが、入れて動作がとまったりするアプリがあった場合には疑ってみてください。
また、先週はホームアプリはHome++ betaを試していました。機能はまだ少ないのですが上部の通知バーを下にもってくることが可能になったりと更新に期待です。

各画面ですが、左から一番目、検索バーと電源管理しかありませんがここはスクリーンショット用画面です。いきなり開発用途ですみません。

次、2番目。
自作アプリ画面。また参考にならない。。人にどんなのやってる？って話の時用ですね。
一番上の段が個人製作、下2段が会社での製作です。

次、カレンダー＋デバッグ画面。
ファイラーはASTRO、タスク管理系2個、メモリクリーナーと設定。あいてる3コマのスペースに開発中アプリを置いて使っています。カレンダーはPure Grid Calendarです。

中央、ホーム画面。ここは時計・天気予報・メモ帳・ごみカレンダー。すぐに見たいものを置いてる画面です。時計と天気はweather widgets。メモ帳はMobisle Notes Free。オクトバさんに紹介があります。メモ帳は使うのがよく変わりnote everything,RTM taskなども使っていましたがこれに落ち着いています。
ごみカレンダーは個人的なニーズからサクッと週末作ったんですが重宝しています。地味ですが。

右から3番目。自作以外のよく使うアプリ。Twitterは有料買ったTwidroidと最近出てきたTwicca。
メインはTwiDroidですが様子見ています。他はカメラ関係4個(snapphoto proはデフォルトをトイカメラ)、音楽系、ニュース系など。k-9は仕事メール専用クライアントとして設定しておき、同期は切ってあります。

右から2番目はなにもなし。pure calendar widget買ったのでここに入れる予定なのと、アプリが増えた時用にあいています。

一番右は利用頻度が低いもの。アプリ一覧がスキンのアイコンなどで溢れやすいのでたまに使いそうなものを置いています。

で、これまでに買ったアプリですが、
・Pure calendar widet
・Pure Grid calendar widget
・SnapPhoto Pro
・OpenHome - full
・twidroid PRO
・advanced task manager
・weather widget forecast
・ボンバーマン道場（ゲーム）
・Buka（ゲーム）

やはり定番が多いです。ゲーム買ってみたんですがDSをやってしまいますね。十字キーは偉大。
あと有料のスキンをいくつか試してみたいです。
定番以外のアプリを知る機会の少なさはどうしても感じてしまいます。有料アプリには人気とそうじゃないものの中間層が少ない感じ。
androlibのランキング上位はたまに入れてみていますが、週１本は有料を買うようにしていきたいと思います。
有料でいいのに、と思う無料アプリが多くてありがたいですが、やはり有料マーケットを見ていきたいので。

ロック画面を置き換えるflyscreenやaLockは試してみたのですが画面が出せないことがあったりして結局外しました。ロック画面置き換えは自分でも試していて完全に動作させるのは難しかったので、気になっていたのですが難しいようです。

1.初回にassetフォルダからアプリのdatabasesフォルダに移動
2.通常通りDBにアクセス

流れと言おうとしたら２つで終わりました。調べてる時は面倒だったのにわかってしまえばこれだけですね。
以下コード。
public void copyFile(String srcFilePath) {
File dstFile;
String dst;
dst= "/data/data/" + this.getPackageName() + "/databases/";
dstFile=new File(dst);
dstFile.mkdirs();
dst+=srcFilePath;
dstFile = new File(dst);
InputStream input = null;
AssetManager as = getResources().getAssets();
OutputStream output = null;
try {
input = as.open(srcFilePath);
output = new FileOutputStream(dstFile);
int DEFAULT_BUFFER_SIZE = 1024 * 4;
byte[] buffer = new byte[DEFAULT_BUFFER_SIZE];
int n = 0;
while (-1 != (n = input.read(buffer))) {
output.write(buffer, 0, n);
}
input.close();
output.close();
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
}

(参考：AndroidのFile入出力サンプル:throw Life様)

copyFile(DBファイル名)という形でassetフォルダのファイル名を指定し、アプリのdatabasesフォルダに移動します。
このフォルダに移動した以降は通常のSQLiteOpenHelperをextendしたクラス等から扱えますので、大量の初期データがある場合などにお使いください。

まずはドラッグされるボタン。android:clickableなどはtrueにしておきます。

dgr.setOnTouchListener(new OnTouchListener() {
	@Override
	public boolean onTouch(View v, MotionEvent event) {
		if (event.getAction() == 0) {
			//Drag開始
			draggingFlag=true;
		}
		if (event.getAction() == 1) {
			//Drag終了
			draggingFlag=false;
			backcancel();
		}
		if (event.getAction() == 2) {
			//Move
			if(draggingFlag){
				int x = (int)event.getX();
				int y = (int)event.getY();
				touchXY.set(x, y);
				movepos(touchXY);
			}
		}
		return false;
	}
});

private void movepos(Point touchXY) {
	int newX = baseX + touchXY.x;
	int newY = baseY + touchXY.y ;
	if(newX>180){
		//callfunc();
		newX=newY=0;
		draggingFlag=false;
		dgr.setPadding(0, 0, 0, 0);
	}else{
		dgr.setPadding(newX, 0, 0, 0);
	}
	dgr.invalidate();
}

あとは初期値なんかの設定。最初のほうにやっておきます。

baseX=dgr.getLeft();
baseY=dgr.getTop();

 スイッチの場合は端までスライドした時に位置を強制的に戻して、関数を呼ぶ、値設定の場合は位置移動の際に変更という実装になります。

これはバグではなくメモリ不足時にバックグラウンド処理を止めるというのはOS上の仕様ですが、Timerを止められると負荷が軽くなった後も再実行されません。スレッド等、中の処理を変えて試してみたのですが、Timerだとどうしても止まります。

そこで多少精度は落ちるだろうと考えられましたがここだけalarmmanagerで代用してみたところ重い処理が入ったときには遅れることがありますが止まることなく動作しました。ループの精度もTimerとの差はあまり感じられません。
Timerだとそのアプリ内プロセスのみで動いていたのがalarmmanager使うことで感覚的にはシステム側から要求するのでアプリ停止しても実行できているということでしょうか。
理由の詳細は突き詰められておりませんが、数日alarmmanagerでテストしておりますが停止することはないようです。

この件は引き続き調査中です。

mNM = (NotificationManager) getSystemService(NOTIFICATION_SERVICE);
notification = new Notification(R.drawable.icon, notiStr, System.currentTimeMillis());
contentIntent = PendingIntent.getActivity(this, 0, new　Intent(this,raceMap.class),
Intent.FLAG_ACTIVITY_NEW_TASK);
notification.setLatestEventInfo(this, getString(R.string.app_name),getString(R.string.nm1), contentIntent);
mNM.notify(notificationId, notification);

ここに以下の1行を追加して、上段の実行中のアプリに登録することができます。

notification.flags= Notification.FLAG_ONGOING_EVENT;