当编辑完一条信息后，如果在没有发送的情况下退出编辑页面，那么信息会自动保存为草稿。也就是在ComposeMessageActivity的onStop()时，如果还没有发送，那么就会调用WorkingMessage.saveDraft()来把信息保存为草稿。期间也会检查一些条件，比如消息是否已被标识为放弃，或是是否为空（isWorthSaving），如果一切正常会saveDraft()并会用Toast来告知信息已保存为草稿。
草稿的保存也是针对不同的信息而不同，短信和彩信的流程有所不同。
保存短信为草稿
WorkingMessage会先取出短信内容，然后开启一个新的线程去做接下来的事，WorkingMessage.saveDraft()也会就此返回。在线程中，会先确保ThreadId的正确，如果没有正确的ThreadId，就不会保存。接着把信写进数据库，把Type标识为Draft。最后会删除这个Thread所拥有的彩信草稿，因为一个Thread中只能有一个草稿，所以如果有了新的短信草稿那么就要删除旧的彩信草稿，同理，后面保存彩信草稿的时候也会删除短信草稿的。
保存彩信为草稿
与保存短信类似，ComposeMessageActivity在onStop时调用WorkingMessage.saveDraft()；WorkingMessage.saveDraft()先会刷新收信人信息，然后会创建一个彩信的数据结构SendReq，然后启动线程做其他的事，saveDraft()也就此返回。在线程中，先是保证是一个合法的Thread，也就是threadid要正确。同时也要把这个Thread标志为有草稿，这个是由一个DraftCache在管理，它是一个HashMap，来标识哪些Thread含有Draft。如果这个Thread以前没有附件，那么就为它创建附件，也就是把SendReq写入数据库；相反，如果已有了附件，那么就更新数据库，把SendReq和Slideshow，日期更新成为当前信息的内容。最后删除掉已有短信草稿。
这里要注意的对于彩信的操作都由Frameworks中的com.google.android.mms.*包里面提供的类和工具来完成的，它里面会提供Android所支持的彩信的数据结构SendReq，把数据（Text，Medias，Files）放入SendReq的方法PduPart，PduBody，把SendReq写入数据库和从数据中读取SendReq—通过PduPersister。客户端的应用程序，只是创建SendReq，用提供的方法把数据写入SendReq中，用PduPersister来写入数据库和从数据库中提取，最后用HTTP协议把SendReq发送出去。
同时还有一个专门的类DraftCache用来管理哪些Thread含有草稿，它的内部是一个HashMap，可以标识哪些Therad含有草稿。所以，在对草稿操作的地方都会用到DraftCache，如果一个Thread含有草稿，就需要把它的ThreadId标识为有草稿；如果一个Thread的信息已发送出去，就要把它标识为不含有草稿。
传统的以文件夹方式管理信息都会有一个专门用于存放草稿的文件夹叫草稿箱。每次编辑信息，无论是发给哪个人，都可以放入这草稿箱。但是这里也可以发现，与传统的以文件夹方式不同，Android中的Mms的草稿是每个Thread一个，而且只有一个，换句话说，不可能存储太多的草稿。因为Android中的Mms是以对话Thread方式来管理信息的，而一个Thread，一次对话，只应该有一个没“说完”的话，所以这种设计也是合常理的。
