<div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">I think you're attempting to solve a non-problem, however. The<br>activity installation system will take care of not downloading (and
<br>not storing) duplicate information, based on file hashes. Making<br>three activities that all incorporate the same shared files is<br>sufficient; the OS will make sure no space is being wasted by storing<br>multiple copies. If you really want to manage things yourself, you'll
<br>need to package up all three activities as one activity whose<br>frontend is the launcher.</blockquote><div><br class="webkit-block-placeholder"></div><div>Actually, we're avoiding the launcher system in general, including the concept of "intro screens" which brach a single activity instance into a number of pseudo-independent ones. The self-contained bundle structure was chosen for a number of reasons, and despite the possibility of some shared data taking up extra space (though it seems even that may be taken care of), it makes things a lot simpler. Foremost, we explicitly want to avoid dependencies between bundles; no activity should ever require the presence of another to run.
</div><div><br class="webkit-block-placeholder"></div><div>- Eben</div></div><br>