livebootmodule

livebootmodule copied to clipboard

so i've looked into the 0000bootlive file and it has some cli options but is there any documentation on what i can change to get the desired results? in particular i want the log to be colored but i think you could make a little wiki with all the cmd options in my opinion, thanks in regards.

I don't speak for the author but I will offer up this bit of wisdom. It's open source and available for you to view in it's entirety... RTFM. Thanks for attending my Ted Talk.

@dxcvvxd @SubSpaceManeuvers @0x0021

You can see all available options froö Live Boot app. You can install it from Google Play Store.

Also I will try to use KernelSU's new web config feature to users can edit these parameters. But need css, js and html skilled someone

The app from google play seems to install an additional layer of the log display, but at least it detects Magisk and installs itself systemlessly. But then why use this Magisk module? Additionally, if I remove that additional layer of the boot log, and only keep the one installed by this module, then the boot log will still use the default settings, so that does not seem to solve the problem.

For anyone who wants to change the settings, the boot log's configuration is defined by the command arguments when starting it, so you'll need to edit the 0000bootlive script (either in post-fs-data.d or service.d under /data/adb/) that is installed by this Magisk module. If you do that, the settings are defined at the end of the really long line that is between the lines starting with if and fi. It should be enough if you only edit it in the post-fs-data.d directory, and you delete the duplicate of the script in the service.d directory.

This is the default configuration:

dark logcatlevels=WEFS logcatbuffers=C logcatformat=brief logcatnocolors dmesg=0--1 lines=80 wordwrap fallbackwidth=1080 fallbackheight=2340

This is a colorful configuration with transparent background, a different time format, and more log levels enabled:

transparent logcatlevels=VDIWEFS logcatbuffers=MSC logcatformat=threadtime colors dmesg=0-99 lines=80 wordwrap

Make sure to keep the fallbackwidth and fallbackheight parameters. Probably not essential, but its probably there for a good reason. Also keep the parameters before dark or transparent, those are essential. If you have a large screen, and logs are scrolling by so fast that you cant follow how they move, you can help on that a little by increasing lines, e.g. to 120. Or you can also reduce the loglevels to be shown. Each letter is the starting letter of a log level, V and D can be left off if you like it more that way, but of course the color-show will not be as interesting then.

I think the Liveboot app had a warning for it so it does not hurt if I warn you here, that enabling the V and D events may make the boot log show so many entries that

• it may slow down the boot process a bit
• the newest log messages on screen might be in the past until it catches up

@symbuzzer It would be fine if the configuration could be edited interactively in the Magisk Manager at module installation, instead of using some HTML based solution. What do you think? There are popular module templates that allow to do a reconfiguration instead of reinstallation on a second run. The AshLooper module does this, for example.

Also, why do you install a copy of the startup script in both post-fs-data.d and service.d? Are there phones that cant start it in the former directory? I deleted the one in the service.d directory because it was not necessary, and because it was even running a second instance of the boot log, which I discovered when I applied the transparent setting.

@mpeter50 Thank you very much for your comments and ideas.

First of all, I should mention that I will release a new update that will remove the copy in service.d. I think that the copy in post-fs-data.d will work on all devices and module loading solutions. Let's see if anyone has problems after the new update.

As I said before, for the installation interface; I need help from someone who knows html, js and css. I am now sure that I cannot do it on my own because I am not using an android device right now. (I am not using an ios device either) It would be really great if you or someone else could help me with this.

@symbuzzer

Let's see if anyone has problems after the new update.

Yes, some devices, like mine, can't start the startup script in post-fs-data.d (at least in the latest 2.0.3 version). I renamed that folder back to service.d, and everything worked.

Btw, note that this issue doesn't happen if you update the module from v2.0.2 to 2.0.3, because the service.d folder doesn't get deleted by the update. Also, you should rework your uninstallation script (maybe don't use Zackptg5's MMT-Extended template in order to control things yourself) because when we hit the uninstall button in Magisk or KernelSU (certainly APatch too, but haven't tested), the service.d file doesn't get deleted in /data/adb. Default uninstallation process only deletes the module folder, so in the case of this liveboot module, it will recursively delete the /data/adb/modules/livebootmagisk folder only.

@peternmuller

Yes, some devices, like mine, can't start the startup script in post-fs-data.d (at least in the latest 2.0.3 version). I renamed that folder back to service.d, and everything worked.

Updated to v2.0.4 and re-add service.d installation again. Thanks for your feedback.

Btw, note that this issue doesn't happen if you update the module from v2.0.2 to 2.0.3, because the service.d folder doesn't get deleted by the update.

This was a conscious choice. I aimed to make sure that in case of a problem, the people who install the new version will experience the problem, not the people who update it.

Also, you should rework your uninstallation script (maybe don't use Zackptg5's MMT-Extended template in order to control things yourself) because when we hit the uninstall button in Magisk or KernelSU (certainly APatch too, but haven't tested), the service.d file doesn't get deleted in /data/adb. Default uninstallation process only deletes the module folder, so in the case of this liveboot module, it will recursively delete the /data/adb/modules/livebootmagisk folder only.

I can't test this right now because I don't have an Android device. However, if you can browse the uninstall.sh file, these two startup scripts should be deleted when removing the module.

As I said before, for the installation interface; I need help from someone who knows html, js and css. I am now sure that I cannot do it on my own because I am not using an android device right now. (I am not using an ios device either) It would be really great if you or someone else could help me with this.

Are you sure you want an HTML based interface? To me it seems a little too complicated. I think Magisk users are already familiar with module installer based configurators, where they need to select the desired option with the volume buttons. Also, how would one open the HTML interface? You mentioned KernelSU support for this (I guess the KernelSU app renders the HTML? I'm not familiar with it), but how would Magisk users make use of it?

Here is an addon for the module template you currently use, from the same developer, that adds helper functions for checking for volume key presses. The readme has a short example on its usage.

@mpeter50 I don't prefer this method. Because it only allows for adjustments on the first load. The HTML-based one is complicated, yes. But it's the only one that offers real customization.

The module installer can be just rerun to change the settings, and avoid installing again. That of course needs additional code to detect if the module was already installed, but that is checking for existence of module dir basically. Some modules have been doing this for a long time.

All this and I just want the ability to play a series of static png files on boot. Just my 2 cents but I feel like we can't see the forest for the trees with the trees being a boot screen full of errors and things they really don't even need verbose output to the console and it doesn't even resemble a Linux/Unix startup anyhow. My phone turned on while charging the other day and someone looked down and said, "oh my God what is wrong with your phone??" rather than saying "gee that looks slick". Is more customization going to compound that problem and open up a world of "issue" threads or is it going to alleviate that problem?

On Sat, Aug 31, 2024, 4:02 PM mpeter50 @.***> wrote:

The module installer can be just rerun to change the settings, and avoid installing again. That of course needs additional code to detect if the module was already installed, but that is checking for existence of module dir basically. Some modules have been doing this for a long time.

— Reply to this email directly, view it on GitHub https://github.com/symbuzzer/livebootmodule/issues/10#issuecomment-2323042357, or unsubscribe https://github.com/notifications/unsubscribe-auth/AX2TV7UGF2NT6ZBZI4PGZ3LZUIVOLAVCNFSM6AAAAABG33C43KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRTGA2DEMZVG4 . You are receiving this because you were mentioned.Message ID: @.***>

All this and I just want the ability to play a series of static png files on boot.

This module does not print a series of static png files. It reads the real logcat, and prints log messages from there. It looks somewhat nice, and doubles as a diagnostic tool for when you will eventually end up bootlooping.

and it doesn't even resemble a Linux/Unix startup anyhow

Well, Android devices are not running a standard Linux system, far from it. The init system is totally different, the logging system is totally different, and all the "service units" are totally different.

My phone turned on while charging the other day and someone looked down and said, "oh my God what is wrong with your phone??" rather than saying "gee that looks slick".

I was pretty sure that was expected. Kind of funny (or rather sad) though that they are freaking out over a fucking boot animation, that "YoUr PhOnE iS hAcKeD!!!", but then just couldnt care less about real issues concerning privacy and security regarding preinstalled consumer apps, because it happens behind their backs without them seeing anything about it, and are trained to ignore it by reflex.

Is more customization going to compound that problem and open up a world of "issue" threads or is it going to alleviate that problem?

I dont know what you expect from a bootlog boot animation. I'm genuinely interested, though. But also its not "more" customization, its just providing acces to the preexisting customization developed by Chainfire.

I cant imagine a style that is like linux dmesg, systemd bootup, or any other being "approved" by average people, they would just react the same way. The best reaction I can imagine is if you would set the Windows 10 circling dots, because they are familiar with it and may think "lol you installed windows on your phone?", but thats not a bootlog, just kind of tech related.

I like this boot animation for its relative utility. And because it uses nice colors (in colored mode). Thats it. Personally I wouldnt expect anyone complimenting a boot animation.

Oh no, I hadn't thought that it would display PNG files, that was simply my want that I haven't come across or put together myself as of yet. When/if I have a boot loop with this P8P I foresee myself sitting in front of a terminal. I personally consider this package to be purely aesthetics, the output goes by so fast and so garbled that it is unintelligible anyhow.

Those are very valid points and I would take those up with the person who wrote the description for this module, "A Magisk, KernelSU and APatch module that enables unix-style (verbose) boot animation for Android devices". My curiosity was piqued knowing the same facts you have just laid out, I expected a firehose from logcat and that's what I received so no butt hurt there. As for the lack of concern on the state of privacy, user rights and infosec; that is all so far out of this personals grasp that it couldn't even be a consideration but the point remains that it doesn't come off polished at all. It is, as I said, a firehose of verbose logs which are mostly errors (atleast on my device) that chews you up and spits you out the other side like Willy Wonka's Boat Ride.

What do I expect from the animation? Honestly, I got what I expected. What I had hoped for was Hollywood, what I would have been more supportive of would have been a bit less verbosity so that the text stream has some sort of flow and verbosity where verbosity belongs, in the critical errors and not in the mundane events surrounding the boot of a device. With that said, logcat is overwhelming even in small bites if you aren't very very specific and how can one man be very very specific for every single person who uses it, I get that. Perhaps knowing that my phone has somehow sensed that Leroy in Tulsa just farted after eating 38.62 bites of corn at exactly 1725143372 seconds since epoch is a bit too much verbosity and we can all agree on that, I would hope. Bottom line, I think if the module maybe featured a "best of" approach rather than the entire polka collection of the Czech Republic it would be a little more appealing.

On Sat, Aug 31, 2024, 4:44 PM mpeter50 @.***> wrote:

All this and I just want the ability to play a series of static png files on boot.

This module does not print a series of static png files. It reads the real logcat, and prints log messages from there. It looks somewhat nice, and doubles as a diagnostic tool for when you will eventually end up bootlooping.

and it doesn't even resemble a Linux/Unix startup anyhow

Well, Android devices are not running a standard Linux system, far from it. The init system is totally different, the logging system is totally different, and all the "service units" are totally different.

My phone turned on while charging the other day and someone looked down and said, "oh my God what is wrong with your phone??" rather than saying "gee that looks slick".

I was pretty sure that was expected. Kind of funny (or rather sad) though that they are freaking out over a fucking boot animation, that "YoUr PhOnE iS hAcKeD!!!", but then just couldnt care less about real issues concerning privacy and security regarding preinstalled consumer apps, because it happens behind their backs without them seeing anything about it, and are trained to ignore it by reflex.

Is more customization going to compound that problem and open up a world of "issue" threads or is it going to alleviate that problem?

I dont know what you expect from a bootlog boot animation. I'm genuinely interested, though. But also its not "more" customization, its just providing acces to the preexisting customization developed by Chainfire.

I cant imagine a style that is like linux dmesg, systemd bootup, or any other being "approved" by average people, they would just react the same way. The best reaction I can imagine is if you would set the Windows 10 circling dots, because they are familiar with it and may think "lol you installed windows on your phone?", but thats not a bootlog, just kind of tech related.

I like this boot animation for its relative utility. And because it uses nice colors (in colored mode). Thats it. Personally I wouldnt expect anyone complimenting a boot animation.

— Reply to this email directly, view it on GitHub https://github.com/symbuzzer/livebootmodule/issues/10#issuecomment-2323050463, or unsubscribe https://github.com/notifications/unsubscribe-auth/AX2TV7WM5EZAEMFDF5YAVWLZUI2LBAVCNFSM6AAAAABG33C43KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRTGA2TANBWGM . You are receiving this because you were mentioned.Message ID: @.***>

Honestly, for the customisation, a little tutorial on a wiki page (or even just in the README.md file) on how to customize the bootanimation with all the logcat levels available, all the buffers available etc... would be enough. An HTML interface is not worth the effort, and only KernelSU (maybe APatch too, but no one uses that) users will benefit from it. It's very simple: you go to /data/adb/service.d and edit the 000bootlive file, then reboot after saving changes.

Colored mode could also be there by default.

Those are very valid points and I would take those up with the person who wrote the description for this module, "A Magisk, KernelSU and APatch module that enables unix-style (verbose) boot animation for Android devices".

Oh, I did not notice that. I understand it now

It is, as I said, a firehose of verbose logs which are mostly errors (atleast on my device)

That is because by default liveboot is set up to only print errors and warnings to the screen, and you may have not edited the script to change that

With that said, logcat is overwhelming even in small bites if you aren't very very specific

Yeah, a lot of phone's manufacturers dont clean up the errors and warnings after themselves when releasing a prod version of their ROM, so in that case its very verbose I agree. My previous phone had the logs scrolling for a minute or two before it booted up, my current one takes only 20 seconds or so.

Some of that verbosity could be solvable with passing common filters to the liveboot binary, but unfortunately I dont think it has a feature like this, and maybe even the original developer does not have access to the source code of it anymore. It is a really old piece of software.

Honestly, for the customisation, a little tutorial on a wiki page (or even just in the README.md file) on how to customize the bootanimation with all the logcat levels available, all the buffers available etc... would be enough

While we dont have that, you may be able to find these out with using the logcat command in an android shell. Levels in --help, and for listing buffers I think it has a separate param.

It's very simple: you go to /data/adb/system.d and edit the 000bootlive file, then reboot after saving changes.

service,d, but yeah. The only complication is:

• finding the list of supported settings and its values
• finding where exactly should you edit it (because its on a single line, and only the end of it, because it has a bunch of other required params)

Honestly, for the customisation, a little tutorial on a wiki page (or even just in the README.md file) on how to customize the bootanimation with all the logcat levels available, all the buffers available etc... would be enough. An HTML interface is not worth the effort, and only KernelSU (maybe APatch too, but no one uses that) users will benefit from it. It's very simple: you go to /data/adb/system.d and edit the 000bootlive file, then reboot after saving changes.

Colored mode could also be there by default.

If you can give me the code for all the variations, I can make a separate module for each one, just like the OLED2LCD module.

@mpeter50

The only complication is:

• finding the list of supported settings and its values
• finding where exactly should you edit it (because its on a single line, and only the end of it, because it has a bunch of other required params)

Nope, it's actually easy, you just have to look at Chainfire's app source code and you'll see all settings parameters. You already have written some of them already yourself in one of the first message in this issue thread!

@symbuzzer

If you can give me the code for all the variations, I can make a separate module for each one, just like the OLED2LCD module.

Hm, I don't think this is a great idea, provided there are so many settings combination possible, and some people will not know the difference between those anyway. Again, best solution imo is to add a customization tutorial section in the README file!

Anyways, here they are:

• Background colors: (no character, it's the default Liveboot app's gray-ish background color), dark, transparent
• Logcat levels: V (Verbose), D (Debug), I (Info), W (Warning), E (Error), F (Fatal), S (Silent)
• Logcat buffers: M (Main), S (System), R (Radio), E (Events), C (Crash)
• Logcat formats: brief, process, tag, thread, time, threadtime
• Logcat colors: colors, logcatnocolors
• Dmesg: 0--1 (dmesg off), 0-99 (dmesg on)
• Lines: any value you want
• Wordwrap: wordwrap, (no character)
• Save log: save (saves log in /data/cache, just like in the app), (no character)
• Fallback width and fallback height: usually your device's screen resolution, but you can put other values to spoof another screen size

Nope, it's actually easy, you just have to look at Chainfire's app source code and

Yeah, easy for us, but the reason I worded it that way is that I think it is not for most thinking of using this module. Thanks for the detailed comment, though!

@mpeter50 Thank you very much for your comments and ideas.

First of all, I should mention that I will release a new update that will remove the copy in service.d. I think that the copy in post-fs-data.d will work on all devices and module loading solutions. Let's see if anyone has problems after the new update.

As I said before, for the installation interface; I need help from someone who knows html, js and css. I am now sure that I cannot do it on my own because I am not using an android device right now. (I am not using an ios device either) It would be really great if you or someone else could help me with this.

That to debug would be painful, cuz you have to restart the device to test the changes.. I could try it with ModConf (MMRL), doesn't require CSS

I would rather store the liveboot argument in a separate file and the service access the file.

I built an prototype: https://gist.github.com/DerGoogler/c24015d1a310809ab882a7d7f23ddd62

It saves the arguments to a separate file.

@DerGoogler Isn't it possible to get the fallbackwidth and fallbackheight values ​​of the device with this code? Or at least run the shell command and use its output?

@symbuzzer with window.screen.height and window.screen.width, but window.screen is not in ModConf implanted and would give a false value.

That may need to implanted natively

@DerGoogler install.sh script get these values at first installation. Anyway to implement your code for editing 0000bootlive file both system.d and post-fs-data.d folders? Not re-creating only editing exists 0000bootlive files

@DerGoogler install.sh script get these values at first installation. Anyway to implement your code for editing 0000bootlive file both system.d and post-fs-data.d folders? Not re-creating only editing exists 0000bootlive files

That could be possible. But then I rather implant a additional confirm button to save that.

@DerGoogler Can u send PR please?

@symbuzzer here the pr: https://github.com/symbuzzer/livebootmodule/pull/15

@DerGoogler Is your code only works on specific app?

Unfortunately it only works on MMRL

@DerGoogler So will there be any problems if the module is installed normally or if this application is not used?

There won't be any problems. No other app can ise that config.

Is literally the same as WebUI, but for WebUI you have to built everything yourself.