Update docs

Author: ThomasFarstrike

docs/apps/app-lifecycle.md

@@ -217,6 +217,37 @@ Activity Stack:
 
 2. **Going back:** Framework first calls `onBackPressed()`. If it returns `True`, the activity stays foreground and must call `finish()` itself when ready. If it returns `False`, the current activity receives `onPause()` → `onStop()` → `onDestroy()`, and the previous activity receives `onResume()`
 
+### Disabling Navigation Globally
+
+Apps that need full control over the back and menu buttons can disable the system-level actions globally via `InputManager`:
+
+```python
+from mpos.ui.input_manager import InputManager
+
+# Disable back-screen navigation (hardware back button, swipe-back gesture)
+InputManager.set_back_screen_disabled(True)
+
+# Disable top-menu drawer opening (hardware menu button, swipe-down gesture)
+InputManager.set_drawer_open_disabled(True)
+
+# Query current state
+if not InputManager.is_back_screen_disabled():
+    InputManager.set_back_screen_disabled(True)
+```
+
+The same functions are also available as top-level `mpos` imports:
+
+```python
+import mpos
+mpos.set_back_screen_disabled(True)
+mpos.set_drawer_open_disabled(True)
+```
+
+- `close_drawer()` still works when drawer opening is disabled — you can close an already-open drawer.
+- `finish_current_activity()` (called directly) is not gated, only `back_screen()`.
+- All paths — hardware key handlers, gesture navigation, and programmatic calls — funnel through `back_screen()` and `open_drawer()`/`toggle_drawer()`, so a single call gates every trigger.
+- When disabled, the back-screen and drawer-open actions invoke optional callbacks passed to `set_back_screen_disabled(True, cb=...)` and `set_drawer_open_disabled(True, cb=...)`. The callbacks receive no arguments. If no callback is set, the action is silently consumed.
+
 ## Starting Activities
 
 ### Basic Navigation

docs/other/release-checklist.md

@@ -21,9 +21,34 @@ git diff --stat 0.6.0 internal_filesystem/  # Check changes since last release,
 
 This will trigger the GitHub builds at https://github.com/MicroPythonOS/MicroPythonOS/actions
 
-**Download the builds**
+**Tag the commit**
 
-When finished, download and extract the builds as artifacts from the [GitHub actions](https://github.com/MicroPythonOS/MicroPythonOS/actions).
+When finished, check to make sure the tests were green.
+
+Then, tag the freshly built commit with something like:
+
+`git tag 0.17.0 64b8597713`
+
+In the example above, 0.17.0 is the CURRENT_OS_VERSION and 64b8597713 is the commit that was built.
+
+**Push the tag**
+
+Run:
+
+`git push --tags`
+
+This will trigger the github "release.yml" workflow, which will create a [draft release](https://github.com/MicroPythonOS/MicroPythonOS/releases).
+
+**Test the draft release**
+
+Make sure it's all good to go.
+
+**Publish the draft release**
+
+Edit the draft release on GitHub.
+
+- Copy-paste the list from `CHANGELOG.md` into it
+- Click "Publish"
 
 **Release to Over-The-Air update**
 
@@ -46,13 +71,6 @@ When finished, download and extract the builds as artifacts from the [GitHub act
 - Extract it to ../web/
 - Run ../upload_web.sh
 
-**Release to GitHub**
-
-- Upload the builds a [new GitHub release](https://github.com/MicroPythonOS/MicroPythonOS/releases/new)
-- Fill in the new tag (e.g. 0.6.0)
-- Copy-paste the list from `CHANGELOG.md` in it
-- Add the "What to do" section at the bottom
-
 **Bundle and publish apps**:
 
 ```