Related
The actual creation of an arm linux chroot image is probably out here on teh internetz somewhere, but I can assist with my mounting shell script (which works).
My image is of a debian arm chroot, and the image filesystem is ext2 (a good idea for fewer writes. ie innately non-journaling), has been used extensively on fw DE .17 and I'm currently trying it out on WW .29 (thank you, miloj).
I would upload my debian img somewhere, but I've actually broken it somewhat (it works for my needs, but it's nonetheless a bit too hacked up to be reliable).
I've modified it somewhat for generalization, some of it is probably wrong and/or redundant, and it IS hackish and ugly, but it works for me (tm).
* the chroot image only need a root account (and probably bash installed, but it usually is)
* You need busybox installed.
* You need to upload your chroot image named linux.img to the internal sdcard in a folder named linux
A shell script to set things up is attached.
What you need to do:
push the install script and run it:
Code:
adb push installlinuxstuff.sh /data/local/
adb shell sh /data/local/installlinuxstuff.sh
Now you can (from adb shell or terminal emulator on device):
Code:
su -
/data/local/mnt/linux.sh
/data/local/mnt/notlinux.sh
Feel free to remove the install script at
/data/local/installlinuxstuff.sh
when you've got it up and running.
Alternative way to run the scripts from adb shell:
Code:
adb shell su -c /data/local/mnt/linux.sh
adb shell su -c /data/local/mnt/notlinux.sh
I usually symlink start and stop (in my case deb and undeb) shell scripts placed in /data/local/mnt in /system/bin (ie shell scripts with 'su -c /data/local/mnt/whatever.sh' in them) for easy start an stop from terminal emulator, and if you've gotten this far you may welcome the small advice. (in other words - don't do this unless you _really_ know what you're doing)
Debian ARMHF or ARMEL?
If you would uploaded it (good place is google drive , sharing as public, as there are no ads or bull**** and the download is extremely fast) I would love to try your image - after modifying your script so it can work on a UHS-1 class MicroSD I want to try running this off of (should give it a little more speed).
zamaditix said:
Debian ARMHF or ARMEL?
If you would uploaded it (good place is google drive , sharing as public, as there are no ads or bull**** and the download is extremely fast) I would love to try your image - after modifying your script so it can work on a UHS-1 class MicroSD I want to try running this off of (should give it a little more speed).
Click to expand...
Click to collapse
Armel (I use the same chroot installation on my phone in a smaller image file (with less stuff installed)). I've got loads of personal stuff all over it and besides - it's somewhat broken. I really don't want to try to fix it.
So I'm working on retracing my steps, creating a clean armhf ext2 image (debian wheezy base installation for now) and redo the mount script, but I can't make any promises on a release date.
Anyhu - there are loads of images (armel, at least) on teh internetz (BT5 and too many ubuntu, for instance).
Just check so our kernel can mount the filesystem.
Edit: if not you can just create a new image file with a filsystem that's mountable and copy the chroot files to it.
So the ideal image for this tablet is armhf? If I wanted to create a Gentoo image, I would go with armv7? I'm just not sure exactly which ARM architecture this tablet is.
EndlessDissent said:
So the ideal image for this tablet is armhf? If I wanted to create a Gentoo image, I would go with armv7? I'm just not sure exactly which ARM architecture this tablet is.
Click to expand...
Click to collapse
The CPU is the Tegra 3 if you want to google it and it is an ARMv7 w/ NEON extensions chip. ARMv7 specification requires hardware fp so naturally it is ARMhf.
Nice to hear, keep us updated on your progress. I'm currently running an armel copy of Ubuntu 12.04 but it has problems with some packages and others are armhf only.
When I run linux.sh, I get an error that /sdcard can't be mounted because it doesn't exist.
Code:
mount: mounting /sdcard on /data/local/mnt/linux/sdcard failed: No such file or directory
I also tried changing the script to mount /mnt/sdcard, but that didn't work either.
EndlessDissent said:
When I run linux.sh, I get an error that /sdcard can't be mounted because it doesn't exist.
Code:
mount: mounting /sdcard on /data/local/mnt/linux/sdcard failed: No such file or directory
I also tried changing the script to mount /mnt/sdcard, but that didn't work either.
Click to expand...
Click to collapse
Yes, it is somewhat hackish, like I wrote. My image has got an sdcard folder (/sdcard) inside of it where I mount /sdcard from android. (Ie chroot and mkdir /sdcard)
followed this:
http://androlinux.com/android-ubuntu-development/how-to-install-ubuntu-on-rooted-transformer-prime/
make sure you have busybox installed der. Or at least the cp command in /system/bin
works well on my TF300T, Yea its not native but im currently configuring it for kernel building ;-D
FlyingPoo said:
followed this:
http://androlinux.com/android-ubuntu-development/how-to-install-ubuntu-on-rooted-transformer-prime/
make sure you have busybox installed der. Or at least the cp command in /system/bin
works well on my TF300T, Yea its not native but im currently configuring it for kernel building ;-D
Click to expand...
Click to collapse
Why does the mount script remount a non-existing block device with an ancient (according to android) filesystem?
Code:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
Edit: I read all the scripts, and they all mount that crap. It's not made for transformers, and on the android device it's made for it leaves /system mounted rw after you've run it, and WHEN run (installed) it modifies too much in /system/bin
Code:
# At first it copies loads of crap to /system/bin, and then:
cd /system/bin/
chmod 4777 *
It's not even "hackish" - it's just... wrong...
Will loop1 work every mount?
Code:
mknod /dev/loop1 b 7 0
losetup /dev/block/loop1
I'm almost only asking, since this thread was supposed to be about scripts?
gasingvar said:
Yes, it is somewhat hackish, like I wrote. My image has got an sdcard folder (/sdcard) inside of it where I mount /sdcard from android. (Ie chroot and mkdir /sdcard)
Click to expand...
Click to collapse
Thanks. I created /sdcard, and it works almost perfectly now. However, mounting devpts at /dev/pts doesn't seem to work. I replaced that line with
Code:
mount --bind /dev $mnt/dev
and it seems to work fine. Is there anything wrong with my method?
/dev/void said:
Why does the mount script remount a non-existing block device with an ancient (according to android) filesystem?
Code:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
Edit: I read all the scripts, and they all mount that crap. It's not made for transformers, and on the android device it's made for it leaves /system mounted rw after you've run it, and WHEN run (installed) it modifies too much in /system/bin
Code:
# At first it copies loads of crap to /system/bin, and then:
cd /system/bin/
chmod 4777 *
It's not even "hackish" - it's just... wrong...
Will loop1 work every mount?
Code:
mknod /dev/loop1 b 7 0
losetup /dev/block/loop1
I'm almost only asking, since this thread was supposed to be about scripts?
Click to expand...
Click to collapse
I'm assuming you're talking about the link in the post you quoted, even though you seem to be referencing the OP's use of the word "hackish". The script in the OP doesn't do any of that stuff. It just creates a few directories in /data/local/mnt/ and writes the mount/unmount scripts, which themselves only un/mount appropriate directories for the tablet. As for your question, I'm not nearly experienced enough to answer it. Sorry.
EndlessDissent said:
Thanks. I created /sdcard, and it works almost perfectly now. However, mounting devpts at /dev/pts doesn't seem to work. I replaced that line with
Code:
mount --bind /dev $mnt/dev
and it seems to work fine. Is there anything wrong with my method?
Click to expand...
Click to collapse
AFAIK your mount seems to be more complete, ie more android hardware goodies accessable from the chroot environment. However - that means more things possibly going wrong (like writing to a device who's critical to the android environment).
Personally I'd try to find what "hardware goodies" and whatnot I'd need to get the chroot environment working optimally, and not mount ALL of /dev.
EndlessDissent said:
I'm assuming you're talking about the link in the post you quoted, even though you seem to be referencing the OP's use of the word "hackish". The script in the OP doesn't do any of that stuff. It just creates a few directories in /data/local/mnt/ and writes the mount/unmount scripts, which themselves only un/mount appropriate directories for the tablet. As for your question, I'm not nearly experienced enough to answer it. Sorry.
Click to expand...
Click to collapse
Yes, and the OP is very honest about his script(s) being "hackish", which I interpret to mean 'not optimal, possibly redundant but working', all of which it is (and I applaud the early release, since for instance I could get things rolling), but the ubuntu image installation and mounting scripts from the other poster ( whom I was addressing ) are plain faulty.
I am looking for a armhf build of ubuntu or debian that I can chroot (newer the better), if anyone knows of such a build that would be fantastic but if not does anyone know of an easy to follow guide to compile such a thing?
I found two pretty good guides. I mostly followed THIS ONE, but I found that it doesn't mount enough before "first boot", so what I did was follow the guide until the point where you move the image to the tablet. Then I ran the OP's installlinux.sh script, and then the mount script. However, the mount/unmount scripts need to be edited before using them. Comment out the sdcard line and probably the devpts line (mounting devpts didn't work; Bash complained that devpts didn't exist; I had to replace it with the line I mentioned a few posts above, but as /dev/void says, it could be problematic, so be careful). Mount the image, make the /sdcard directory, exit, unmount, and edit the scripts again to mount/unmount /sdcard.
Next time you enter the chroot, feel free to run the
Code:
sh /debootstrap/debootstrap --second-stage
command to build the image, and follow the linked guide until the next time it tells you to exit the session (NOTE: The second echo "whatever" > sources.list command is wrong; it should be echo "whatever" >> sources.list; Also, remember to replace "squeeze" with the appropriate Debian version, in my case, "testing"). Instead of exiting right after the apt-get update, I'd recommend playing around with the chroot and configuring whatever apps you install. You can just use the OP's scripts now and ignore the script in the linked guide.
When the guide I linked above gets to this line:
Code:
sudo debootstrap --verbose --arch armel --foreign squeeze /mnt/squeeze/ http://ftp.debian.org/debian
just replace armel with armhf, and if you want a testing image, replace squeeze with testing.
Sorry I'm not attaching my image. I made it gigantic (5GB), so I don't really have anywhere to store it, and you probably wouldn't want to download a file that big. Plus, it already has Openbox and a bunch of other things you probably don't want installed. I'm assuming you'd want GNOME or KDE instead.
I will be using this thread to post my scripts and link them to other threads as needed. For this thread, I am assuming you know what you're doing. You don't need mad hacking skills and you don't need to be an expert (I'm sure as hell not), but knowing your way around the file system and basic shell scripting are helpful.
Some background: I am using the stock ROM and kernel (SGS2 - GB27, SGS4 - MDC), so all of my tips revolve around using stock and all of my scripts (even the flashable ones) will work without flashing from recovery (just extract the script from the ZIP and execute it while the phone is in phone-mode - you know... powered on ).
You are welcome to use my scripts in your apps. I only ask that you give me some credit.
I am not responsible for bricking your phone. I have only tested my scripts on my personal Samsung Galaxy S2 and S4 from Sprint. You are welcome to try on your phone, but I offer no warranties or guarantees as to whether they will work or not. Back up your ****!
All of this requires root!
Below is a list of the scripts I have written for y'alls. Enjoy.
Custom df: Shows where irregular mounts ("mount -o bind") are mounted. [ Forum post | Download ]
Currently doesn't work on my SGS4.
Easily move Phonesky.apk and GoogleServicesFramework.apk to /system or /preload for Multi DPI Play Store. [ Forum post | Download ]
Untested on my SGS4, but there's no reason to think that it won't work.
Use your SGS2's internal SD card for Link2SD instead of making a second partition on your external SD card (although, depending on the setup, you may still need to make a tiny partition on your external SD card) and your external SD card as your internal SD card [ Forum post ]
Untested on my SGS4. I have no need for it.
Clean up Link2SD: Delete files associated with Link2SD when uninstalling it. It does not revert the links Link2SD makes. It only deletes the mount scripts. [ Forum post | Download ]
If you use the debuggerd script to enable init.d, running this script will cause you to lose init.d.
Untested on my SGS4, but there's no reason to think that it won't work.
Delete Samsung's bloatware from the Sprint SGS2. [ Forum post | Download ]
Untested on my SGS4, but there's no reason to think that it won't work; however, it was written specifically for the SGS2's bloatware. See thread S4 System Apps Safe To Remove for a list of SGS4 bloatware apps.
Google Home Launcher (from Kit Kat).
Works on Jelly Bean.
Below are some other tweaks.
You can use custom boot animations with the stock ROM. All you need to do is swipe a "/system/bin/bootanimation" binary file from another ROM (such as @rujelus22's Blu Kuban FL24 (ICS) or Blu Kuban GB27 (JB 4.1.2)), paste it into "/system/bin", and make it executable.
For JB 4.2.2, make sure the user and group are root and shell respectively. This doesn't seem to be a problem with JB 4.1.2 and below. It's also possible that my initial testing involved a boot animation that didn't work on my SGS4, so if it works with root as both user and group, then roll with it. :good:
Also for JB 4.2.2, use the file from a JB 4.2.2 ROM, such as The Blu Kuban S4.
You can enable init.d scripts very easily by renaming "/system/bin/debuggerd" to "/system/bin/debuggerd.bin", replace it with the following, and make both files executable. If "/system/bin/debugger.bin" already exists, then edit "/system/xbin/busybox run-parts /system/etc/init.d" into "/system/bin/debuggerd".
As with the above, make sure the user and group are root and shell.
Code:
[color=green]#!/system/bin/sh[/color]
LOG=/data/debuggerd.log
echo "$(date)" > $LOG
echo "init.d" >> $LOG
/system/xbin/busybox run-parts /system/etc/init.d 1>>$LOG 2>>$LOG
echo "$(date) finished" >> $LOG
echo debuggerd.bin launched >> $LOG
exec /system/bin/debuggerd.bin
Below are some tips.
Most of the things you can do with a custom kernel, you can do with the stock kernel, it just requires more work and more risk.
If you replace an odexed system app with a deodexed system app, make sure you delete the app's ODEX file (it's the same file name except with the extension .odex).
Conversely: if you replace a deodexed system app with an odexed system app, you better have the ODEX file to go with it.
You can clear the dalvik-cache without a custom kernel by deleting the contents of "/data/dalvik-cache". You can even delete an individual app's dalvik-cache by finding the file "/data/dalvik-cache/[email protected]@[email protected]" or "/data/dalvik-cache/[email protected]@[email protected]" and delete it.
You can manually uninstall a system app's update by finding the file "/data/app/.apk" and delete it.
You can manually delete all user data by deleting the contents of "/data/data". You can even delete an individual app's data by finding the folder "/data/data/" and delete it.
Making scripts and binaries executable:
They must be on an EXT formatted filesystem (e.g. /data, /system, /preload).
They must be at least readable and executable by the user 'shell' (755 (read/execute for all, write only for user - "u=rwx,a=rx" if your busybox supports that method) is what I usually use).
Code:
chown root:shell ""
chmod 755 ""
chmod u=rwx,a=rx "" # busybox must support symbolic modes
Changing file permissions requires read/write access to the filesystem on which the file resides:
Code:
mount -o remount,rw /system # make the /system partition read/write
mount -o remount,ro /system # make the /system partition read only
The stock kernel is considered "production" whether or not it's rooted; therefore, you cannot use ADB to push or pull files directly to or from protected partitions, nor run ADB as root, nor use ADB's remount command, so you have to use unprotected partitions as a sort of buffer. You can, however, access the ADB shell and issue the "su" command wherein you can use "cp" to copy files to or from protected partitions prior to using ADB to push or pull the desired file. However, there is an app aptly named [root] adbd Insecure by @Chainfire that patches the ADB daemon to get around this limitation.
Example:
Code:
c:/android-sdk> adb shell
[email protected]:/ $ su
[email protected]:/ # cp /system/bin/debuggerd /sdcard/debuggerd
[COLOR="green"]-- open a new command prompt window --[/COLOR]
c:\android-sdk> adb pull /sdcard/debuggerd debuggerd
c:\android-sdk> adb push debuggerd /sdcard/debuggerd
[COLOR="green"]-- switch to the first command prompt window --[/color]
[email protected]:/ # mount -o remount,rw /system
[email protected]:/ # cp /sdcard/debuggerd /system/bin/debuggerd
[email protected]:/ # chown root:shell /system/bin/debuggerd
[email protected]:/ # chmod 755 /system/bin/debuggerd
[email protected]:/ # mount -o remount,ro /system
Some noteworthy files and folders:
/proc/self/mountinfo: If you can read it, it tells you where your partitions and folder binds are mounted.
/proc/partitions: Shows all of your SD card's partitions, how many blocks each has, and their vold numbers (eg "179 1 30578964 mmcnlk0p1").
/dev/block/platform/dw_mmc/by-name: This folder contains symlinks to your internal eMMC's partitions indexed by what they are for (eg UMS for your internal SD card - "realpath /dev/block/platform/dw_mmc/by-name/UMS" will print out the device path (ie "/dev/block/mmcblk0p11")).
/dev/block/platform/dw_mmc/by-num: This folder is like the previous except that they are indexed by partition number (eg "p11").
/proc/version: Shows what version of Linux is currently being used.
/data/system/batterystats.bin: Delete this when your battery is fully charged and still plugged in to recalibrate it.
Footnotes:
For "/data/app", "/data/data", and "/data/dalvik-cache" files you need to know the package name. There are various apps that will tell you, including Link2SD (mentioned above), Titanium Backup, and the web URL of the app in the Play Store (ex: https://play.google.com/store/apps/details?id=com.devname.appname).
More:
Random boot sound using your notification sounds
Make ADB work for all users - Jelly Bean 4.2.2 (Updated 07/15/13 00:35 MST)
Stock ROM - SGS4 - init.d
No-data restore tips
SGS4 Bloatware Remover
Make apps run faster and increase battery life
Random boot sound using your notification sounds
The attached ZIP contains a script that can be run pre or post boot. It just needs to be executable.
Preboot requires init.d. See the OP for enabling it if you are on a stock rooted ROM and requires the file to be readable and executable ("chmod 755" works fine).
Postboot requires an app such as Scripter (ROM Toolbox) or Script Manager to execute the script at boot.
Requires the variable $RANDOM. You can make sure it's available from the command line ("echo $RANDOM").
Use this script at your own risk. I provide no warranties or guarantees.
What does this script do?
Check for carrier boot up sounds (sub folders in the "/system/media/audio/ui" folder) and moves them to "/system/media/audio/notifications" renaming them as needed.
Create symlinks in the above folders to "/system/media/audio/ui/PowerOn.ogg".
Check if "/system/media/audio/notifications/PowerOn.ogg" is present and copy it to "/system/media/audio/ui/PowerOn.ogg" it's not.
Count the number of files in "/system/media/audio/notifications".
Grab a random number between 1 and the number of files found inclusive (math notation: "[1, numFiles]").
Go through "/system/media/audio/notifications" and copy the file at index random to "/system/media/audio/ui/PowerOn.ogg".
Notes:
The stock file is included. If you want a different sound in its place, you can either comment out that line in the script and delete the "/system/media/audio/notifications/<subfolder>_PowerOn.ogg" files from "/system/media/audio/notifications" or just replace "/system/media/audio/notifications/PowerOn.ogg" with some other sound file and still delete the "/system/media/audio/notifications/<subfolder>_PowerOn.ogg" files from "/system/media/audio/notifications".
If you want more sounds, just copy them to "/system/media/audio/notifications" (OGG files only).
The script does not check for valid files and blindly renames the destination file to "PowerOn.ogg".
It does not look in "/sdcard/media/audio/notifications" or anywhere else for audio files.
I do not recommend using alarms or ringtones files as they are usually looped which can cause the media scanner to get stuck and overheat your phone or tablet - those files may continue to play even if you can't hear them.
If you can't hear a sound on boot, it is likely that the file is either invalid or has no audio (ex: my /system/media/audio/ui/BST/PowerOn.ogg has no audio).
It was tested and works on a Samsung Galaxy S2 (stock JB 4.1.2) and a Samsung Galaxy S4 (stock JB 4.2.2) both from Sprint and using stock kernels.
There's no obvious reason it won't work on other phones and tablets with other ROMs from other carriers.
Nice work E.
cerj said:
Nice work E.
Click to expand...
Click to collapse
:good:
Make ADB work for all users - Jelly Bean 4.2.2 (Updated 07/15/13 00:35 MST)
With Android 4.2.2, ADB now requires RSA keys. This poses a problem when attempting to connect to the device's ADB server from the device itself and the device won't ask for authorization unless it's connected via USB. Well, there's hope, yet.
For the following, I'm assuming you used my method for adding init.d support to your device.
Use these scripts at your own risk. I provide no warranties or guarantees.
Add the following script to /system/bin/debuggerd. If you use an alternate method, please note that it must be executed by the debugger daemon. You must do this first or you'll have to manually restart the debugger daemon after editing this file and executing the run-once script (next step), so edit this file first and save it.
Code:
if [ ! -e "/.android" ]; then
busybox mount -o rw,remount /
mkdir /.android
mount -o bind /data/.android /.android
busybox mount -o ro,remount /
fi
Then run this script once from the device (not over ADB on your PC).
Code:
[COLOR="Green"]#!/system/bin/sh[/COLOR]
HOME=/data
adb kill-server
adb start-server
stop adbd
cat /data/.android/adbkey.pub >> /data/misc/adb/adb_keys
echo "" >> /data/misc/adb/adb_keys # Add a blank line at the end of the file
start adbd
HOME=/
adb kill-server
stop debuggerd
start debuggerd
Notes:
You can also find the abdkey.pub file on your Windows' PC here, C:\Users\<user name>\.android\adbkey.pub. Copy it to your device by whatever means necessary, then append it to /data/misc/adb/adb_keys and you won't need to initially use the USB to allow the PC connection. Not really necessary unless your PC has no USB or you've broken your USB cable.
This may have inadvertently corrected the mounting issue introduced in Jelly Bean 4.2.2.
You can also allow other Android 4.2.2 devices, but it requires ADB version 1.0.31 and for you to manually append the contents of /data/.android/adbkey.pub from device A (the one you want to use to ADB on) to /data/misc/adb/adb_keys on device B (the target device).
Don't delete /data/.android
This won't fix apps. Just allow you to use ADB to connect to your device from itself.
Tested on my SGS4. No reason it won't work on other devices.
If you already have a /data/.android directory, you may not need to do this. On my SGS4, HOME defaults to "/" which the ADB daemon can't write to, so it can't make the RSA key.
The run-once script temporarily changes HOME to "/data", a writable directory, so the ADB daemon can write the RSA key then it append it to the allowed clients file then restarts the debugger daemon thus binding /data/.android to the /.android directory allowing all Linux users ADB access to the device.
Reassigning HOME to a new value on one user only changes its value for that user which is why I'm binding /data/.android to /.android.
Code:
# Example
[email protected]:/ $ echo $HOME
/
[email protected]:/ $ HOME=/data
[email protected]:/ $ echo $HOME
/data
[email protected]:/ $ su 1000
[email protected]:/ $ echo $HOME
/
Alternatively (much easier):
Make the .android folder in /data (mkdir /data/.android).
Add the script, the first code block in this post, to your debuggerd file or an init.d script.
Restart the debugger (stop debuggerd; start debuggerd) or reboot the phone.
Restart ADB (stop adbd; start adbd).
Copy the newly created public key to the allowed clients (cat /data/.android/adbkey.pub >> /data/misc/adb/adb_keys; echo "" >> /data/misc/adb/adb_keys).
Restart the ADB server (adb kill-server; adb start-server).
SGS4 Bloatware Remover
I have written a live-script to delete all of the SGS4 bloatware except GoogleContactsSycAdapter and SecLauncher3. If you want to delete those, remove the "#" from that line in the script. If you want to exclude an app, add a "#" to that line and put the app name in quotes (ie AppName / becomes "#AppName" / (including the forward slash) or just remove that line. If you remove the last item (YouTube in this case), remove the forward slash from the previous line.
Use this scripts at your own risk. I provide no warranties or guarantees.
What this script does:
Move the app's APK and ODEX to /sdcard/SystemAppsBackup.
Delete its dalvik-cache.
Reboot the phone. If it doesn't reboot, you'll have to do this yourself.
What this script does not do:
Delete the app's data. Because the script doesn't know the package name.
Delete its Play Store update (located in /data/app). Because the script doesn't know the package name.
Mount the SD card if it's not mounted. If you want backups, make sure the SD card is mounted.
Care if you delete a system app you wanted to keep. Most apps that you would want to keep may be available in the Play Store.
Restore apps.
Notes:
Apps will crash left and right when you execute this script in running mode. Don't fret, this is normal.
This is a live-script which means you have to manually execute the script either with a terminal emulator, a script executor like Scripter, or ADB.
This is not flashable.
If executing via ADB in Recovery mode, you may need to mount the SD card to /storage/sdcard0 manually or settle for no backups.
If you restore an app from /sdcard/SystemAppsBackup, make sure you get the ODEX file if present and set the permissions for both to 644.
This list is based off the list in the thread, S4 System Apps Safe To Remove.
Here You Go Guys, I took me about 30 mins, but I have successfully added all the app in the Op to a flashable Zip.
The Zip is base of TrulyClean v1.6 script code, I just deleted his ;delete/system/...apk and replaced it with all the ones from the OP
bigtobitobs said:
Here You Go Guys, I took me about 30 mins, but I have successfully added all the app in the Op to a flashable Zip.
The Zip is base of TrulyClean v1.6 script code, I just deleted his ;delete/system/...apk and replaced it with all the ones from the OP
Click to expand...
Click to collapse
Looks like you're deleting bloatware, perhaps you should post that in the right thread... or at least a more appropriate thread.
Sent from my SGS4.
egingell said:
Looks like you're deleting bloatware, perhaps you should post that in the right thread... or at least a more appropriate thread.
Sent from my SGS4.
Click to expand...
Click to collapse
LOL OMG I am so sorry, I had multiple tabs open and put this in the wrong forum. Please Delete
bigtobitobs said:
LOL OMG I am so sorry, I had multiple tabs open and put this in the wrong forum. Please Delete
Click to expand...
Click to collapse
Would that I could.
Sent from my SGS4.
Make apps run faster and increase battery life using Xposed App Settings.
Did you install GravityBox on your SGS4 then uninstall it and now you can't hear your games or music?
I think it has to do with GravityBox's "Volume Steps" option not undoing when GB is uninstalled. This is how I fixed it (forum post).
Stock ROM - SGS4 - init.d
I recently found out that my debuggerd hack to enable init.d support on my stock SGS4 wasn't working. So, I did this and now it works.
Make a file named "install-recovery.sh" and drop it into /system/etc. Whatever script you put in here will execute at boot up so long as the user/permissions are correct.
Code:
chown shell:shell "/system/etc/install-recovery.sh"
chmod 755 "/system/etc/install-recovery.sh"
chmod u=rwx,a=rx "/system/etc/install-recovery.sh" # busybox must support symbolic modes
Use this script at your own risk. I provide no warranties or guarantees.
My "/system/etc/install-recovery.sh" script:
Code:
[COLOR="Green"]#!/system/bin/sh[/COLOR]
LOG="/data/install-recovery.log";
echo "Executing install-recovery.sh" > $LOG;
echo "" >> $LOG;
echo "$(date) install-recovery hack..." > $LOG
echo "" >> $LOG
echo "init.d" >> $LOG
[COLOR="green"]# I can't get run-parts to work for some reason, but this will run every *.sh script in /system/etc/init.d as root.[/COLOR]
for N in /system/etc/init.d/*.sh; do
su -c "$N" 1>>$LOG 2>>$LOG
done;
Notes:
Mount binding (in JB 4.2.2+) seems to work. E.g. mount -o bind /folder1 /folder2
$(date) does not provide the correct date (mine said: "Wed Apr 15 13:24:13 MST 1970").
The Package Manager is not available. (There may be other unavailabilities, but I don't intend to test it thoroughly.)
Somethings I discovered recently while doing a no-data system restore for the second time in the same night and some tips relating to system restores:
* When doing a no-data restore, disabled/frozen system apps remain disabled.
* Apps that can't be disabled even with Titanium Backup will not remain disabled after a reboot and will sometimes crash/FC repeatedly until uninstalled.
* If an app won't open or FCs, try converting it to a system app and back to user app or vice versa.
* Don't integrate system app updates into the ROM. In the event that you have to do a no-data restore, those updates will be retained.
* Don't convert user apps to system apps for the same reason.
* Disregard the previous two tips if disk space is a problem. It's just more time consuming (redownloading updates, reintegrating, and reinstalling) after a restore.
* Save all modified system files, such as /system/bin/debuggerd, /system/build.prop, /system/etc/install-recovery.sh, and if your ROM uses /system/etc/unit.d, any modified or extra files there. If you use them, you'll need them after a restore.
* For a smoother post no-data restore, use Titanium Backup's labels so you can batch-uninstall those pesky system apps you don't want.
SGS2 - JB 4.1.2 GB27
SGS4 - JB 4.2.2 MF9
any command for updater script to make directory in root of android ??
HassanMirza01 said:
any command for updater script to make directory in root of android ??
Click to expand...
Click to collapse
Creating directories in / and all the files contained therein must be redone on every boot. That said, you just need to make root writable and make the directory.
mount -o remount,rw /
mkdir /whatever
mount -o remount,ro /
Note: Every time you wish to create, modify, or delete files you'll have to make root writable.
Sent from my LG-H811 using Tapatalk
egingell said:
Creating directories in / and all the files contained therein must be redone on every boot. That said, you just need to make root writable and make the directory.
mount -o remount,rw /
mkdir /whatever
mount -o remount,ro /
Note: Every time you wish to create, modify, or delete files you'll have to make root writable.
Sent from my LG-H811 using Tapatalk
Click to expand...
Click to collapse
Actually.... I wanna add some files within folder in root of android root... So i need to use above three commands nd then after making directory, i should extract files to that folder ??
HassanMirza01 said:
Actually.... I wanna add some files within folder in root of android root... So i need to use above three commands nd then after making directory, i should extract files to that folder ??
Click to expand...
Click to collapse
Yes.
Sent from my LG-H811 using Tapatalk
:good:
The stock recovery on the Nook Simple Touch has a routine to restore the device to factory state, wiping everything in the process. It is initiated on the 8th unsuccessful boot (unsuccessful := interrupted before the boot counter could be reset). The image is stored on the "/misc" partition, /dev/block/mmcblk0p3, as /factory.zip. On my device, it's version 1.0.1 (file size: 108460423, MD5 sum: 3ae0d4d9869330dec639a7da9c50fa72). Not very useful. So, how about customizing it? Or at least upgrading it to stock 1.2.1?
When restoring to factory state, the /cache and /data partitions are wiped independently by the stock recovery. As for the files inside the ZIP, there is no difference between the factory image and the OTA (over-the-air) update (nook_*_update.zip). The format of both files is the standard Edify ("updater-script") style. If you have your own script you can put it there for easy restoration. If you don't, you can at least upgrade the factory image there to 1.2.1, the latest version. The example is for the latter case, but all the steps will be the same, except the first one.
Please do not follow these instructions blindly. Instead, read them critically and adjust to your situation, adding extra steps such as backups where necessary. Make sure that you don't mind if everything from your device is erased in the process.
Remove B&N cruft from the ZIP update header
Start with the file nook_1_2_update.zip (get it here from B&N). Make sure you have the right file: size 121323347, MD5 sum: 30822c2927482380c325a47dc060daee. Note that while a well-formed ZIP file starts with the letters "PK" (from the initials of Phil Katz, the original developer of the ZIP format), the B&N ZIP has some proprietary gibberish at the beginning:
Code:
...............'1.2.1.24.carbon1_2.gossamer.rrdp.s70455.......XOLBsPWsxv0saXev7rdGBBrQLzdM74ai2CM4h6oD/D3S9xeKq8eFYW7j0+MgLohN4x/3tyIYaZV6YiLEi7gLXq+7XjvWV4KaTGvNw0wM6x11IPOEzYwmHryagnY91XjkfKTjwKR8XC3SkSRu4TT01DZ6lfqsw6MZO18AFz48GEjXcxKy8SQZyhA++kobYWlcC8jNa/EmkGgVJien7QJ4LvR8N5Bftk11WRTOy6+BSQQgdBh4K/i2WI0TqfpH7JC+6vNp5rb61KTXpZIMLHGyZloYca68mnn4rmr1SKqodpffgSmYI+f7DPt7RgBEkXGz20x+3kKA+OcPbd1QKvIwd+A==.........;=.
First 418 bytes of nook_1_2_update.zip. Unprintable characters replaced with dots.
Unzip and other unpackers will get through this just fine so you might not even notice it but it will prevent the file from working as factory image for the stock recovery, so let's start by getting rid of the cruft. There are at least three options here: (1) use dd(1) (UNIX shell or Windows CLI), (2) use Free Hex Editor (Windows GUI), (3) unzip and repack again. The dd command if you're lucky to have a recent version is:
Code:
dd if=nook_1_2_update.zip of=factory.zip skip=418bytes
- or -
Code:
dd if=nook_1_2_update.zip of=factory.zip iflag=skip_bytes skip=418
Option (3) will break the B&N signature on the ZIP. Theoretically, if the signature is preserved, the file should work as-is as the new factory image as it matches the key stored in the recovery). It didn't work for me but I didn't try too hard because what I want to do is to use a custom image anyway so feel free to check for yourself (skip to the last step).
Otherwise, if you are using the stock update file that you want to sign again, you need to remove the signature that is already there. Supposing your soon-to-be new factory image file is called factory.zip, the way to do it is:
Code:
zip -d -q factory.zip META-INF\CERT.SF META-INF\CERT.RSA META-INF\MANIFEST.MF
Insert your key into stock recovery RAM disk image
For customized factory.zip signed with your own key, we need to tweak the recovery image a bit.
Extract the image from the update ZIP:
Code:
unzip -j nook_1_2_update.zip ramdisk-recovery.img
Replace the file res/keys (see attachment) in the image, using XDA user Renate NST's bootutil.exe tool:
Code:
bootutil /r ramdisk-recovery.img res\keys
You can also leave the old key in place and append the new one, just make sure there is nothing in between them (not even whitespace). And here are the alternative steps to unpack and repack the image using just the standard tools, which might come handy on UNIX:
Unpack:
Code:
dd if=ramdisk-recovery.img bs=64 skip=1 | gzip -cd | cpio -id
Repack:
Code:
find . -not -name ramdisk-recovery.img | cpio -oc | gzip -c9 | mkimage -A arm -O linux -T ramdisk -C gzip -a 0 -e 0 -d - ramdisk-recovery.new.img
Now the image just needs to be installed:
Code:
adb shell mkdir /data/boot
adb shell mount -t vfat /dev/block/mmcblk0p1 /data/boot
adb push ramdisk-recovery.img /data/boot/uRecRam
adb shell umount /data/boot
adb shell rm /data/boot
Sign and install the customized factory image ZIP
Suppose our new factory image is called factory.zip. Then to sign it:
Code:
java -jar signapk.jar [B]-w[/B] testkey.x509.pem testkey.pk8 factory.zip factory.signed.zip
See the attachment below for the necessary files. Note the -w switch, which is particularly important in this case.
Now just for the installation part:
Code:
adb shell mkdir /data/factory
adb shell mount -t ext2 /dev/block/mmcblk0p3 /data/factory
adb push -p factory.signed.zip /data/factory/factory.zip
adb umount /data/factory
adb rm /data/factory
Restore to factory image to check if it works
For an easy alternative to the power button marathon:
Code:
adb shell
echo -n -e "\x08\x00\x00\x00" >/rom/devconf/BootCnt
reboot
Warning: this wipes everything, all your data on the device will be lost.
Bonus: What if you want to use your own key?
The testkey.{pk8,x509.pem} is one of these ubiquitous Android debug keys, used all around. Apparently, it was good enough for B&N as well, as they used a version of it too for their OTAs (see /system/etc/security/otacert.zip). If it's not good enough for you though, and you have your own key, the attached keys file will not work for you; instead, you need to generate the key dump in the right format for yourself using the dumpkey utility also provided in the attachment:
Code:
java -jar dumpkey.jar testkey.x509.pem >>res/keys
Replace the references to testkey with the name of your key throughout the examples. If you're doing this on Windows, remember to convert the line ending to UNIX format (CR+LF to LF), not doing so might make the key not work.
General note: If at any stage you need to debug why a key is rejected, there is a log being saved by the stock recovery under /cache/recovery/log.
Disclaimer: Please do not follow these instructions blindly, but instead adjust them to your situation. This is the minimal set of necessary actions, with any optional steps removed for the clarity of illustration. I don't do it this way myself: personally, I'd make a backup here and there, verify MD5 sums after copying large files, etc. In any case, if something goes wrong, you will have to boot from SD card and restore your device. If everything goes right, you will lose all the data on the device. These instructions are provided on an "as is" basis. I will not provide support if anything doesn't work as expected for you. Anything you decide to do based on the above instructions is your sole responsibility.
dumpkey.jar really helped, thanks for that. Had to make exponent 3 type android key else it gets rejected, if you compiled the class, can you remove that check? Out of thanks for today.
Just a short note:
"bootutil" is now called "imgutil" and can be found in the signature.
There are more options than before, but I forget which ones.
Extracting ramdisk image to change fstab.tenderloin to make system read and write allowing permanent root access using any ROM ever created for the HP Touchpad.
I am using Ubuntu 18.04.1 LTS 64-bit (All the software is open source and free, you can get the packages necessary for your distro)
Create a folder in /home (root) name it hpboot ( on the PC ) all work is done on the PC.
Open the custom ROM zip file and extract boot.img to the created directory hpboot
Open Terminal in the hpboot directory, all the commands needs to be enter there.
Text beginning with –>># are for information only. Do not paste into the Linux terminal window.
–>># The following will extract images from boot.img file located in the hpboot direcory.
–>># Copy and paste each individual line in the Terminal window one by one and wait until each command finish processing.
dumpimage -i boot.img kernel.uImage
dumpimage -i boot.img -p 1 ram
dd if=ram of=ramdisk.img.gz bs=64 skip=1
gunzip ramdisk.img.gz
mkdir ramdisk; cd ramdisk
cpio -i < ../ramdisk.img
–>>#The ramdisk files are uncompress in the hpboot/ramdisk directory
–>>#Open file fstab.tenderloin using (text editor) change mnt_flags of/system ext4 from ro to rw
–>>#Look like this when change from (ro ) read only to ( rw ) read and write.
–>>#<src> <mnt_point> <type> <mnt_flags and options>
–>>#/dev/store/cm-system /system ext4 rw,errors=panic
–>># Save and close the fstab.tenderloin file
–>># The next 3 steps will repack the files into the ramdisk and merge Kernel to create the finish boot image.
find . | cpio --create --format=’newc’ | gzip > ../ramdiskRW.img
cd ~/hpboot
mkimage -A arm -O linux -T ramdisk -C none -a 0x00000000 -n “TENDERLOIN RW SYSTEM RAMDISK” -d ./ramdiskRW.img ./ramdisk.uImage
mkimage -A arm -T multi -C none -n “Tenderloin RW System” -d kernel.uImage:ramdisk.uImage uImage.Android_RW
–>>#Boot the touchpad into TWRP, connect to PC, copy uImage.Android_RW to the external Micro SDCard.
–>>#Select MOUNT and touch Boot, go back, touch Advanced, File Manager, touch external_sd, select uImage.Android_RW, touch Copy File, touch boot, touch select Current Folder.
–>>#You should have free space on your boot for both images. At the boot screen you will have the option of Android (with no permanet ROOT access) and Android_RW (RW System), you need to install SuperSu. You can use any of the two options or delete uImage.Android and then rename uImage.Android_RW to uImage.Android for one boot option.
You do not need to re flash the ROM, you can add this boot file and use it with your current installed working ROM.
The process works for all boot.img created for the HP Touchpad. If you have a ROM and would like to have system read and write access then you can do this.
Hopefully a Linux Guru will create a script for this, which will automate the process to 3 seconds!
I like tinkering with my TP but I am running @Windows 7 on a 32 bit.. any suggestions?
Android is base on Linux OS.
Install vmware player and run ubuntu as a virtual machine, both are free.
--SNIP--
Hopefully a Linux Guru will create a script for this, which will automate the process to 3 seconds!
Click to expand...
Click to collapse
Here's a shell script that automates the process (rename the extension from .txt to .sh). Put the script and boot image file in any directory and type
Code:
./rwcreate.sh
If it doesn't execute, it probably needs its permissions changed.. Right click the file you created, select 'properties'. In the properties window, select "Permissions" and check "allow executing as ..." or type
Code:
chmod +x rwcreate.sh
in a terminal window
Thanks for your help and dedicating your time to make it easier for others.
I made suggestion to the script on correcting an error, on DU forum.
Now is just a click to get it done, but if we were in a perfect computer world, it could be even easier as to connect the HP Touchpad to PC using USB.
Then run the script and everything is complete!
Using adb pull command to get (boot.uImage) from hp boot directory, to PC.
Changes are done as per script.
adb push command new boot.uImage to hp boot directory, all done!
But making it easier, will make it more complicated and having to install more software and confusing!
HP_TOUCHPAD said:
Thanks for your help and dedicating your time to make it easier for others.
I made suggestion to the script on correcting an error, on DU forum.
Now is just a click to get it done, but if we were in a perfect computer world, it could be even easier as to connect the HP Touchpad to PC using USB.
Then run the script and everything is complete!
Using adb pull command to get (boot.uImage) from hp boot directory, to PC.
Changes are done as per script.
adb push command new boot.uImage to hp boot directory, all done!
But making it easier, will make it more complicated and having to install more software and confusing!
Click to expand...
Click to collapse
Done. Thanks.
shumash said:
Done. Thanks.
Click to expand...
Click to collapse
The script on this forum is correct, but in the DU the file was wrong, corrected now.
Thanks for the fix and help!
I wanted a way to easily work on GSIs with my phone. These are the fruits of my labor.
Prerequisites:
* Magisk manager > settings > mount namespace mode > global
* Termux
How to dump, edit, and convert your stock OS into a GSI?
1. Using Termux run the following commands. This assumes you have root.
Code:
su
ls /dev/block/bootdevice/by-name
cd /data/local/tmp
For me system is labeled as system_a, so this is what we're going to use. This name may differ by device so it's always a good idea to check. Next command...
Code:
dd if=/dev/block/bootdevice/by-name/system_a of=/data/local/tmp/system.img
2. About 1-2min after running the previous command you'll have a raw system image in your tmp directory. Now we need to mount it like so...
Code:
mkdir /mnt/a && chmod 0755 /mnt/a
mount -o loop system.img /mnt/a
3. If everything went smoothly your raw image is now mounted at /mnt/a and visible with a root explorer. Not only that, it's also live! So any changes you make while it's mounted will be permanent. Simply make any edits as you see fit using a root explorer, then unmount the image when you're done like this...
Code:
umount /mnt/a
Tip: If you can't unmount due to device or resource busy, back out of /mnt/a or any subfolders with your root explorer. If the files are being accessed then you can't unmount them until you get out.
4. Now that the raw image we dumped into /data/local/tmp has been edited, we need to convert it into a sparse image for flashing. Download arm_img_binaries.zip. Extract the files and copy img2simg to /data/local/tmp and set permissions to 0755. From termux run the following commands...
Code:
./img2simg system.img name-of-gsi.img
cp /name-of-gsi.img /sdcard/name-of-gsi.img
You're done! Now just install it like any other GSI using twrp or fastboot.
To clean up everything simply run...
Code:
rm -rf /data/local/tmp/*
How to edit a GSI that's already in sparse format?
Again we're going to need our arm_img_binaries. This time copy simg2img to /data/local/tmp & chmod 0755 just like before. Copy your GSI to the same location then run...
Code:
./simg2img name-of-gsi.img system.img
From there, just follow the guide starting at step #2.
Sources & Tools used:
Termux: Clang, build-essential, git, and python for compiling arm versions of the needed binaries with my Moto G7 Play. **(Supports Android 8, 9, & 10)**
android-simg2img repo - https://github.com/anestisb/android-simg2img.git
A to AB Port Script -- wip
1. Copy both GSIs and tools.tar.gz to the root of your internal storage. Then rename your A only GSI to a.img and your AB GSI to ab.img. I believe a stock dump converted to a sparse image can also be used for this.
2. Download port_gsi.sh.txt and remove .txt from the name. Then place it in /data/local/tmp and set permissions on the file 0755.
3.Run the script and wait. You're moving gigs of data, so it will take several minutes. To do this with Termux, use the following commands.
Code:
su
cd /data/local/tmp
./port_gsi.sh
4. Once the script finishes check the root of your sdcard. Your new GSI will be named new_gsi.img. Install it with fastboot or twrp and cross your fingers.
Notes:
* I recommend that you have at least 12gb of storage available for this process. To get a rough estimate of how much space you actually need, add the size of both GSIs together then multiply by 3. For the images I tested, this comes out to around 10.8gb
* This will put selinux into permissive mode for the duration of the script. Selinux is returned to enforcing at the end of the script.
* The script has been optimized for storage space. It's also self cleaning. The script doesn't remove itself though. port_gsi.sh will be left in /data/local/tmp. You need to remove it manually. This was by design so I wouldn't have to keep copying it every time I want to run the script.
* In theory some small edits to the script would allow it to port AB to A, or a stock dump to an A or AB GSI.
* The arm binaries provided should also work for converting oem or vendor images between sparse and raw. Android 8, 9, & 10 are supported.
* If anyone can improve upon my work, please do! I'm grateful for any suggestions or ideas.
Tips and Tricks
Backup partitions to inactive slots...
Code:
su
dd if=/dev/block/by-name/oem_a of=/dev/block/by-name/oem_b
dd if=/dev/block/by-name/vendor_a of=/dev/block/by-name/vendor_b
dd if=/dev/block/by-name/system_a of=/dev/block/by-name/system_b
dd if=/dev/block/by-name/boot_a of=/dev/block/by-name/boot_b
How to mount and edit inactive partitions...
Code:
su
mkdir /mnt/a && chmod 0755 /mnt/a
mount -o loop /dev/block/by-name/system_b /mnt/a
Navigate to /mnt/a with a root explorer and make any changes you want. The changes will be permanent. To unmount simply back root explorer out of /mnt/a or any subfolders then run...
Code:
umount /mnt/a
This works on system, oem, and vendor partitions.
U r an inspiration. Great job! I think I was merely hours from jus walking into oncoming traffic over the frustration this A & B **** has given me for nearly two months. I probably bricked it 15 or more times EVERY SINGLE DAY trying all sorts of things with fastboot and ramdisk combo attacks. Never did better than achieving root shell thru adbd from PC and recovery. I tried every SuperSU zip I could find to try even to jus give magisk root to accomplish and that didn't work either. I have security updates thru Feb '20 and I have a suspicion it plays a part in this. Everything I've read on it when I'd give up for awhile all date six months or more and nothing y'all were doing then we worked much at all. It would but for very temporary....anyhow this is exactly direction we needed to go to fix this very unfriendly to developing trap they call A/B...This phone scrambled my eggs man. Anytime my phone reboots I have an anxiety attack
kapmino269 said:
Nice , good start .
I sugest to add more tools, like convert to dat and rhe opposite ( img2dat.py - dat2img.py ) and ither stuff .... scripts and make android kitchen tool which works on android , I got this idea 2 weeks ago but no time for me (NOW) .
Which I meant :
Tool u can use it like AIK magisk by @osm0sis , but with more better way , better way means to make it easy for user also us ex :
Script :
1- unpack
2- repack
3- convert
4- compress
5- etc...
User : 1
Script :
1- unpack img .
2- unpack squashfs img .
3- unpack (recovery / boot) img .
.....etc
Like that....
User : 1
Script :
Chose which one ?
1- s.img 2- v.img
If convert :
User : 3
Script :
1- convert img to (dat || dat.br) .
2- convert a img to ab img .
Etc .......
And so on ..... That will be very awesome , hope I can see it by u , if no luck np I will try to write scripts for that later .
Hope that my suggest will help u .
Click to expand...
Click to collapse
I get what you're saying. That's actually an awesome idea. I'll see what I can do!
Great guide, many thanks
Successfully made image of my system.. Located in /dev/block/mapper
Getting an error when trying to mount it though, wonder if you have seen it before?
I've got a Redmi Note 9s with dynamic partitioning
Code:
dd if=/dev/block/mapper/system of=systemmiui.img
4838824+0 records in
4838824+0 records out
2477477888 bytes (2.3 G) copied, 23.800180 s, 99 M/s
mkdir /mnt/miui11 && chmod 0755 /mnt/miui11
mount -o loop systemmiui.img /mnt/miui11
mount: '/dev/block/loop9'->'/mnt/miui11': Block device required
I did however manage to unpack and repack on pc.
... That alone has been a saviour with my device only having a closed sourcd twrp clone
Spaceminer said:
A to AB Port Script -- wip
1. Copy both GSIs and tools.tar.gz to the root of your internal storage. Then rename your A only GSI to a.img and your AB GSI to ab.img. I believe a stock dump converted to a sparse image can also be used for this.
2. Download port_gsi.sh.txt and remove .txt from the name. Then place it in /data/local/tmp and set permissions on the file 0755.
3.Run the script and wait. You're moving gigs of data, so it will take several minutes. To do this with Termux, use the following commands.
Code:
su
cd /data/local/tmp
./port_gsi.sh
4. Once the script finishes check the root of your sdcard. Your new GSI will be named new_gsi.img. Install it with fastboot or twrp and cross your fingers.
Notes:
* I recommend that you have at least 12gb of storage available for this process. To get a rough estimate of how much space you actually need, add the size of both GSIs together then multiply by 3. For the images I tested, this comes out to around 10.8gb
* This will put selinux into permissive mode for the duration of the script. Selinux is returned to enforcing at the end of the script.
* The script has been optimized for storage space. It's also self cleaning. The script doesn't remove itself though. port_gsi.sh will be left in /data/local/tmp. You need to remove it manually. This was by design so I wouldn't have to keep copying it every time I want to run the script.
* In theory some small edits to the script would allow it to port AB to A, or a stock dump to an A or AB GSI.
* The arm binaries provided should also work for converting oem or vendor images between sparse and raw. Android 8, 9, & 10 are supported.
* If anyone can improve upon my work, please do! I'm grateful for any suggestions or ideas.
Click to expand...
Click to collapse
thank you very much for your work,
so can i use this on a linux computer? and how ti use?
awesome,realy cool,thanx!!!
hello how to do the opposite. from A/B to A-only. I have an AB img and I want to convert it to A-only. Thanks
Spaceminer said:
I wanted a way to easily work on GSIs with my phone. These are the fruits of my labor.
Prerequisites:
* Magisk manager > settings > mount namespace mode > global
* Termux
How to dump, edit, and convert your stock OS into a GSI?
1. Using Termux run the following commands. This assumes you have root.
Code:
su
ls /dev/block/bootdevice/by-name
cd /data/local/tmp
For me system is labeled as system_a, so this is what we're going to use. This name may differ by device so it's always a good idea to check. Next command...
Code:
dd if=/dev/block/bootdevice/by-name/system_a of=/data/local/tmp/system.img
2. About 1-2min after running the previous command you'll have a raw system image in your tmp directory. Now we need to mount it like so...
Code:
mkdir /mnt/a && chmod 0755 /mnt/a
mount -o loop system.img /mnt/a
3. If everything went smoothly your raw image is now mounted at /mnt/a and visible with a root explorer. Not only that, it's also live! So any changes you make while it's mounted will be permanent. Simply make any edits as you see fit using a root explorer, then unmount the image when you're done like this...
Code:
umount /mnt/a
Tip: If you can't unmount due to device or resource busy, back out of /mnt/a or any subfolders with your root explorer. If the files are being accessed then you can't unmount them until you get out.
4. Now that the raw image we dumped into /data/local/tmp has been edited, we need to convert it into a sparse image for flashing. Download arm_img_binaries.zip. Extract the files and copy img2simg to /data/local/tmp and set permissions to 0755. From termux run the following commands...
Code:
./img2simg system.img name-of-gsi.img
cp /name-of-gsi.img /sdcard/name-of-gsi.img
You're done! Now just install it like any other GSI using twrp or fastboot.
To clean up everything simply run...
Code:
rm -rf /data/local/tmp/*
How to edit a GSI that's already in sparse format?
Again we're going to need our arm_img_binaries. This time copy simg2img to /data/local/tmp & chmod 0755 just like before. Copy your GSI to the same location then run...
Code:
./simg2img name-of-gsi.img system.img
From there, just follow the guide starting at step #2.
Sources & Tools used:
Termux: Clang, build-essential, git, and python for compiling arm versions of the needed binaries with my Moto G7 Play. **(Supports Android 8, 9, & 10)**
android-simg2img repo - https://github.com/anestisb/android-simg2img.git
Click to expand...
Click to collapse
hello how to do the opposite. from A / B to A-only. I have an AB img and I want to convert it to A-only
i'm trying to mount a gsi image but it says that requires -t option, what should i do?