Skip to content

Home

Jump to bottom Edit New page
jca02266 edited this page Sep 14, 2010 · 30 revisions

Welcome to the k9mail wiki!

目的

K-9 mail を日本人にやさしい(というか自分にやさしい)Android用のメーラにすることを目的とする。

  • support-emoji ブランチ
    携帯の絵文字に対応するためのパッチ。現在、DoCoMoの絵文字およびデコメ絵文字に対応している。
    ただし、DoCoMoからGmail宛メールアドレスに送信した場合の挙動のみが確認されており、その他の条件については未検証。
  • hide-message_view_attachment
    デコメ絵文字対応に追加して、デコメ絵文字の添付データを添付ファイルとして表示しない。
    内部DBの項目を変更しているため、このパッチを適用したバイナリを実行したあとは他のブランチに戻す前にDBファイルを削除する必要がある。
  • support-multibyte-filename-attachment ブランチ
    日本語ファイル名が文字化けするバグを修正(この修正により他の箇所に影響がある可能性あり。まだ、十分な評価が出来ていない
    オリジナルソースのr1523で修正されたようです。(Issue 1289)
    該当のコミット: a3d619e472b40d8f96b1fd2aa18cca6f97eefc2e
  • discard-empty-draft-message
    空のメッセージをDraftに保存しないようにするパッチ。ただし、本家でも Issue 1322:Empty messages shall not be saved in Drafts in certain conditions で、私のパッチなんかよりまともな修正が行われるかも。
  • ja-l10n
    服部さんの日本語リソース。
  • enlarged-downloading-buffer-size
    添付ファイルなどメッセージのダウンロード時間が長いと言うことで、受信バッファサイズを大きくしてみた(IMAPのみ) 1024B→10240B
    エミュレータでの実行で約365.4kBの添付ファイルの受信が30秒だったのが12秒に短縮された。(気のせいかもしれない)
  • bugs
    本家に対する細かなバグ修正、仕様の変更を反映するブランチ →本家のバグ対応が早すぎるので不要なブランチであった

上記のブランチは、開発終了／中断などにより削除される場合がある。
以下は常に存在するブランチ

  • master ブランチ
    オリジナルのtrunkソースのブランチ。不定期的に最新ソースがpushされる予定。
  • build
    バイナリをビルドするためのブランチ。各種パッチをマージしたのちリリース用のバイナリはこのブランチで作成される。バイナリ公開前にこのブランチが更新されることになるため、必ずしも最新ソースとは限らない。 ビルド対象のソースはタグのみで示す

ライセンス

メモ

  • オリジナルソース 全部は大きいのでr1400からインポートしている。
  • 現在(2010-03-15)r1501までのオリジナルソースが入っている。今後のオリジナルソースのインポートについては、方針を検討する必要がある。

ルール

  • master ブランチは今のところオリジナルソースを格納し、オリジナルから適当に枝分かれしたブランチで各種パッチの開発を勧める方針とする。(git svn rebase すると、pullできなくなるから)
  • 各種パッチをマージしたブランチを別途作成し、バイナリ作成はそこで行うこととするのはどうか？(build ブランチで試している)

コミットログ

  • 英語で書くこととする(苦手だけど、 その方がcoolに見える気がするから 思わぬ問題を避けるため)。

ソースの取得(読み取り専用)

以下、このプロジェクトからソースを取得する手順

% git clone git://github.com/jca02266/k9mail.git

環境によってはProxyサーバ経由でないとソースを取得できないかもしれない。その場合は、以下のようにGitにてProxyサーバの設定をした上で、HTTPプロトコルで、clone する。

% git config --global --add http.proxy proxy-server:port
% git clone http://github.com/jca02266/k9mail.git

proxy-server:port の部分はそのサイトのプロキシサーバおよびポートを指定する。

ダウンロード時間の短縮のためにリポジトリの履歴全体ではなく、直近の履歴のみ必要な場合は、以下のように —depth オプションを利用すると良い。以下の例では直近20コミットの履歴のみを取得する例

% git clone --depth 20 http://github.com/jca02266/k9mail.git

clone した直後はカレントディレクトリに、k9mailというフォルダが作成される。

% cd k9mail/
% git branch -a
(出力例)
 * build
  remotes/origin/HEAD -> origin/build
  remotes/origin/build
  remotes/origin/discard-empty-draft-message
  remotes/origin/hide-message_view_attachment
  remotes/origin/ja-l10n
  remotes/origin/master
  remotes/origin/support-emoji
  remotes/origin/support-multibyte-filename-attachment

現在(2010/4/13)、デフォルトのブランチを build としているため、clone 直後はbuildがcheckoutされた状態となる(行頭の"*"で現在のブランチが示される。実際に、作業ディレクトリk9mailの下にはbuildブランチのファイルが展開されている)。

他のブランチに切り替えたい場合は、以下の通りブランチ名を指定してgit checkoutを実行する。

% git checkout support-emoji
(出力例)
Branch support-emoji set up to track remote branch support-emoji from origin.
Switched to a new branch 'support-emoji'
% git branch -a
(出力例)
  build
* support-emoji
  remotes/origin/HEAD -> origin/build
  remotes/origin/build
  remotes/origin/discard-empty-draft-message
  remotes/origin/hide-message_view_attachment
  remotes/origin/ja-l10n
  remotes/origin/master
  remotes/origin/support-emoji
  remotes/origin/support-multibyte-filename-attachment

ソースの修正(ローカル)

あなたが、support-emojiブランチのファイルに対して何らかの変更を行いたい場合は、前項の状態から好きなエディタを使って直接ファイルを修正すれば良い。以下、修正を行った後の状態を示す。
作業ディレクトリの状態を確認したい場合は、statusコマンドを利用する。

% git status
(出力例)
git status
# On branch support-emoji
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   src/com/fsck/k9/mail/store/LocalStore.java
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       assets/emoticons/sun2.gif
no changes added to commit (use "git add" and/or "git commit -a")

この表示により、src/com/fsck/k9/mail/store/LocalStore.java が修正されており、さらにバージョン管理されていない新しいファイルassets/emoticons/sun2.gifが追加されていることが示されている。

差分の確認

作成中…

% git diff

コミット(ローカル)

作成中…

% git add -u
% git commit -m 'nancharakanchara'
% git log

パッチ作成

作成中…

% git format-patch

コンパイル

ant でのコンパイル

以下の内容で local.properties ファイルを作成し、android-sdkのパスを書く(以下では、sdkをc:\opt に置いているものとする。パス区切りはスラッシュで書いているがもしかすると \ でも問題ない？)

sdk-location=C:/opt/android-sdk-windows
sdk.dir=C:/opt/android-sdk-windows

２つパスを書くのは後者が比較的新しめのソースで変数名が変わっているからである。本当はどちらか一方だけで問題ないが、２つ書いておけば間違いない。
この点を除けば後は、本家に記載の通りである BuildingK9 参照

% ant debug

ただし、Windowsのandroid-sdk 1.6 の場合、ツール dx.bat がバグっているのでそのままだと

[echo] Converting compiled files and external libraries into bin/classes.dex...
    [apply] error: no command specified   
    :
BUILD FAILED
C:\home\arai\custom-vendor-src\k9mail-github\build.xml:219: apply returned: 1

っとエラーになる。これを避けるには、

Issue 4217 から、修正版 dx.bat を取ってきて、android-sdk-windows\platforms\android-1.6\tools\dx.bat を置き換えるのがてっとり早い。

Eclipse でのコンパイル

コンパイルというか、プロジェクトの取込み方。最近のバージョンでは最初からEclipseに取り込めるみたい。

  1. File → Import
  2. Existing Projects into Workspace → [Next>]
  3. Select root directory: k9mailのパス → [Finish]

リポジトリの作り方

ここでは、本プロジェクトのリポジトリをどのように作ったかを示す。
これは、著者個人のための記録である。

% git svn clone -r1400 -s http://k9mail.googlecode.com/svn/k9mail/
% cd k9mail
% git svn fetch
 ... patching to support Emoji
% git branch -a
* master
  support-emoji
  remotes/2.4-MAINT
  remotes/attachments-on-sd
  remotes/issue1116
  remotes/reworking-identity
  remotes/tags/2.405
  remotes/tags/2.505
  remotes/tags/2.506
  remotes/tags/2.507
  remotes/tags/2.508
  remotes/tags/2.510
  remotes/tags/2.511
  remotes/tags/2.512
  remotes/trunk
% git remote add origin git@github.com:jca02266/k9mail.git
% git push origin master
% git push origin support-emoji

フォークの仕方

前項の「リポジトリの作り方」は無視して(!)

  1. github のアカウントを持ってなければ作成する
  2. 本ページの右上のフォークボタンを押す
  3. フォークした自分のリポジトリで開発する
  4. （もし、開発に満足したら）pull request する

4 番目は必須ではないけれど、素敵なハックはぜひpull requestで教えてください。

前項「リポジトリの作り方」と同じようにオリジナルのソースを作って自分でリポジトリを作成した場合、同じソースを起源とすることができずgit でうまくマージを扱えなくなる(gitのコミットは作成時刻、コミット時刻をsha1に含むため)。パッチのファイルを交換するだけなら別にそれでも構わないけれどgitやgithubを使う意味がなくなるし、git svn fetch は無駄に時間を使うだけである。

リリース用 apk の公開

以下を参照のこと
バイナリの作成の仕方（開発者向け）

ワークフロー

  • 現在
    
  o--o--o--o--o master (= original source)
        \
          o--o--o support-emoji
  • 将来
    本家が開発をすすめてその内容を取り込む場合→本家からmergeする
    
  o--o--o--o--o--o--o--o master (= original source)
        \               \
          o--o--o--------o support-emoji
  • 遠い将来
    マージの繰り返しは、リポジトリが汚くなるから何かの契機で rebase するかも
    そうするとこのプロジェクトを追っかけている人がいたらそちらもrebaseしないといけなくなる。
    か、dangling branch で(気づかずに)開発を続けるのかも？
    安定バージョンのバージョンアップ時などに実施するかも
    ブランチ名に本家のバージョンを含めると良いのではないか？
    
  o--o--o--o--o--o--o--o-------------------------------o master (= original source)
        \                \                              \
          o--o--o---------o dangling branch              o --- support-emoji (rebase)
  • 本家へのcontribute
    本家にパッチをマージしてもらった場合も本家は svn なので、マージしてもらったソースは同じコミットにはならないので、そこからrebaseしなおすことになるだろう
    
  o--o--o--o--o--o--o--o------------------------------o master (= original source = support-emoji)
        \                \                              \
          o--o--o---------o dangling branch              o --- new-commit (rebase)
Add a custom footer
Add a custom sidebar
Clone this wiki locally