diff --git a/frontend/apps/filemanager/filemanagermenu.lua b/frontend/apps/filemanager/filemanagermenu.lua
index 2f45d5774..aaddde7dd 100644
--- a/frontend/apps/filemanager/filemanagermenu.lua
+++ b/frontend/apps/filemanager/filemanagermenu.lua
@@ -355,7 +355,7 @@ function FileManagerMenu:setUpdateItemTable()
             end,
         })
     end
-    if not Device.should_restrict_JIT then
+    if not (Device.should_restrict_JIT or Device:isAndroid()) then
         local Blitbuffer = require("ffi/blitbuffer")
         table.insert(self.menu_items.developer_options.sub_item_table, {
             text = _("Disable C blitter"),
diff --git a/frontend/device/android/device.lua b/frontend/device/android/device.lua
index 8ae6b34ad..38531567e 100644
--- a/frontend/device/android/device.lua
+++ b/frontend/device/android/device.lua
@@ -108,19 +108,23 @@ local Device = Generic:new{
         end
     end,
 
-
-    --[[
-    Disable jit on some modules on android to make koreader on Android more stable.
-
-    The strategy here is that we only use precious mcode memory (jitting)
-    on deep loops like the several blitting methods in blitbuffer.lua and
-    the pixel-copying methods in mupdf.lua. So that a small amount of mcode
-    memory (64KB) allocated when koreader is launched in the android.lua
-    is enough for the program and it won't need to jit other parts of lua
-    code and thus won't allocate mcode memory any more which by our
-    observation will be harder and harder as we run koreader.
-    ]]--
-    should_restrict_JIT = true,
+    -- Android is very finicky, and the LuaJIT allocator has a tremendously hard time getting the system
+    -- to allocate memory for it in the very specific memory range it requires to store generated code (mcode).
+    -- Failure to do so at runtime (mcode_alloc) will *tank* performance
+    -- (much worse than if the JIT were simply disabled).
+    -- The first line of defense is left to android-luajit-launcher,
+    -- which will try to grab the full mcode region in one go right at startup.
+    -- The second line of defense is *this* flag, which disables the JIT in a few code-hungry modules,
+    -- but not necessarily performance critical ones, to hopefully limit the amount of mcode memory
+    -- required for those modules where it *really* matters (e.g., ffi/blitbuffer.lua).
+    -- This is also why we try to actually avoid entering actual loops in the Lua blitter on Android,
+    -- and instead attempt to do most of everything via the C implementation.
+    -- (FIXME:
+    -- Revert the bits of https://github.com/koreader/koreader-base/pull/1200
+    -- that made nightmode go through the Lua blitter again)
+    -- NOTE: So, on that joyous note, it's been 5 years since the last time we touched that, so,
+    --       let's try to disable it and watch the world burn ;).
+    should_restrict_JIT = false,
 }
 
 function Device:init()
diff --git a/platform/android/luajit-launcher b/platform/android/luajit-launcher
index 639158e05..ad05b6d17 160000
--- a/platform/android/luajit-launcher
+++ b/platform/android/luajit-launcher
@@ -1 +1 @@
-Subproject commit 639158e05c7cdb8af9bfbbeed87fb41dada8962a
+Subproject commit ad05b6d1769c634d04897df84cb4cd09994e831e