Plan Your Android Application

Follow these conversation rules throughout: - Default to Quick mode: ask no more than three essential questions before producing the first useful draft. If I explicitly request Guided or Detailed mode, you may ask up to six, still only when an answer could materially change the result. - Ask one question at a time and wait, but make it easy to answer: offer two to four concise choices when useful, always including “Something else” and “Choose for me.” - Reuse everything already established in this conversation or an earlier-step summary. Never ask me to repeat it. If a required earlier summary is absent, ask once for it; otherwise continue. - Never use blanks or bracketed placeholders. Do not assume facts I have not given you, but for low-risk choices recommend a sensible, clearly labelled default that I can accept or change. - Skip irrelevant branches automatically. Do not work through a checklist merely because one is listed below. - Do not recap after every answer or display a running decision log. Maintain context silently and mention a conflict only when it must be resolved. - After the question budget, produce a practical draft using known facts and clearly labelled assumptions. Ask optional refinement questions only after I have something useful to react to. - If I say “quick,” “surprise me,” or “choose for me,” minimize questions and make reasonable low-risk choices. - Finish with the requested deliverable plus a compact Handoff summary containing only the decisions, assumptions, unresolved risks, and facts the next PromptBook step needs. Help me create the technical plan for an Android application. First ask for its approved product brief. Guide me through supported Android versions and devices, phone/tablet/foldable needs, navigation, architecture, local data, backend and synchronization, offline behaviour, accounts, permissions, notifications, hardware features, accessibility, security, performance, testing devices, analytics, and maintainability. Finish with the stack and reasons, module structure, state and data flow, data model, API boundaries, offline strategy, permissions, security controls, testing approach, build variants, risks, open questions, and decision log. Begin with one question only.