Related
Hi all
I am new here, so, let me say a big Hello to all comunity. I am a developer for some programming languajes and just starting with android, hope I can write nice code to share here with all you.
My G1 is coming (hope get it in my hands next week) and the first I like to do is flash it with the new boot and modified RC30, but I like to have the original ones in a save place... maybe I need them one day.
But I have been reading the "Rooting, Hacking, and Flashing your G1/Dream" threat, the procedures are all clear like water, but still I have the doubt.... what is the way to save the original boot and Android built that comes with the phone?
Please, could anybody give me some help with this?
Thanks
The original /system /boot and /recovery are all restoreable with publicly available update files (you can even grab them direct from Google's https server), so don't worry about having to back up your own copy. If you absolutely must copy your own data, there are scripts out there to dump out your nand flash. Good luck and looking forward to seeing your code!
First, let me give you the thanks for your answer...
Nandroid is one of those scripts?
Believe I have been reading this forum for several days, but is hard to asimilate so much information, and more if that info isn´t writted on your native languaje...
I believe I understand that I must install a bootloader to use nandroid... and not sure if I can do it with the original android installed... I readed about the /system /boot and so on directories, but not sure if I can access them from the pc, and / or if those directories contains all you need to have the phone working, or if you need a boot sector or similar to get the phone booting...
Is possible the phone boots just reading the contents or the /boot directory, without a boot sector/master record??
Is hard to asimilate that for a windows os applications developer like me
Maybe you can show me the right thread to start, I think I must change my mind with that systems... I am a Delphi, C++ and so on developer for windows S.O, and now I like to introduce my own on Linux wordl too
Introduction
If you are rooted and running a Hard SPL or a Stock SPL and really want to flash a ROM that claims to require Danger/Haykuro SPL, but you do not want to upgrade your SPL there are alternative ways to make these ROMs work on your phone without upgrading your SPL.
This is a very easy process, Ive done it with a few ROMs with no problems:
First off, keep in mind that on a Stock SPL
/system = about 67MB
Any ROM that has a system partition 67MB or Greater will require Danger/Haykuro SPL, UNLESS you can shrink that ROM's /system down below 67MB.
How do you do this, you ask?
------------------------------------------------------------------------------------------------------------------------------------------------------
Method #1 (Easy) -Move/Delete unneeded Apps, Sounds, Files
------------------------------------------------------------------------------------------------------------------------------------------------------
NOTE: This Method does NOT apply to HERO/SENSE ROMs, they are way too big! Check Method 2 if you want to fit ANY ROM on any SPL (Advanced)
Make sure you have 7-Zip! Dont have it? Google is your friend!
1) Read the first post and changelog of the ROM you wish to install on your phone. After youve made yourself familiar with what needs to be Wiped (ie: dalvik cache, ext, data) the Partition Layout the developer suggests (ie: FAT32/Ext3/Swap), then go ahead and download the ROM. Unzip it to a folder, name it something short. for example: C:\1\rom
now click on the system folder, scroll down and click on the media folder, and delete the audio folder. This will erase every sound effect and ringtone on your phone and usually will free up about 2MB in system.
To get your ringtones and sounds back download this (thanks Robot Teapot!) and unzip the folder to the root of your sdcard. (note: your ringtones might not show up the first time you boot the rom, in this case, reboot and theyll all be right there)
If removing your ringtones isnt enough to keep /system under 67MB then move on to step 2), if youre already below 67MB skip to step 3)
2) Return to the first post and changelog of the ROM you are trying to install. Look for apps the dev has added to the ROM that dont seem necessary for the ROM to function such as Twidroid.apk, Facebook.apk, NeroMedia.apk, WirelessTether.apk, WiredTether.apk, Maps.apk(takes up a lot of room, and sometimes outdated...just delete it and install the latest from the market!)etc.
You can use Android Barebones/Necessary Apps - CyanogenMod Wiki as a general guideline to determine which apps are essential to Android running properly and the functions of many system apps.
Delete those unnecessary apps or move them to your sdcard, and use ASTRO File Manager or a similar app to install them after you flash the ROM.
3) Okay, assume youve trimmed /system down below 67MB, good job! now you need to get those folders you extracted and the boot.img zipped up and signed. select the folders from the ROM you extracted and modified, the boot.img, right click, and select 7-Zip < Add to .zip
4) Download Stericson's Autosign place it in any directory and follow the instructions in the thread to sign your zip file.
5) Move the signed zip to your SD Card, making sure you have the proper partitions, wipe the necessary things, then flash your zip file and cross your fingers!
------------------------------------------------------------------------------------------------------------------------------------------------------
Method #2 (Advanced) -"Cache Hack"
------------------------------------------------------------------------------------------------------------------------------------------------------
NOTE: This Method will fit any ROM on any SPL but is more advanced than Method 1
lbcoder introduced the concept of moving files to the /cache partition of the phone and linking them back to /system or /data.
Firerat has come up with a way to make this concept work and explains the whole process in his thread and shows some examples of his method by providing some ports:
[HACK][ROM][BOOT.IMG][CACHE]-Stk SPL ROMs with Danger SPL size & extra 30mb! any SPL!
------------------------------------------------------------------------------------------------------------------------------------------------------
There you have it folks! Congrats if youve bypassed the Danger SPL requirements! Be sure to always keep a Nandroid/BART backup!!!!
Disclaimer: Not saying these methods will brick or damage your phone, but in the rare event this occurs I am NOT responsible for bricks or or any damages to your phone!
Autosign doesnt need to be in the SDK place, I had it in my music folder and it worked fine.I accidentally formatted my PC last night and dont have the SDK installed but autosign works for me so im happy.
Note to OP-You cant brick from flashing any 32B rom, you would only get a blank screen that stays..which some seem to call soft-brick, i call it nonsense though.
Thanks for this excellent tutorial
Ace42 said:
Autosign doesnt need to be in the SDK place, I had it in my music folder and it worked fine.I accidentally formatted my PC last night and dont have the SDK installed but autosign works for me so im happy.
Note to OP-You cant brick from flashing any 32B rom, you would only get a blank screen that stays..which some seem to call soft-brick, i call it nonsense though.
Click to expand...
Click to collapse
Really? I had no idea that the SDK wasnt required, ill remove that.
and yeah i know its usually a soft brick, if anything, and youre right its nonsense, and can be solved using a nandroid backup and wiping the proper things, but im playing it safe with that disclaimer just like the rom devs do lol
migalito said:
Thanks for this excellent tutorial
Click to expand...
Click to collapse
.
Youre welcome! I hope it works out for you!
Will this work with the Super D rom?
cg87 said:
Will this work with the Super D rom?
Click to expand...
Click to collapse
yes! I tried it on Super D!
speedysilwady said:
yes! I tried it on Super D!
Click to expand...
Click to collapse
Then I'm so confused. If it's possible, why does the rom still require the Danger SPL? Why didn't bbuchacher make it so it doesn't require the Danger SPL? Doesn't make any sense to me. Can someone please enlighten me?
cg87 said:
Then I'm so confused. If it's possible, why does the rom still require the Danger SPL? Why didn't bbuchacher make it so it doesn't require the Danger SPL? Doesn't make any sense to me. Can someone please enlighten me?
Click to expand...
Click to collapse
Well, to be honest, im not sure why, but im assuming some developers like to include features and apps that arent necessarily required for the rom to run properly but to make their rom more appealing to users, than other roms. keeping those apps in system prevents those apps from disappearing after you wipe your phone/ext. Plus devs always keep ringtones and sounds included in their roms for completeness's sake.
Now a Hero ROM on the other hand is loaded with system apps that cant be deleted and i dont think theyll ever fit on a Stock SPL, except maybe MicroHero, but im not sure.
But for whatever reason, a lot of regular ROMs are fat and bloated with apps and extras that dont necessarily have to be saved on the system partition,so the best thing to do is shrink those roms down till they fit, if you can't or dont want to upgrade your SPL.
How to make it work *WITHOUT TRIMMING*
Take a look at your update.zip archive.
Probably has 4 things in the root:
boot.img
system
META-INF
data
If system is greater than about 67MB (or lets say 60 just to be real safe...), then create ANOTHER directory and call it "cache".
Now MOVE /system/app into /cache/
You now have the space cleared up, but it still won't work.
So go into META-INF/com/google/android and edit the script "update-script".
just below the line where it says "format CACHE:", add these lines:
copy_dir PACKAGE:cache CACHE:
set_perm_recursive 0 0 0755 0644 CACHE:
symlink /cache/app SYSTEM:app
Wow, did we just move the extra crap into cache? Yep.
May require slight modification. Use your head.
Seems someone else is in the same boat as I am.
Can't update my radio, looks like some kind of hardware problem almost. Tried everything in any possible way.
So it looks like we're stuck with the standard or engineering SPL, which is fine but means there are some restrictions.
I'll try some of the tips you gave and flash something besides Cyanogenmod tonight.
lbcoder said:
Take a look at your update.zip archive.
Probably has 4 things in the root:
boot.img
system
META-INF
data
If system is greater than about 67MB (or lets say 60 just to be real safe...), then create ANOTHER directory and call it "cache".
Now MOVE /system/app into /cache/
You now have the space cleared up, but it still won't work.
So go into META-INF/com/google/android and edit the script "update-script".
just below the line where it says "format CACHE:", add these lines:
copy_dir PACKAGE:cache CACHE:
set_perm_recursive 0 0 0755 0644 CACHE:
symlink /cache/app SYSTEM:app
Wow, did we just move the extra crap into cache? Yep.
May require slight modification. Use your head.
Click to expand...
Click to collapse
I thought about that but I'm not 2 good @ programing unless its cars/video console. But doesn't the cache get used for something after the rom is up and running? Or is it only for ota updates?
If only for ota updates how come the danger spl doesn't give you 120mb or so since cache and system are 67mb each
That's a very good question. Just tried it and it seems to work, though. It's booting as we speak. All system/app files in the cache directory.
EDIT: Actually, all apps seem to force close on boot. So I'll just try it the regular way I guess.
try the Fix apk uid mismatches maybe idk ill try it in a lil bit
*update*
Got a boot loop on openeclair1.0.1 not sure why but dont got the time to fig. it out right now.
also why does a boot loop drain the crap out of your battery?
lbcoder said:
Take a look at your update.zip archive.
Probably has 4 things in the root:
boot.img
system
META-INF
data
If system is greater than about 67MB (or lets say 60 just to be real safe...), then create ANOTHER directory and call it "cache".
Now MOVE /system/app into /cache/
You now have the space cleared up, but it still won't work.
So go into META-INF/com/google/android and edit the script "update-script".
just below the line where it says "format CACHE:", add these lines:
copy_dir PACKAGE:cache CACHE:
set_perm_recursive 0 0 0755 0644 CACHE:
symlink /cache/app SYSTEM:app
Wow, did we just move the extra crap into cache? Yep.
May require slight modification. Use your head.
Click to expand...
Click to collapse
I remember you suggested this a while back when I asked about eclair roms on stock spl, I'm guessing if you use this method and wipe, you'll have to reflash the rom because those system apps are gone, correct?
yea anytime you wipe you would have to reflash the rom because a wipe deletes. data and cache folder
Dr-b said:
That's a very good question. Just tried it and it seems to work, though. It's booting as we speak. All system/app files in the cache directory.
EDIT: Actually, all apps seem to force close on boot. So I'll just try it the regular way I guess.
Click to expand...
Click to collapse
Might be a minor goofup on the permissions. Just verify the permissions and it will be fine.
What programming?
There is no programming involved in this.
Mainly cache is for OTA, but also some other crap related to the download manager.
As for the deathspl allocation, it puts *some* of the /cache into /system, *some* of the /cache into /data, and the balance of /cache remains in /cache.
xile6 said:
I thought about that but I'm not 2 good @ programing unless its cars/video console. But doesn't the cache get used for something after the rom is up and running? Or is it only for ota updates?
If only for ota updates how come the danger spl doesn't give you 120mb or so since cache and system are 67mb each
Click to expand...
Click to collapse
speedysilwady said:
I remember you suggested this a while back when I asked about eclair roms on stock spl, I'm guessing if you use this method and wipe, you'll have to reflash the rom because those system apps are gone, correct?
Click to expand...
Click to collapse
Why would you want to wipe it?
Note: you could just create an update.zip with an update-script that says ONLY "format DATA:" That would wipe the data withOUT wiping the /cache. Maybe name it "betterwipe.zip" and put it on your sdcard. Boot into recovery and apply "betterwipe.zip".
lbcoder said:
Why would you want to wipe it?
Note: you could just create an update.zip with an update-script that says ONLY "format DATA:" That would wipe the data withOUT wiping the /cache. Maybe name it "betterwipe.zip" and put it on your sdcard. Boot into recovery and apply "betterwipe.zip".
Click to expand...
Click to collapse
true, with fix permissions, and wipe dalvik, there really isnt much use in wiping data anymore, but would fix permissions still work if the apps are in cache? i know theyre syslinked, but im not sure how that works with the fix_permissions script. sorry if im asking dumb questions, im still learning.
Ill try your idea a really big rom and see if it works.
just wanted to confirm that all Hero ROMs seem to require Danger SPL, I see no way of shrinking system anywhere close to 67 or less.
But my method should still work on any eclair or donut rom. I still havent had a chance to try lbcoder's method though it should work. if people can get lbcoders method to work ill add it to the first post!
I unlocked bootloader, flashed recovery, flashed root. Things looked almost sweet and colorful, but here suddenly appears ugly bug (or feature?)
It is not possible to write anything to /system partition.
Ok, not exactly "impossible". It is possible. You remount partition for rw access and can write files, delete files, rename files. You can do whatever you want. But once you reboot, all changes magically disappear.
Which is pretty cool on the one hand, since nothing can write to system even after getting root access.
On the other hand, even if I want to write there, I have to reboot into recovery for that.
Does anyone know how to change this behavior?
SamePaul said:
I unlocked bootloader, flashed recovery, flashed root. Things looked almost sweet and colorful, but here suddenly appears ugly bug (or feature?)
It is not possible to write anything to /system partition.
Ok, not exactly "impossible". It is possible. You remount partition for rw access and can write files, delete files, rename files. You can do whatever you want. But once you reboot, all changes magically disappear.
Which is pretty cool on the one hand, since nothing can write to system even after getting root access.
On the other hand, even if I want to write there, I have to reboot into recovery for that.
Does anyone know how to change this behavior?
Click to expand...
Click to collapse
You need to flash a kernel with /system write enabled. There are stock kernels in the Development section that will help you.
My thread and project are inactive now. Please accept my apologies for this inconvenience.
ast.ls
Blackout
ast.np
Blackout
ast.pm
Blackout
ast.ops
Blackout
ast.settings
Blackout
ast.storage
Blackout
2nd Feedback
Thanks for the dedicated thread. If I may, some more nitpicking about rudimentary things.
ast.install has hard coded file names of ast scripts, that's not very portable:
l_Scripts=( "ast.ls" "ast.np" "ast.pm" "ast.ops" "ast.settings" "ast.storage" "astcore" )
I have packages ( "ast.ls" "ast.net" "ast.pm" "ast.ops" "ast.set" "ast.sto" "astcore" )
so more generic pattern for handling like ast* may be considered. In case of renaming, ast.install could have a file renaming template (ast.rename) with say key value rows for generic renaming procedure before starting the actual transfer/installation. Another thing it could try to perform chmod 755 after installation.
EDIT: Looks like you have it but it doesn't work as system is read-only for say /system/xbin installation directory. So installation can be performed either by hand from a file manager with root access or TWRP recovery (install script for easy TWRP install may be a solution).
Do you have any comparative performance observations regarding background network access?
2a. The interesting are the influence of size of the blacklist on system/apps behaviour (fluency, speed, memory usage or possibly noticed negative consequences re some specific apps). By default whitelist contains less than a dozen of items, blacklist is empty. What packages would you consider safe to remove from the whitelist, like LG weather widget? Will 300 blacklisted items be completely practical to have?
2b. Battery consumption changes and practical benefits measured re having hundreds of packages blacklisted vs normally empty blacklist.
2c. I remember you mentioned a FW app you installing on the end of device restoration process, what functionality separate FW app provides for your use case, or is that just an app like AdAway?
hotcell said:
Thanks for the dedicated thread. If I may, some more nitpicking about rudimentary things.
ast.install has hard coded file names of ast scripts, that's not very portable:
l_Scripts=( "ast.ls" "ast.np" "ast.pm" "ast.ops" "ast.settings" "ast.storage" "astcore" )
I have packages ( "ast.ls" "ast.net" "ast.pm" "ast.ops" "ast.set" "ast.sto" "astcore" )
so more generic pattern for handling like ast* may be considered. In case of renaming, ast.install could have a file renaming template (ast.rename) with say key value rows for generic renaming procedure before starting the actual transfer/installation. Another thing it could try to perform chmod 755 after installation.
EDIT: Looks like you have it but it doesn't work as system is read-only for say /system/xbin installation directory. So installation can be performed either by hand from a file manager with root access or TWRP recovery (install script for easy TWRP install may be a solution).
Do you have any comparative performance observations regarding background network access?
2a. The interesting are the influence of size of the blacklist on system/apps behaviour (fluency, speed, memory usage or possibly noticed negative consequences re some specific apps). By default whitelist contains less than a dozen of items, blacklist is empty. What packages would you consider safe to remove from the whitelist, like LG weather widget? Will 300 blacklisted items be completely practical to have?
2b. Battery consumption changes and practical benefits measured re having hundreds of packages blacklisted vs normally empty blacklist.
2c. I remember you mentioned a FW app you installing on the end of device restoration process, what functionality separate FW app provides for your use case, or is that just an app like AdAway?
Click to expand...
Click to collapse
I "liked" your post because your nitpicking is only indication of your care and liking AST scripts, I respect that.
Now, onto addressing your 2nd phase of nitpicking, mildly jocking. As I mentioned previously, perhaps in Info Bank thread, once I get a question, in order not to repeat myself I would cover it, thoroughly, in its relevant post/tool. Please read post #3 for everything I could share on Netpolicy.
Naming issues: Please rename/copy ast.install to ast.setup or anything you wish then update the array list to your liking. This is a quick solution for anyone with the same issue. The beauty of AST is you can modify its scripts in any way you wish in a text editor, on any platforms. Please kindky, don't ask me and provide me with the solution when is not practical. I'm referring to your copying idea instead of hardcoded list of scripts. I know what I'm doing in this instance.
ast.install automatically mounts /system to 'rw' if it was 'ro'. If it was 'rw' already it never set it back to 'ro' to avoid causing problems to the process which set it to 'rw' before ast.install was executed. There are times, /system cannot be mounted as 'rw'. I can guess why, but don't wish go into details for now. A reboot often solves the problem. ast.install will show an error message if it fails but you didn't mention that in your post. So I have no idea what you have complained about at the end.
You have mentioned TWRP before as well. In order to avoid confusion to other users, AST has nothing to offer in TWRP and I don't know why you think it does. I have installed AST to /system/xbin on two LG V20 phones with the same script with no issues. If it is easier to do this manually please do by all means. When you mention installing AST from TWRP, you would give the wrong impression to users, as if AST is an overly complicated thing.
I don't have the time nor the patience to measure battery consumption. Battery consumption is very subjective, as you know. However, I would appreciate it if you like to share your future findings with the community in here.
I'm sorry, I don't recall what was exchanged in reference to 2.c.
Since I know you like AST, how about sharing something with the community about how it made things easier for you? That is a feedback too. No one would take my word for it because they think I'm on my way to become a millionaire.
3rd Feedback
xdav20 said:
I "liked" your post because your nitpicking is only indication of your care and liking AST scripts, I respect that..
Click to expand...
Click to collapse
I never do posts asking or hoping for likes. That would be rather strange assumption. Regarding your obviously negative connotation here, it would be more appropriate if you simply remove the "like" you made.
Now, onto addressing your 2nd phase of nitpicking, mildly jocking. As I mentioned previously, perhaps in Info Bank thread, once I get a question, in order not to repeat myself I would cover it, thoroughly, in its relevant post/tool. Please read post #3 for everything I could share on Netpolicy.
Click to expand...
Click to collapse
Thank you for more detailed explanation. I have to note that you added the explanations in your post #3 after I asked the relevant net policy questions. Either way, IMHO your statement "I think the performance loss or gain is debatable, totally dependant on how Android internally implemented it, and, frankly, this is something I don't wish to get heavily involved with. Please kindly, keep me out of future debates." is not very encouraging. To me it seems that you aren't interested in the discussion of benefits in performance or possible battery savings here, thus logically negating the major possible purpose of using your tool from users perspective. That's strange indeed, but I do respect your wish, so that's it.
Naming issues: Please rename/copy ast.install to ast.setup or anything you wish then update the array list to your liking. This is a quick solution for anyone with the same issue. The beauty of AST is you can modify its scripts in any way you wish in a text editor, on any platforms. Please kindky, don't ask me and provide me with the solution when is not practical. I'm referring to your copying idea instead of hardcoded list of scripts. I know what I'm doing in this instance.
Click to expand...
Click to collapse
Here you are contradicting yourself. As you previously mentioned, you made a deliberate effort to ensure any script can be renamed and still maintain its integrity thus boosting flexibility of usage even more. But here you are basically insisting such move would not be practical. In previous post I suggested you to maintain this flexibility by introducing renaming templates file, so updating the tool will be a simple seemless step/command, without manual intervention required, regardless of a chosen naming scheme. Well, again, it's your call. Perhaps you'd reconsider, just like you did with the inner AST folder in the distribution archive (Thanks BTW for that!).
ast.install automatically mounts /system to 'rw' if it was 'ro'. If it was 'rw' already it never set it back to 'ro' to avoid causing problems to the process which set it to 'rw' before ast.install was executed. There are times, /system cannot be mounted as 'rw'. I can guess why, but don't wish go into details for now. A reboot often solves the problem. ast.install will show an error message if it fails but you didn't mention that in your post. So I have no idea what you have complained about at the end.
Click to expand...
Click to collapse
Indeed I mentioned this due to failure to obtain the expected result on execution of ast.install. Note this script can't be run from ext SD card due to the obvious permission / media format issue. But, normally the /system is in RO state, so even if jackterm has required root permission, the ast.install still would fail when run from internal storage:
elsa:/storage/emulated/0/Download/ast #sh ast.install /system/xbin
cp: /system/xbin/ast.ls: Read-only file system
chmod: chmod '/system/xbin/ast.ls' to 100755: Read-only file system
cp: /system/xbin/ast.net: Read-only file system
chmod: chmod '/system/xbin/ast.net' to 100755: Read-only file system
cp: /system/xbin/ast.pm: Read-only file system
chmod: chmod '/system/xbin/ast.pm' to 100755: Read-only file system
cp: /system/xbin/ast.ops: Read-only file system
chmod: chmod '/system/xbin/ast.ops' to 100755: Read-only file system
cp: /system/xbin/ast.set: Read-only file system
chmod: chmod '/system/xbin/ast.set' to 100755: Read-only file system
cp: /system/xbin/ast.sto: Read-only file system
chmod: chmod '/system/xbin/ast.sto' to 100755: Read-only file system
cp: /system/xbin/astcore: Read-only file system
chmod: chmod '/system/xbin/astcore' to 100755: Read-only file system
I) ast.install: Installation completed.
elsa:/storage/emulated/0/Download/ast #
Why and how reboot supposed to resolve that?
EDIT: Looks like it works fine when performed right after reboot! It would be nice if install script would try to perform a mount, cp, chmod and report about the failure. Instead of showing the (fake) message "Installation completed." the hint to reboot and retry would be much more useful.
You have mentioned TWRP before as well. In order to avoid confusion to other users, AST has nothing to offer in TWRP and I don't know why you think it does. I have installed AST to /system/xbin on two LG V20 phones with the same script with no issues. If it is easier to do this manually please do by all means. When you mention installing AST from TWRP, you would give the wrong impression to users, as if AST is an overly complicated thing.
Click to expand...
Click to collapse
It has nothing to do with wrong impressions. All I tried to suggest was an attempt to provide a path to easy and working solution to install/update AST and have a workaround for system RO state issue as described above. One still will have to ensure the system partition is mounted in TWRP before doing AST install/update. Sure if ast.install or its exec environment can be fixed, there would be no need to reboot to recovery or perform manual steps with a file manager.
I don't have the time nor the patience to measure battery consumption. Battery consumption is very subjective, as you know. However, I would appreciate it if you like to share your future findings with the community in here.
Click to expand...
Click to collapse
If and when I'll proceed with net policy customisation and start to have some comarative data on battery consumption, I'll try to post here without involving you to the subject as per your wish to keep you out of future debates.
@hotcell
I have attached a modified version of ast.install that would double check if 'mount' command remounted /system rw or not. If the script still fails to copy your scripts, without displaying an error message, then, and previously, the problem has nothing to do with my script. I haven't developed 'mount' binary nor know why on your particular system things doesn't work normally. There is no 'fake' message, because of what happens the script assumes everything went well. If the scripts were previously copied to the target location, there is no easy way to know if the copy was successful or not. For such non-critical job, doing more is waste of time.
"ast.storage -lb online" displays the mounted partitions. The very last data is the current read/write status of the partition. After a reboot, could you run the above command to see what it prints about /system partition before and after running ast.install please.
I'm a tool maker, I'm not going to tell anyone where you can use my tool. I can provide guidance how the tool should be used, for productivity purposes only. What thing you have forgotten was, ast.np is a helper tool for Android Netpolicy tool. Without ast.np it is, literally, impossible to use it due to the input format it takes. Knowing how over analytical you can be, I made it clear I wish to stay away from any future debates myself. I have not stated, no one else can debate about it on my thread. I'm sorry, if you took my statement personally and I encourage you to use my thread to discuss anything related to AST. I would response, if I had to.
I thought for a while, how can I prove to @hotcell I wasn't being sarcastic when I "liked" his post? My proof is at the very end of that post when stated: "Since I know you like AST, how about sharing something with the community about how it made things easier for you?" If I didn't mean it, I wouldn't have stated a factual thing, I would had said; "If you like AST then why don't you...". Since I meant what I said without a menacing connotation, I stand by my previous decision. However, I do share your sentiment about the "like" system in place.
I have a serious issue with you or anyone else who think I have to accommodate to their specific needs in the same release that is meant for the public and no matter how accommodating I have been to you, you still have an approach that I don't feel comfortable with it. I will response equally to anyone who would want to dedicate terms to me. Once you renamed the scripts, I do not have to change the installer with your suggestion method, period. Have you thought, in the same directory users might have scripts or files starting with the "ast" prefix? That was the reason I hard-coded the script names to avoid potential disasters.
Edit: Noticed your edited comment about everything started working after a reboot. I do not like to discuss about something, specially in a public forum, when I do not have factual information. I'm normally good at observing patterns. I'm purely guessing, the reason behind the failure of mount command is to do with how certain file managers that support root handle mounting /system partition. Of course, there is always more than one reasons to such conditions.
Here is what you can do to see if that is the caase or not. Do everything as you would do after a reboot. Use the file managers you use and access the /system partition and copy something over to force the file manager to make the /system partition rw. Exit the file manager and then try the installer script again. Repeat the same thing, this time don't use the same file managers and after the system has been up and running for awhile, try the installer script again. What did you observe?
4th Feedback
Yes, you were right. After writing to the /system with MiXplorer file manager, the ast.install script fails. See screenshots: first made befre using MiX on /system, after that script worked; the second pic shows the ast.install.sh failure after using MiX, please note the (fake because of actual failure to mount and errors reported before) success report on the last line; the trird pic was made after the failed install. Also, with Root explorer, it asks to remount the system partition as R-W for operation, after that the ast.install(.sh) fails exactly as shown on the middle pic.
xdav20 said:
There is no 'fake' message, because of what happens the script assumes everything went well. If the scripts were previously copied to the target location, there is no easy way to know if the copy was successful or not.
Click to expand...
Click to collapse
The easiest way to know is probably to try to write an empty file into installation dir and check for its existance. Another way would be checking file timestamp.
I have a serious issue with you or anyone else who think I have to accommodate to their specific needs in the same release that is meant for the public and no matter how accommodating I have been to you, you still have an approach that I don't feel comfortable with it. I will response equally to anyone who would want to dedicate terms to me. Once you renamed the scripts, I do not have to change the installer with your suggestion method, period. Have you thought, in the same directory users might have scripts or files starting with the "ast" prefix? That was the reason I hard-coded the script names to avoid potential disasters.
Click to expand...
Click to collapse
Of course you don't have to accomodate or appease anyone. If maintaining renaming flexibility and extending that to install script is not you goal AST tool may benefit in terms of flexibility, just forget about this. And yes, I thought about ast prefix oversimplicity. That is the exact reason why I suggested ast.rename file template where one can explicitly define source-destination name pairs. So having a single fixed named file name for such template is all needed to avoid any possible clash.
hotcell said:
Yes, you were right. After writing to the /system with MiXplorer file manager, the ast.install script fails. See screenshots: first made befre using MiX on /system, after that script worked; the second pic shows the ast.install.sh failure after using MiX, please note the (fake because of actual failure to mount and errors reported before) success report on the last line; the trird pic was made after the failed install. Also, with Root explorer, it asks to remount the system partition as R-W for operation, after that the ast.install(.sh) fails exactly as shown on the middle pic.
The easiest way to know is probably to try to write an empty file into installation dir and check for its existance. Another way would be checking file timestamp.
Of course you don't have to accomodate or appease anyone. If maintaining renaming flexibility and extending that to install script is not you goal AST tool may benefit in terms of flexibility, just forget about this. And yes, I thought about ast prefix oversimplicity. That is the exact reason why I suggested ast.rename file template where one can explicitly define source-destination name pairs. So having a single fixed named file name for such template is all needed to avoid any possible clash.
Click to expand...
Click to collapse
Thank you for the quick response. Of course, if my script fails, so as everything else from command line. Now that we established my guess is an actual fact, I have another immediate concern.
Thanks to your screenshots, I have noticed storage.ast -lb command is not displaying the partition fs type and partition read&write status of /system and /userdata and there were errors. I installed Mixplorer and navigated to xbin and created a file. Went back to terminal and used ast.storage -lb online again and it reported everything correctly. You either have a corrupt fs table or there is a condition that I haven't seen before. To make sure, I would like to ask you to send me the following files by running these commands please:
Code:
cat /proc/mounts > mounts
cat /proc/self/mountinfo > mountinfo
cat /proc/self/mountstats > mountstats
Please make sure you have used Mixplorer or the usual things you do that may cause the problem first.
Edit: After a reboot, please run the ast.storage -lb online again and please report back if there were errors. I'm guessing if you do, there is something wrong on your end.
Disclaimer: At the time of publication of this article, I have not found a way to remedy the problem with the application mentioned in this article. If you did, please notify me to make the appropriate changes to this article.
This article came to existence after exchanging messages with @hotcell to which my further investigation revealed a problem with MIXplorer app. I understand MIXplorer has a thread on XDA so there is a chance the developer to be contacted to rectify the problem.
The problem is after /system partition is remounted 'rw' (Read & Write) MIXplorer does not set the partition back to 'ro' (Read-only) even after the application is closed explicitly. This can leave you extremely vulnerable in case a malicious app awaits for such opportunity. Fortunately, after a reboot all partitions will be set back to their default status. However, users might not reboot their phones for days.
Root Explorer from SpeedSoftware has a mount toggle (rw,ro) button for each partition you use which it gives you the control to change the status at will. Then I tested ES File Explorer, as soon as I closed the app the /system was remounted back to 'ro'.
Thanks to ast.storage -lb command I could easily tell what was going on. My advice to you is, to either contact the developer of MIXplorer and request the partitions to be remounted as 'ro' upon exiting the app or similarly to provide a toggle button. In the mean while, I wouldn't use MIXplorer on a device that is connected to the internet.
5th
@xdav20
Although irrelevant in the thread common context, please see the attachment below (as it looks like you disabled PM functionality).
I see your AST gives formatting errors, but practically I can't see any problems with my system. Also, looks like if /system left R-W mounted by a file manager or other app, AST has no way to proceed. As you noticed about re-mounting on-the-fly from UI, reboot can be avoided by remounting the /system as RO in Root Explorer. Also, another decent file manager X-plorer doesn't need an (clean) exit as it will re-mount the system as RO after FS operation finished.
hotcell said:
@xdav20
I see your AST gives formatting errors, but practically I can't see any problems with my system. Also, looks like if /system left R-W mounted by a file manager or other app, AST has no way to proceed..
Click to expand...
Click to collapse
Thank you for the files. I will start looking into them.
I have already stated, two posts up, ast.storage's -lb command works fine on my phone even with MIXplorer installed and /system remounted rw. While I'm trying to establish if your phone has a problem or not, I have to be here correcting your incorrect statement. Also, I'm wondering why you never reported the error messages before when you did about other things?
Edit: I have attached a screenshot to prove everything works. I deliberately set the /system to rw.
6th
xdav20 said:
Thank you for the files. I will start looking into them.
I have already stated, two posts up, ast.storage's -lb command works fine on my phone even with MIXplorer installed and /system remounted rw. While I'm trying to establish if your phone has a problem or not, I have to be here correcting your incorrect statement. Also, I'm wondering why you never reported the error messages before when you did about other things?
Click to expand...
Click to collapse
Perhaps my statement is incorrect, I've no idea. But how would you explain that after Root Explorer toggling to RO state ast.install works perfectly, what Root Explorer can do that ast.install can't?
For the last question there is an easy answer: When I reported about "fake installation success" clause, it was obvious the copy failed, screenshots were attached. Timing to report wasn't/isn't critical for me. Also, looks like you are using SuperSU while I've Magisk, maybe there are some diffs/settings related?
EDIT: After playing with renaming ast.net in /system/xbin via X-plore, Root Explorer and MiX more:
1. X-plore always know how to rename the file
2. Root Explorer knows and warns when in RO state, but fails to rename after subsequent renamings in other FMs. Toggling RW->RO>RW restores renaming capability.
3. MiX fails to rename first.
hotcell said:
Perhaps my statement is incorrect, I've no idea. But how would you explain that after Root Explorer toggling to RO state ast.install works perfectly, what Root Explorer can do that ast.install can't?
For the last question there is an easy answer: When I reported about "fake installation success" clause, it was obvious the copy failed, screenshots were attached. Timing to report wasn't/isn't critical for me. Also, looks like you are using SuperSU while I've Magisk, maybe there are some diffs/settings related?
EDIT: After playing with renaming ast.net in /system/xbin via X-plore, Root Explorer and MiX more:
1. X-plore always know how to rename the file
2. Root Explorer knows and warns when in RO state, but fails to rename after subsequent renamings in other FMs. Toggling RW->RO>RW restores renaming capability.
3. MiX fails to rename first.
Click to expand...
Click to collapse
Found the cause, I think I have the solution, and I have to leave to my dentist appointment soon. I will release a fix as soon as I can. There is nothing wrong with your device but with what you use that commonly cause problems to everyone else's (not literally) code. Thanks again for the files. The future fix will not fix the mount issue, mount issue is a common issue in Android because so many processes use /system partition and bound to be conflicts.
7th
xdav20 said:
Found the cause, I think I have the solution, and I have to leave to my dentist appointment soon. I will release a fix as soon as I can. There is nothing wrong with your device but with what you use that commonly cause problems to everyone else's (not literally) code. Thanks again for the files. The future fix will not fix the mount issue, mount issue is a common issue in Android because so many processes uses /system partition and bound to be conflicts.
Click to expand...
Click to collapse
Thanks, although I have no idea what you are going to fix (as it seems the issue is in mounting)
Anyway, I thought you can try to implement an algo like this:
1. check if /system looks mounted as RW, remember the state for later restoration, if not RW, try to re-mount
2. create am empty file named as current time in installation dir
3. try to check if it exists. if yes, delete it and set flag ready=true and proceed to #5.
4. if flag tried is not set (false), try to make double re-mount RW>RO>RW, set flag tried=true, return to #2.
5. if flag ready=false, return error message asking to either reboot or mount /system as RW and exit
6. if ast.rename is absent from install dir, perform scripts copy, otherwise the same with renaming according to the template
7. set chmod on script files as required. Done.
@hotcell
I have attached a pre-release version of AST to this post. This release contains support to handle multiple mountpints on online blocks. Android by default has one single mountpoint per block. However, components/su such as Magisk creates additional mountpoints, one on /dev/block/sda14 and two on /dev/block/sda18. AST can now handle multiple mountpoints on any online blocks, referring to -lb command. Thank you again for the files and your assistance in resolving this issue.
As you have guessed by now, Magisk was the cause of errors and I'm guessing the source of your /system mount issues. Now, that '-lb' command can show correct information on your device, you can keep your eyes on read and write status of both mountpoints on /dev/block/sda14. Please kindly provide a screenshot of '-lb online' so I can make sure everything was okay before releasing it on OP. Since you have installed AST in /system/xbin, please do not run anything locally without specifying its full parh in command line. I'm updating OP about this point shortly.
One minor matter, I have to respectfully ask you to refrain from referencing to AST scripts as your renamed versions. I got confused when you referenced ast.np to ast.net. For anyone following our conversations it can workout confusing too. At this point of time, I don't wish to make a rule and publish it on OP. I hope you can understand the point I raised. Thank you for your understanding.
Edit:01
Added two screenshots. Magisk-Partitions image shows the online partitions with Magisk being installed (based on your device data files) and Default-Partitions image shows a typical device without Magisk? Have you spotted the additional entries?
Hi all.
I'll make my apologies if this post is in the wrong place or against any rules, if so sorry for creating more work for the mods!
I dabble in Linux, so bear with me here. I am not a complete noob, but to some of you folks here, I am certainly in the gutter of the pecking order
So I got a cheap Amazon Kindle Fire 7" 2019 model, and thanks to this forum have used diplomatic's mtk-su tool to get superuser (su/root) on adb and Termux, which has allowed me to get rid of a lot of Amazon bloat and data collection, and system apps that just aren't useful, replace the launcher and generally make this tablet useable.
I have not, as of yet, installed a modified boot loader/twrp/magisk stuff. I am trying to avoid that route, as there is quite a chance of me messing up and I am destructive when trying to take things apart (maybe unplug battery required).
On to network interface security.
I've installed NetGuard, read a lot and understand the idea behind how it works. Dump unwanted traffic to a sinkhole VPN connection.
I would like to utilise iptables. After using mtk-su in termux, I can access and create rules and these apply instantly. All seems to work as expected, however, as we all know iptables rules are not persistent and a reboot clears them all out and replaces with the stock ruleset - which is a bit too open and has strange stuff in it.
Q:
Run a my_rules script on startup.
So I can write a .sh script with the iptables rules I want applied. It won't have root permission and won't run, but if executed at boot time by another script? ( .rc ) which does have permission to do root things, the script should run, rules be applied and I can be happy.
For one thing, I am not sure quite where to add my script. I have read somewhere that the .rc files I can see are actually created from a secure/encrypted/compressed store which is uncompressed at boot time. So editing an .rc file which is freshly created is pointless.
Secondly, I guess import <name of script -no.sh extension->? won't work, and will probably need service <name of script> and oneshot or another command.
Am I going to have to go the twrp/magisk route? Do I really need to make changes to more than I can access with root and a terminal on the running device?
Thank you for your time and patience to read this post.
I am obviously not reading enough!
It seems the /system/ folder is all read-only. I can't even "cp /system/bin/install-recovery.sh /system/bin/install-recovery_bak.sh" to back up the existing.
Will try mounting /system as rw, maybe.
*edit*
OK, a major problem is that /system is not writable. mount -o remount,rw /system or /dev/block/dm-0 looks like it works but the location still cannot accept new files created or changes to existing files.
There seems to be a watchdog or something running which prevents changes to the mounting here.
So, I conclude this is what people mean by rooting - booting a modified system which allows access to these such places. Having su in a terminal /adb is all great, but still can't do everything - opens up the opportunity of going further and changing boot loader, twrp and magisk though.
Sigh, I was hoping to avoid that path.
I can, at least, launch a small shell script which would leverage mtk-su to run and write my iptables rules into the running system. But this would be a manual exercise and I am bound to forget to apply it.
If mods wish to delete this thread, I have no objection. but maybe it might help someone else in my situation to understand a little more or maybe not.
I think I am showing how much of a noob I am here. Sorry.