Related
I tried to word the title correctly to establish that I want to ask 2 different questions, but dont want to clutter up the board with 2 separate posts
Please help if you can
1. Kernel
Why do some kernels work with some roms and not others? I have taken a Sprint Rom, ran it through the kitchen, and tried flashing any number of kernels. The only one that works is Zenulators AnyKernel. I know at times only the stock overclocked worked, but I think at certain times I have gotten the no perf lock to work (though that may have been with an NFX Rom, and not one that I created myself). This leads me to ask why would a kernel work for a rom that is built from the same base that I am using, but not on mine? Is dsixda's kitchen not the one everyone uses? I just dont understand why I am limited to one kernel that is not undervolted and overclocked. I would like to put a 768 overclocked, undervolted kernel with this rom, but cant get any to flash. Should I just use the kitchen to "port" the kernel. How does nfinitefx45 get the kernels he posts to work with a Sprint base? Is the kernel edited in some way? Im not calling anyone out, just trying to learn how to get a good kernel to work with my rom.
2. MAJOR issue: when running df, I get an error that etc/mtab: no such file or directory. What I have done is in the paragraph below
I decided to take another cracked at a minimal Sprint 2.1 Rom. I used dsixda kitchen 0.107 to root, add busybox, remove boot sounds, deodex, add data/app, add nano + sysrw, sysro, bash, and zipalign the .7 Rom. I then removed all Sprint apps except for VVM, all google apps, all htc apps and widgets that were not explicity needed (need the contacts and ime apks among a few others), removed a ton of system apps (can provide a list of current system/app dir and a list of all that was removed if it will help). I edited the lockscreen so it wasnt in landscape mode all the time. Added an OMADM.apk file that didnt FC when I tried to update the prl (tested the update and it works). I did find an EPST.apk that adds ## codes back to the dialer (should I include that in the rom...wasnt intending on it as the only ## code that doesnt work is the prl...data works) OMADM.apk is smaller that the EPST...but EPST does exist already...and I might be able to pull OMADM meaning 0 firmware, profile, or prl updates...but you could do ##prl manual...I dont know, still thinking it through. I did end up creating a google apps zip file with the apps from the .7 rom so that market will work (removed maps as it wasnt up to date and the Streets.apk never worked, but left gmail, youtube, voice search to work with jonasl's htc keyboard, and of course gtalk). In doing this, I am thinking about creating some packs for the rom, but really need the above 2 questions answered to find out where to go from here.
evilvoice said:
1. Why do some kernels work with some roms and not others?
2. MAJOR issue: when running df, I get an error that etc/mtab: no such file or directory. What I have done is in the paragraph below
Click to expand...
Click to collapse
afaict, the 'kernels' are literally just the linux kernel that provides some basics to the os... altho linux IS a monolithic kernel, it is not a bsd-system that has all the tools completely-compiled for the system together...
thus, the answer to 2. is that you have deleted too much of the periphery, for instance the actual mount-table system that df uses to to check... (ie: some prog creates the mtab, and apparently it is not the kernel, i guess)
alternatively, the answer to 1. is that there is actually too much in the roms that are using something unique to each kernel that you are trying to install (altho that seems odd to me)... thus, the only way that the rom will work is if you give it the kernel with the tools that it (the rom) needs...
tbh - im not exactly sure - ive not gone into the depths of kernel-swapping that youre trying to explore... in full-linux-systems, the kernel is fairly easy to update without breaking all of the miscellaneous tools - however apparently the android-roms are more tied-together than a normal linux system...
gl and maybe someone with more experience will give an accurate (rather than a guessing) answer...
I like to tweak my ROMs before a flash. i.e. make changes to /system apps; framwork tweaks... etc.
However, whenever I try to replace a kernel zImage or modem binary(using 7z, so as not open archive), I get stuck at a bootloop.
I can replace .apks and .pngs no problem using this method.
Can zImage and .bin be replaced as well? Does redbend also need to be copied? Since .bin and zImage reside in same folder in ROM... which redbend to use if needed?
Thank you?
Whenever I use a new kernel in Loki, or test one personally, I use the version of redbend that the dev included with their kernel initially. Modem does not seem to matter. Are you using a kernel that is meant for the version of Android that matches your rom? If you want to, specifically, what are you using?
This is interesting to me as well, as I did not know you could flash a zip that had been added to, so can you briefly explain how this is done? I would much rather inject my apps than do the titanium backup dance.
I also noticed that SGS Kernel flasher flashes the zImage by simply copying it, and rebooting.
If you are about to tell me I can manipulate my FS to add anything i want, in an update.zip, then sir, I love you.
BTW, if its a simple explanation, whats the redbend file do?
Br1cK'd said:
Whenever I use a new kernel in Loki, or test one personally, I use the version of redbend that the dev included with their kernel initially. Modem does not seem to matter. Are you using a kernel that is meant for the version of Android that matches your rom? If you want to, specifically, what are you using?
Click to expand...
Click to collapse
Exactly what Br1cK'd said. Use the redband that's with the kernel. If pulling the kernel from a rom and a modem from a different one same deal. Also be careful which kernels you use ie: right kernel for phone and version of Android.
d33dvb said:
This is interesting to me as well, as I did not know you could flash a zip that had been added to, so can you briefly explain how this is done? I would much rather inject my apps than do the titanium backup dance.
I also noticed that SGS Kernel flasher flashes the zImage by simply copying it, and rebooting.
If you are about to tell me I can manipulate my FS to add anything i want, in an update.zip, then sir, I love you.
BTW, if its a simple explanation, whats the redbend file do?
Click to expand...
Click to collapse
No sir it is not quite that simple. Proper settings have to be in the update script for everything to install properly. Replacing one file for another of the same name usually works and some files can be added but system apps and additional folders need to be in the update script.
Br1cK'd said:
Whenever I use a new kernel in Loki, or test one personally, I use the version of redbend that the dev included with their kernel initially. Modem does not seem to matter. Are you using a kernel that is meant for the version of Android that matches your rom? If you want to, specifically, what are you using?
Click to expand...
Click to collapse
Br!ck'd, fan of your work and EDT as a whole... great dev team! It happens on any kernel/ROM combo I have tried, which is interesting. Update.zips just carry signed certs and simple copy bash scripts, essentially pushing new files to correct directories, correct? I definitely check for kernel compatability before, I am noobish, not noobtacular
d33dvb said:
This is interesting to me as well, as I did not know you could flash a zip that had been added to, so can you briefly explain how this is done? I would much rather inject my apps than do the titanium backup dance.
I also noticed that SGS Kernel flasher flashes the zImage by simply copying it, and rebooting.
If you are about to tell me I can manipulate my FS to add anything i want, in an update.zip, then sir, I love you.
BTW, if its a simple explanation, whats the redbend file do?
Click to expand...
Click to collapse
1. I believe redbend is samsung tool for flashing volatile memory (NAND).
2. You can use 7zip to explore archives/apks without extracting them and breaking signings. Thus you can simple copy paste .apks/.pngs to appropriate directories without extracting
Most update zips are the actually apk and simple scripts in a flashable container. Roman form EDT has an excellent tool for creating flashable zips if interested... but yes you can manipulate file system of phone and archives. I use adb from recovery. Or android commander is a useful tool as well
EDIT: Explodingboy gives better explanation above
I use untermench's modified redbend. It's the same thing except it removes that ugly blue splash screen every time it is run. That said, I've simply copied over OS and CW into the trigger zips to override the stock kernel. And I never received any reports if it not working from anyone (and I've had releases with both).
Point being, in my experience it doesn't really matter (so long as everything matches). I've done the same for previous modems.
And as you said, all it's doing is copying them to the proper partitions.
Sent from my SGH-T959 using Tapatalk
birgertime said:
I use untermench's modified redbend. It's the same thing except it removes that ugly blue splash screen every time it is run. That said, I've simply copied over OS and CW into the trigger zips to override the stock kernel. And I never received any reports if it not working from anyone (and I've had releases with both).
Point being, in my experience it doesn't really matter (so long as everything matches). I've done the same for previous modems.
And as you said, all it's doing is copying them to the proper partitions.
Sent from my SGH-T959 using Tapatalk
Click to expand...
Click to collapse
Very cool... thanks.
Also, you are going to think I am crazy... but that ugly blue splash screen can tell me if it is a bad flash or not. When it happens on the top of screen= good flash, on bottom = gonna need to flash again, cause behavior goes wonky. Maybe just bizarre coincidence???
Poser said:
Br!ck'd, fan of your work and EDT as a whole... great dev team! It happens on any kernel/ROM combo I have tried, which is interesting. Update.zips just carry signed certs and simple copy bash scripts, essentially pushing new files to correct directories, correct? I definitely check for kernel compatability before, I am noobish, not noobtacular
Click to expand...
Click to collapse
I've seen you around, you're not noobtacular, but hell I'm still way noobish about a lot of things. Dig the avatar btw. I don't know if I can give an intelligent enough answer to your question, would probably have nobody running Loki by tomorrow, lol. Have you grabbed any logs, or tried to, while its looping?
I have no issues doing this with winrar.
Sent from my Amazing Captivate using the XDA Premium App Infused with Tiger Blood
Br1cK'd said:
I've seen you around, you're not noobtacular, but hell I'm still way noobish about a lot of things. Dig the avatar btw. I don't know if I can give an intelligent enough answer to your question, would probably have nobody running Loki by tomorrow, lol. Have you grabbed any logs, or tried to, while its looping?
Click to expand...
Click to collapse
<Palm to forehead> Probably should logcat... duh.
Just flashed with with custom kernel/modem combo... seems to be booting fine, will report any anomalies.
Only thing I did different was copy zImage and redbend from Kernel.zip
Thanks peoples!
This thread is for FlashCast image developers ONLY. If you are not developing a FlashCast image, please do not post here. Post in the main thread instead.
Hello developers! I hope that this thread can serve as a place for you to ask any questions you may have about FlashCast development or internals, make feature requests, and report issues you're having. I will edit this post with FAQs as they come up. Until then, take a look at my documentation on GitHub, which contains documentation and sample code to help you create FlashCast mods.
tchebb said:
This thread is for FlashCast image developers ONLY. If you are not developing a FlashCast image, please do not post here. Post in the main thread instead.
Hello developers! I hope that this thread can serve as a place for you to ask any questions you may have about FlashCast development or internals, make feature requests, and report issues you're having. I will edit this post with FAQs as they come up. Until then, take a look at my flashcast-samples repository on GitHub, which contains documentation and sample code to help you create FlashCast mods.
Click to expand...
Click to collapse
So far its working great! Plan on releasing a rooted 13300 system image with this soon, but I was wondering, is there a possibility you could create a partition backup option? so like
Code:
backup_mtd_partition 'rootfs' 'system.img'
Where it will make a folder called backup on the jump drive, and store the rootfs file system with the name of system.img? also a md5 for each file would be nice. I know I could just have a script dd the mount point, but would be nice to see a function to call.
ddggttff3 said:
So far its working great! Plan on releasing a rooted 13300 system image with this soon, but I was wondering, is there a possibility you could create a partition backup option? so like
Code:
backup_mtd_partition 'rootfs' 'system.img'
Where it will make a folder called backup on the SD card, and store the rootfs file system with the name of system.img? also a md5 for each file would be nice. I know I could just have a script dd the mount point, but would be nice to see a function to call.
Click to expand...
Click to collapse
This would definitely be a useful feature. I can see a few implementation details that would need to be worked out in a non-obvious fashion, though:
There is currently no way for a imager script to directly access the root of the user partition. This is intended to prevent multiple scripts from having access to the same filesystem and possibly overwriting each others' files. Instead, scripts are executed in a temporary directory whose contents are discarded on device shutdown. It seems like the solution to this would be to create numbered backup directories, like there are numbered logs now, for mods to place their backups in.
It wouldn't be desirable for a mod to take a backup every time it was flashed, as not everyone cares about backups and they take up lots of space. There would need to be some way for the user to decide whether or not they wanted backups. Maybe another flag file?
Finally, taking a backup of an MTD partition using nanddump (dd should not be used to image NAND partitions, since it is not bad-block aware) images the entire partition, when (in the case of squashfs) only a small part actually has a filesystem on it. This means that a single rootfs backup will take up 400MB on the USB drive. I would want to implement something which can back up only the part of a partition which squashfs is using before I release backup functionality.
Obviously, this is a prime candidate for a new helper function, because of these non-trivial complications. I'll see if I can make the necessary changes to FlashCast and release backup functionality as part of v1.1. Thanks for the suggestion!
One more suggestion, if you do not mind.
How about the ability to flash multiple zips at once? So, if I have 2 files I want to flash, first one will stay eureka_image.zip, and then the next one would be eureka_image1.zip, or some similar process to allow multiple zips.
The issue here would be a naming scheme that would be easy for users to use and understand. so maybe if you flash a single file, just use eureka_image.zip, and if multiple, each would have a number added, starting from 1 and counting up in the order you want them flashed?
ddggttff3 said:
One more suggestion, if you do not mind.
How about the ability to flash multiple zips at once? So, if I have 2 files I want to flash, first one will stay eureka_image.zip, and then the next one would be eureka_image1.zip, or some similar process to allow multiple zips.
The issue here would be a naming scheme that would be easy for users to use and understand. so maybe if you flash a single file, just use eureka_image.zip, and if multiple, each would have a number added, starting from 1 and counting up in the order you want them flashed?
Click to expand...
Click to collapse
This is something I intend to implement. My current plan is to support a eureka_images directory, which can contain any combination of zipped and unzipped mods which will be flashed in alphabetical order. Mod authors can distribute their mods with a prefixed number, so, for example, you could distribute 00_13300_rooted.zip and 59_unlocator_dns.zip. I'll write a standard for how to determine the numbers (e.g. full system images get 00-09, major/minor filesystem changes get 40-49/50-59 respectively depending on how many files they affect, etc). It's not perfect and there can still be conflicts, but it should allow most mods to be flashed in a mostly sane order. I'm open to any suggestions or improvements you might have.
tchebb said:
This is something I intend to implement. My current plan is to support a eureka_images directory, which can contain any combination of zipped and unzipped mods which will be flashed in alphabetical order. Mod authors can distribute their mods with a prefixed number, so, for example, you could distribute 00_13300_rooted.zip and 59_unlocator_dns.zip. I'll write a standard for how to determine the numbers (e.g. full system images get 00-09, major/minor filesystem changes get 40-49/50-59 respectively depending on how many files they affect, etc). It's not perfect and there can still be conflicts, but it should allow most mods to be flashed in a mostly sane order. I'm open to any suggestions or improvements you might have.
Click to expand...
Click to collapse
Sounds great to me! Only other suggestion I have is to add another flag file which would allow Flashcast to continue flashing the multiple zips, even if one errors out.
So, by default if multiple zips are going to be flashed, and it errors on the first, it would stop, get a red LED, and then reboot.
with a flag file present, maybe ignore_errors, even if it errors out on the first zip, it would continue down the chain of zips until it finishes all of them.
Anyone got any idea how to get started with some themes for the chromecast? Will be more than happy to help, as soon i know where to start.
bormeth said:
Anyone got any idea how to get started with some themes for the chromecast? Will be more than happy to help, as soon i know where to start.
Click to expand...
Click to collapse
Most of the resources seem to be kept in the .pak files contained in /chrome. The first step to theming would be figuring out what format those are in and how to unpack and repack them. You might want to start by taking a look at the content_shell source code, as it might have some documentation or scripts for working with .pak files.
tchebb said:
Most of the resources seem to be kept in the .pak files contained in /chrome. The first step to theming would be figuring out what format those are in and how to unpack and repack them. You might want to start by taking a look at the content_shell source code, as it might have some documentation or scripts for working with .pak files.
Click to expand...
Click to collapse
Im gonna dive into it
Have a little bug report.
If a person has more then 85~MB in their eureka_image folder, and then they start a SquashFS File system edit, flashcast will report an error saying out of space. Now, here is the error part. Even though it failed to mount with an error, the imager.sh file will continue to run, and will then attempt to flash back a corrupt file, causing a non-bootable chromecast until the system partition is re-flashed.
bormeth said:
Anyone got any idea how to get started with some themes for the chromecast? Will be more than happy to help, as soon i know where to start.
Click to expand...
Click to collapse
The first script on THIS SITE will unpack the .PAK files, although it unpacks everything as a .png as it was made for a different Chromium device. So you would have to manually go rename all the files to their correct extension for the files, but because it expects everything to be a .png it won't pack back properly. The second script, technically should unpack/pack as proper file extensions, but I never got it to work right as I have little to no knowledge of Python.
The chromium source has a script,data_pack.py (which I can't link to since I'm a new user ATM) which can be used to pack and unpack .PAK files. The script posted above seems to be lifted from this source and modified to detect a few filetypes and write the unpacked files. But if you want to modify or add images and need to repack them, this script will help you figure it out. I'll work on adding and making some changes to the theme and give some instructions.
how to mount usb drive
Haven't used linux in years. Thanks!
Hey, want to do some poking around in the flashcast .bin file...how do I go about doing that? What is the file format, and is the image mountable in linux? Even better might be to extract files/folders from the image...what tool can I use to do that?
Ok, so I'm doing some dinking around...I've looked into buildroot, and I think for the most part I understand what is going on. I also tried building from source, and it appears to have worked. So, from this poking around I have a few assumptions I've made and a few questions. Correct me if I'm wrong anywhere but.......
Basically, you've built a generic bootloader for the device using buildroot. This is not related at all to the stock CC bootloader (although maybe you borrowed a few drivers, etc). I would guess that the buildroot bootloader has just what you need to display a picture on the TV and do some basic file system operations, and I would also guess that the buildroot bootloader is missing a few features that the stock bootloader has - therefore, it wouldn't be possible to run a full-fledged ROM off of this bootloader. Am I right so far? If so, what is missing from the buildroot bootloader? Libraries? Binaries? No idea?
Also, to access something like USB storage, the buildroot bootloader is able to include the required /dev devices, whereas it wouldn't be possible to include this on CC's stock bootloader without the source. So, doing something like accessing a ROM from an external flash drive isn't feasible because of these limitations? Basically, all that is possible with the current bootloader (of course, the insecure one which allows for unsigned code to run) is to add a few binaries to the stock CC ROM (things like adb, dropbear, etc), maybe add some access to those binaries through Web GUI, etc.
Am I on the right track? Is there anything you would add/correct? Thanks for the help. I'm trying to understand
tomg09 said:
Ok, so I'm doing some dinking around...I've looked into buildroot, and I think for the most part I understand what is going on. I also tried building from source, and it appears to have worked. So, from this poking around I have a few assumptions I've made and a few questions. Correct me if I'm wrong anywhere but.......
Basically, you've built a generic bootloader for the device using buildroot. This is not related at all to the stock CC bootloader (although maybe you borrowed a few drivers, etc). I would guess that the buildroot bootloader has just what you need to display a picture on the TV and do some basic file system operations, and I would also guess that the buildroot bootloader is missing a few features that the stock bootloader has - therefore, it wouldn't be possible to run a full-fledged ROM off of this bootloader. Am I right so far? If so, what is missing from the buildroot bootloader? Libraries? Binaries? No idea?
Also, to access something like USB storage, the buildroot bootloader is able to include the required /dev devices, whereas it wouldn't be possible to include this on CC's stock bootloader without the source. So, doing something like accessing a ROM from an external flash drive isn't feasible because of these limitations? Basically, all that is possible with the current bootloader (of course, the insecure one which allows for unsigned code to run) is to add a few binaries to the stock CC ROM (things like adb, dropbear, etc), maybe add some access to those binaries through Web GUI, etc.
Am I on the right track? Is there anything you would add/correct? Thanks for the help. I'm trying to understand
Click to expand...
Click to collapse
Buildroot does not let us build a bootloader, it lets us build a custom linux distribution that runs on the chromecast. The reason it is unable to do anything "graphical" minus the static image is due to licensing of the marvell GPU driver the chromecast uses. It is currently closed source, so it is unable to be compiled. We can use the blob from the stock OS, but ATM there is no need, and this can cause licensing issues.
Also, you can still access /dev and such on the stock OS. The big thing is the stock OS has usb input disabled at a kernel level, so it doesn't mount or detect any devices plugged in when the OS is running. This is circumvented though if you build and use your own custom kernel. For the features Eureka-ROM adds to the stock OS, we add those by using googles open source cross compiler for the device to build supported binaries.
Hmm...interesting. So, if I understand the booting process properly, upon power-on, a small bit of code called the bootloader is run, loading the kernel into memory (where, among other things, the graphics driver is located). From there, other components of the operating system are loaded on "top" of the kernel. So, it's not the bootloader that's rebuilt - but the kernel - with buildroot. Now, what sort of things would be possible if an open source alternative for the graphics driver were available (bear with me in the hypothetical), or even if one were to take the blob from the stock CC kernel? Turn CC into an android stick, complete with USB input device compatibility maybe?
Now on another note. I want to learn about cross-compiling. I am thinking of trying my hand at cross-compiling samba for the chromecast. Now if I understand the buildroot compiling process correctly, the right compiler for making chromecast-runnable binaries is compiled (or do you include it externally), and in theory, it should be possible to compile samba, right? I've been poking around the buildroot directory tree with the chromecast source superimposed over the top, and as of yet, I havent found the compiling binary (gcc, maybe?). I will look in a bit more depth. Once I find this, it should be as simple as specifying host and target architecture, putting the compiler for the CC in PATH, and compiling, right?
Thanks again for your help, and if you feel this isn't the appropriate place to post this, let me know.
tomg09 said:
Hmm...interesting. So, if I understand the booting process properly, upon power-on, a small bit of code called the bootloader is run, loading the kernel into memory (where, among other things, the graphics driver is located). From there, other components of the operating system are loaded on "top" of the kernel. So, it's not the bootloader that's rebuilt - but the kernel - with buildroot. Now, what sort of things would be possible if an open source alternative for the graphics driver were available (bear with me in the hypothetical), or even if one were to take the blob from the stock CC kernel? Turn CC into an android stick, complete with USB input device compatibility maybe?
Now on another note. I want to learn about cross-compiling. I am thinking of trying my hand at cross-compiling samba for the chromecast. Now if I understand the buildroot compiling process correctly, the right compiler for making chromecast-runnable binaries is compiled (or do you include it externally), and in theory, it should be possible to compile samba, right? I've been poking around the buildroot directory tree with the chromecast source superimposed over the top, and as of yet, I haven't found the compiling binary (gcc, maybe?). I will look in a bit more depth. Once I find this, it should be as simple as specifying host and target architecture, putting the compiler for the CC in PATH, and compiling, right?
Thanks again for your help, and if you feel this isn't the appropriate place to post this, let me know.
Click to expand...
Click to collapse
If we had a fully working open source graphics driver, lots could be accomplished. Full custom linux distributions could run x11 shells, we could have xbmc working with hardware decoding, and yes android would technically be possible if enough people wanted to put the time and effort into it. You can take the blob from the rom to do some of this, but things like hardware accelerated decoding will still not be possible due to the fact there is no documentation on how to use the blobs properly for things like that. (this is my understanding so I may be off on some small details, @tchebb can probably explain it more in depth.)
As for cross compiling, you just need to use googles prebuilt toolchain as the compile source.
Link: https://code.google.com/p/chromecast-mirrored-source/source/browse?repo=prebuilt
Mind if I ask why you want to compile samba? do you want to host media or files from a chromecast device? I actually have CIFS added to the eureka-kernel configs on our repo, so if you compile our kernel from source, you can mount samba shares on the chromecast device using the CLI.
ddggttff3 said:
As for cross compiling, you just need to use googles prebuilt toolchain as the compile source.
Link: https://code.google.com/p/chromecast-mirrored-source/source/browse?repo=prebuilt
Mind if I ask why you want to compile samba? do you want to host media or files from a chromecast device? I actually have CIFS added to the eureka-kernel configs on our repo, so if you compile our kernel from source, you can mount samba shares on the chromecast device using the CLI.
Click to expand...
Click to collapse
Cool. Thanks for the link. Basically, I'm just looking to learn about cross compiling for mobile devices. I figure samba seems easy enough. It was the first thing that came to mind. Any other ideas for something to cut my teeth on? Other binaries that would be well suited to CC, but are easy to compile?
tomg09 said:
Cool. Thanks for the link. Basically, I'm just looking to learn about cross compiling for mobile devices. I figure samba seems easy enough. It was the first thing that came to mind. Any other ideas for something to cut my teeth on? Other binaries that would be well suited to CC, but are easy to compile?
Click to expand...
Click to collapse
One more question...I've looked through the toolchain...the way it's set up is somewhat confusing. In the root directory of the toolchain: bin=gcc, g++, everything else I need to compile. What are the two folders entitled "arm-unknown-linux-gnueabi" and "target-arm-unknown-linux-gnueabi"? They seem to have relevant stuff (one has gcc, g++, etc except without the arm-unk... prefix, and other binaries which seem important). How do I use these/should I use these/why are they kept separate?
Thanks for the help.
>>> DELETED <<<
Also would like to know since xposed takes forever to reach the latest version of android.
Because Xposed is an API-based framework, allowing you to surgically go into Android to hook and modify the behavior of the specific methods you want.
Magisk is a mask, allowing you to make changes to your runtime system, but not at surgical, method-specific level. It can change props, make system-level replacement, etc., but if you want to change something, you need to replace the entire package that the something comes with.
Magisk is just a way to change system files without actually writing to the system partition while xposed is framework in the art runtime letting you hook into applications natively without have to completely replace the package just to use mods. They aren't the same thing at all as magisk thosent let you do anything you couldn't already do by writing to system. Things like changing volume steps are impossible with magisk but a few calls with xposed. Redirecting state based app requests is also impossible without xposed
Thread closed at the OP's request and unhelpful comments removed. Please folks, if being unhelpful and joking around at the OP's expense is your only intention for posting here, just stop and don't bother posting at all. No one's got time for your spam.
In the past couple years, magisk has come a long ways to the point that it's the de-facto root solution. I have been developing and maintaining the Unity template for the past couple years but it's now reached a point where there's no longer a need for it - it's simply not worth the effort anymore. There are very few use cases where someone would want to stay rootless and still install a bunch of mods and every other root solution is pretty much deprecated at this point. So I switched gears from Unity to a magisk only template.
Consider this the spiritual successor of the Unity Template
So what is Magisk Module Template Extended (MMT-Ex)?
MMT-Ex is just as the name describes - it's the magisk module template but with the best features of Unity added to it
What does this mean?
This means that MMT-Ex is an easy way to make a magisk module regardless of how basic or advanced it is.
Where do I start?
Follow the readme on the main repo here and you'll be setup in no time
Questions?
Post them here, I'll try to help out when I have the chance but hopefully you won't have any
So much for the smooth release. Small bug fix pushed
@Zackptg5 I write here since there's no issue section in the repo, but there are two uninstall.sh files, one in common and the other one in the main directory, I think that's a bit confusing.
My ideas would be:
-merge the two files;
- rename the one in common in remove.sh , MMT-exuninstall.sh or similar names
MarcAnt01 said:
@Zackptg5 I write here since there's no issue section in the repo, but there are two uninstall.sh files, one in common and the other one in the main directory, I think that's a bit confusing.
My ideas would be:
-merge the two files;
- rename the one in common in remove.sh , MMT-exuninstall.sh or similar names
Click to expand...
Click to collapse
I could do a better drop explaining things in the wiki
The one in root gets copied as is to modpath and will uninstall any files outside modpath if removed via magisk manager
The one in common is like the old unity_uninstall one. The only reason I had the common ones named unity_whatever back in the day is because one of the past magisk module templates unzipped everything with the -j option (ignores directories) and so files would overwrite each other if they had the same name
I disabled issues on most of my repos because noobs would post stupid stuff on it so I redirected all support to here instead
Zackptg5 said:
I could do a better drop explaining things in the wiki
The one in root gets copied as is to modpath and will uninstall any files outside modpath if removed via magisk manager
The one in common is like the old unity_uninstall one. The only reason I had the common ones named unity_whatever back in the day is because one of the past magisk module templates unzipped everything with the -j option (ignores directories) and so files would overwrite each other if they had the same name
I disabled issues on most of my repos because noobs would post stupid stuff on it so I redirected all support to here instead
Click to expand...
Click to collapse
So far so good here.
@Zackptg5 it appears system.prop and sepolicy.rule still need to be placed in the root of the mod, and not in common in order to propagate on-device.
Which is fine, as i know thats how to fix it. But wasnt sure if that was your intent, it sounds like you want everything running script-wise out of common (which makes sense). Attached my magisk log, and my mod has a new sepolicy.rule and system.prop. I tried this the way i maentioned above and every loads as it should.
Hello, if I develop a Module with your template, I will be able to install it on my device. But I don't think it will be accepted as a valid module submission here (https://github.com/Magisk-Modules-Repo/submission/issues) because it does not respect the new module format.
Can you confirm?
aer0zer0 said:
@Zackptg5 it appears system.prop and sepolicy.rule still need to be placed in the root of the mod, and not in common in order to propagate on-device.
Which is fine, as i know thats how to fix it. But wasnt sure if that was your intent, it sounds like you want everything running script-wise out of common (which makes sense). Attached my magisk log, and my mod has a new sepolicy.rule and system.prop. I tried this the way i maentioned above and every loads as it should.
Click to expand...
Click to collapse
Common folder scripts should copy over but I've seen this issue in another module. I'll look into it later this week when I'm off work
lapwat said:
Hello, if I develop a Module with your template, I will be able to install it on my device. But I don't think it will be accepted as a valid module submission here (https://github.com/Magisk-Modules-Repo/submission/issues) because it does not respect the new module format.
Can you confirm?
Click to expand...
Click to collapse
mmtex is the new template with some modifications so you shouldn't have any problems there
DELETED
lapwat said:
I don't understand because on the Developer Guides there isn't any common folder anymore: https://topjohnwu.github.io/Magisk/guides.html
Click to expand...
Click to collapse
That's on of the modifications I made although there appears to be a bug with it that I'll need to work out
Zackptg5 said:
That's on of the modifications I made although there appears to be a bug with it that I'll need to work out
Click to expand...
Click to collapse
If I was to guess it would be something in lines 208-214 of the functions.sh. but I'm way to stoned to be of any actual assistance.
Edit: Clearly too stoned. I meant to reply to the system.prop not being applied when in common not what I actually replied to lol
Found the problem real quick. Seems I mixed up Unity with MMT-Ex logic:
The main boot scripts and such (service.sh, post-fs-data.sh, sepolicy.rule, and system.prop) should all be in root of installer like with regular template. Any extras can go into common. I'll push an update to the wiki on that shortly
Zackptg5 said:
Found the problem real quick. Seems I mixed up Unity with MMT-Ex logic:
The main boot scripts and such (service.sh, post-fs-data.sh, sepolicy.rule, and system.prop) should all be in root of installer like with regular template. Any extras can go into common. I'll push an update to the wiki on that shortly
Click to expand...
Click to collapse
That was my second guess!
Zackptg5 said:
Found the problem real quick. Seems I mixed up Unity with MMT-Ex logic:
The main boot scripts and such (service.sh, post-fs-data.sh, sepolicy.rule, and system.prop) should all be in root of installer like with regular template. Any extras can go into common. I'll push an update to the wiki on that shortly
Click to expand...
Click to collapse
that did the trick, much appreciated.
Updated MMT-Ex to v1.1! Been pushing some fixes for a while now and I feel like it's good to go for the next version. See the wiki for changelog: https://github.com/Zackptg5/MMT-Extended/wiki/Changelog
Subscribed. Appreciate your efforts!
Minimun Magisk version?
panchogg said:
Minimun Magisk version?
Click to expand...
Click to collapse
It follows official magisk template so 19 is minimum currently
MMT-Ex has been updated to v1.2! I anticipate this being the last update for a while unless something comes up - think I got it at a good state.
Changelog can be found same place as always: https://github.com/Zackptg5/MMT-Extended/wiki/Changelog
Some notable changes are:
MMT-Ex now has the same behavior as mainstream magisk module template - it always uninstalls/installs Furthermore, to simplify things, it'll only work in magisk manager. If you flash it in TWRP, it'll trigger automatic removal - this was kept in as a save from a module causing a bootloop
common/uninstall and upgrade scripts are gone now - no need for them anymore. There are very few instances where you'd need custom uninstall logic now since MMT-Ex handles all file removal automatically but if you do have something, you can place it in the TOP of the uninstall file at root of installer
ORIGVEN variable is gone - turns out that original vendor is always $ORIGDIR/vendor so you can just use that
Zackptg5 said:
MMT-Ex has been updated to v1.2! I anticipate this being the last update for a while unless something comes up - think I got it at a good state.
Changelog can be found same place as always: https://github.com/Zackptg5/MMT-Extended/wiki/Changelog
Some notable changes are:
MMT-Ex now has the same behavior as mainstream magisk module template - it always uninstalls/installs Furthermore, to simplify things, it'll only work in magisk manager. If you flash it in TWRP, it'll trigger automatic removal - this was kept in as a save from a module causing a bootloop
common/uninstall and upgrade scripts are gone now - no need for them anymore. There are very few instances where you'd need custom uninstall logic now since MMT-Ex handles all file removal automatically but if you do have something, you can place it in the TOP of the uninstall file at root of installer
ORIGVEN variable is gone - turns out that original vendor is always $ORIGDIR/vendor so you can just use that
Click to expand...
Click to collapse
Took you a while to find a proper avatar..