Skip to content

Axion SPSM v3.0.3 (RMX3430) — crash fix

Choose a tag to compare

@arena-ai-coding-agent arena-ai-coding-agent released this 12 Sep 19:02
· 117 commits to Rewrite since this release

The crash you hit is fixed, and it cannot happen again

I read the log you uploaded. It named the fault exactly, and it was mine:

java.lang.NullPointerException: Attempt to invoke virtual method
  'android.view.WindowInsetsController ...DecorView.getWindowInsetsController()'
  on a null object reference
  at com.android.internal.policy.PhoneWindow.getInsetsController(PhoneWindow.java:4136)
  at dev.axion.spsm.SpsmHomeActivity.hideSystemBars(SpsmHomeActivity.java:64)
  at dev.axion.spsm.SpsmHomeActivity.onCreate(SpsmHomeActivity.java:38)

What happened: the activity that died was the SPSM home screen — the one the mode swaps in when you press Turn on. It asked for the window's insets controller before setContentView() had created the window, and Android threw. Because it is a home activity, the system restarted it the moment it died, so the result was a crash loop and a phone with no home screen. That is the "app crashes and many more things happen" you saw. Nothing was wrong with your settings or your device.

Download: Axion-SPSM-v3.0.3-RMX3430.zip — flash over the top in KernelSU/ResukiSU, then reboot. (Also committed at release/ in this tag.)

Two fixes, because the second one is a whole class of failure

  1. The home screen can no longer be taken down by a cosmetic call. The decor view is obtained after the content view exists, the insets call is made on that view, and the whole method is guarded. Hiding a status bar is never worth the phone's home screen. Verified in the built APK's dex: it now references View.getWindowInsetsController and no longer Window.getInsetsController.

  2. The module no longer swaps the home in without checking. After launching the new home it asks the device which activity is actually resumed. If the answer is not our home, your launcher is put back within seconds and home_swap is recorded as restored, so nothing later chases a change that was already undone. If the device will not answer, the swap is left alone rather than reverted on a guess.

So this cannot leave a phone without a home again — whatever the reason: a crash, a ROM that ignores the role change, an activity disabled since.

Getting out without the app

You should never need this, but you should have it. The KernelSU/ResukiSU manager's Action button on this module toggles the mode off and puts everything back, with no app involved. To restore a home manually:

su -c 'cmd role add-role-holder android.app.role.HOME com.android.launcher3'
su -c 'cmd package set-home-activity com.android.launcher3/.Launcher'
su -c 'am start -a android.intent.action.MAIN -c android.intent.category.HOME'

A reboot also reverts an unfinished session — nothing this module changes survives a boot.

Tests

tests/run.sh: 35 cases / 153 assertions, passing, plus run-install.sh 21/21. The two new cases cover both directions: a home that never comes up gets the launcher back while the rest of the mode carries on, and a home that does come up is left alone — no false alarms.