Database Info

[APP] AFV File Verifier for Android™

Introducing the AFV File Verifier for Android™ app, now available (free) in the Market (search for "AFV"; QR code and screenshots are also below in the attached thumbnails).
The AFV File Verifier for Android™ application is a tool for helping to verify and validate that files transferred to your Android device are whole and uncorrupted.
Developers are welcome and encouraged to include this app in their custom ROMs to assist end-users with checking the completeness and validation of their (your ) downloaded custom ROMs.
The AFV File Verifier for Android™ app does this by offering:
- MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 checksum calculation
- "jarsigner -verify"-type validation of signed jar-type files (.jar, .apk, .zip files)
- Nandroid backup directory verification via "md5sum -c"-type functionality
These functions are particularly useful for root users who want to verify/validate that their custom ROMs, themes, and installable .zip files are whole and uncorrupted. However, this app does not require that you be rooted and can also be useful for checking the validity of other non-root files such as application .apk files.
Features
- Includes function to calculate an MD5 or SHA1 checksum for a selected file
* Useful to verify completeness and integrity of files transferred to your Android device
* File size is also displayed
* Calculated checksum is copied to clipboard
- Includes function to perform jar file verification of signed jar-type files (true .jar files, .apk files, signed .zip files such as ROMs, installable .zips, etc.) via 'jarsigner -verify'-type functionality. This function will verify the SHA1 checksums of each file listed in the signed jar file's META-INF/MANIFEST.MF file.
- Includes function to verify Nandroid backup directories via "md5sum -c" type functionality. You navigate to the Nandroid backup directory that you'd like to check, long-press the nandroid.md5 file, and select the Verify Nandroid Backup option. The function will then calculate and verify the MD5 checksums of each file listed in the nandroid.md5 file against the files in the Nandroid backup directory. Additionally, I've added some special name audits for Nandroid backup directories to point-out any issues you might encounter should you attempt to restore a mis-named Nandroid backup.
How to use
- From main / home screen, press the "Select File" button to enter the file-selector
- Top row (folder icon with the green up arrow) always displays the currently selected directory (touch this row to navigate UP one directory level)
- Back key can also be used to navigate UP one directory level (will return to main screen when pressing back key at root directory)
- Navigate to other subdirectories by touching a directory row (folder icon)
- Touch screen and drag up and down to scroll through all files and directories in currently selected directory
- Long-press on a file to view the available functions:
* Calc MD5 Checksum
* Calc SHA1 Checksum
* Verify Jar-type file
* Verify Nandroid Backup (long-press nandroid.md5 file to use this function)
* Calc SHA224 Checksum
* Calc SHA256 Checksum
* Calc SHA384 Checksum
* Calc SHA512 Checksum
Miscellaneous
Works for any Android version 1.5 or higher; has been tested on:
* Motorola Droid X (v2.1, v2.2)
* Motorola Cliq (v1.5)
* HTC Droid Eris (v2.1)
* Samsung Epic 4G (v2.1)
Menu items supported (main screen only):
* Help
* Acknowledgements
* Change Log
* Filtering options (no filtering or show only zip/jar/apk/img-type files)
* Jar Verify options (normal / fast mode or beta / explicit SHA1 calculation mode)
* Current settings
* Exit App
More app details (additional screenshots, etc.) can be found here: https://sites.google.com/site/scaryalienware
Acknowledgements
- jcase at XDA for allowing me to view an example project co-authored w/eclips3 and for the starter MD5 Java code
- XDA's bftb0 (Android Forums' erisuser1) for his encouragement, review, feedback and suggestions for helping me improve this app
- AF and XDA doogald for his very helpful reviews, feedback, and continued support
- Robert W. Harder for his Base64 encoding/decoding classes (http://iharder.sourceforge.net/current/index.html)
Related threads:
- Verify your File's MD5 Checksums!
- On-phone ROM Checksum Verifier
- Devs - Please publish you MD5's - XDA
Please check out the app and let me know if you have any problems, questions, or comments. Cheers!
Change Log
[version 2.3 - 11-Jan-2014]:
- fix issue w/verifying TWRP Nandroid backups [thanks to Marc M. for the kind heads-up re. this]
[version 2.2 - 09-Nov-2013]:
- fix force-close (FC) issues for some devices (Google added new external storage read permission requirement in 4.1 and higher)
[apologies for the delay in fixing]
[version 2.1 - 24-Feb-2013]:
- support auto-verification of MD5 checksum in *.tar.md5 files (thanks for Mike D. for this excellent suggestion)
- better recognize .md5 file entries formatted by other md5sum utilities (i.e., other than busybox md5sum applet)
[version 2.0 - 18-Jul-2012]:
- support Nandroid backup verification for Team Win Recovery Project (TWRP) custom recoveries
- moved two checksum comparison options to the main screen from the menu
- several other minor tweaks and enhancements
[version 1.9 - 26-Jun-2012]:
- minor update to fix crash when non-.md5 file is selected for a Nandroid verification
[version 1.9 - 23-Jun-2012 Android 2.3 and up]:
- support .md5 files w/spaces in file names in 'Verify Nandroid Backup' and 'md5sum -c Type Check' functions
[version 1.8 - 21-Jan-2012 Android 2.3 and up]:
- better display support for tablets and other phone screen densities
- can now also invoke Verify Nandroid Backup function by long-pressing Nandroid backup directory name
- support orientation changes (previous orientation locks have been removed)
- display full information in landscape mode just is done in portrait mode
[version 1.7 - 12-May-2011]:
- display file size after file name in file selector (with menu option to disable)
- add 'Return to Main' menu option in file selector (so you don't have to hit back key)
- tighten-up Nandroid-verification function so that non-'nandroid.md5' files do not cause FCs [note/reminder: the 'Nandroid Verify' function is done against the nandroid.md5 file in your Nandroid backup's directory]
- revise/enhance results pop-up display for the Nandroid Verify function
[version 1.6 - 02-May-2011]:
- thanks to all who have donated or purchased the donate version (very much appreciated!)
- fix FC issue when null/empty URI is received via Send function (please contact me if you experience an FC or other issue)
- several other minor fixes
- dynamically identify external storage directory instead of hardcoding /sdcard
- make pop-up dialogs cancelable via back button
[version 1.5 - 11-Apr-2011]:
- fixed FC issue when last remembered directory is no longer present (renamed / deleted) and
app is re-launched (thanks to Michael C. for bringing this to my attention)
[version 1.4 - 7-Apr-2011]:
- display elapsed time for long-running operations
- allow app to be invoked from other applications (tested with Astro File Manager, Estrongs File Explorer, OI File Manager)
- added donate button (donate version of app will be published soon)
- added 'md5sum -c Type Check' function for .md5 files (equivalent to 'Verify Nandroid Backup') to make it clear that functionality exists for non-Nandroid .md5 files too
[version 1.3 - 2-Feb-2011]:
- now supports SHA-224, SHA-256, SHA-384, and SHA-512 digest/checksum calculation
- display checksum results in a pop-up to ensure viewing checksum results on all phones
- keep screen on while progress-bar is displayed in long-running calculations
- directory name is now remembered from last file selection
- added help menu function for file selection screen
[version 1.2 - 23-Jan-2011]:
- supported standard preferences / settings menu instead of individual menu items
- added SD card mounted check before allowing file selection
- added two methods for comparing MD5 or SHA1 checksums:
* auto-comparison of calculated checksums w/menu option to display comparison results
* manual input of checksum (or paste from clipboard) value to be compared w/next calculated checksum
- changed default sort order of file / directory names to ignore case
- added option to toggle ignoring of case when sorting file / directory names
- force all screens to portrait orientation to fix/prevent FCs (future version will handle orientation changes correctly)
[version 1.1 - 10-Nov-2010]:
- re-instituted checksum clipboard copy lost due to prior UI revamp
- locked orientation of main screen to portrait so checksum results are displayed on all phones (both issues kindly reported by AF's starflorida)
[version 1.0 - 25-Oct-2010]:
- initial Android Market release

nice work....
pls post apk files here thx man

Wonderful dude... this helps a lot for frequent "flashers"

androgiallo said:
nice work....
pls post apk files here thx man
Click to expand...
Click to collapse
androgiallo, you are very welcome! I've got some minor tweaks that I'm working on, so I'm hoping to keep using the Market's ability to let people know about updates (it got a little cumbersome w/publishing the older versions of the app in different threads, etc., lol).
Neo.Collin said:
Wonderful dude... this helps a lot for frequent "flashers"
Click to expand...
Click to collapse
Neo.Collin, thank you for the kinds words and feedback--I very much appreciate it. I know there's a lot of frequent flashers D) out that should be checking their downloaded ROMs and such...peace of mind, you know?
Please let me know if you have any suggestions and/or ideas for future improvements. Thanks!

v1.2 just uploaded to the Market
All,
Been awhile since I've updated this app and it was long overdue. Mostly minor fixes and updates. No real core functions changed other than upgrade the early (noobie-coded ) menu settings to the more professional and standard preferences and settings menu.
I've also made some changes that should eliminate any FCs you were getting (most related to orientation changes, I believe). I'll get the orientation handling properly done in a future version.
If you get any FCs, please email me at [email protected] and let me know the circumstances so I can make a fix (the crash reports don't often tell the whole story).
Here's the change log for v1.2:
version 1.2 - 23-Jan-2011:
- supported standard preferences / settings menu instead of individual menu items
- added SD card mounted check before allowing file selection
- added two methods for comparing MD5 or SHA1 checksums:
* auto-comparison of calculated checksums w/menu option to display comparison results
* manual input of checksum (or paste from clipboard) value to be compared w/next calculated checksum
- changed default sort order of file / directory names to ignore case
- added option to toggle ignoring of case when sorting file / directory names
- force all screens to portrait orientation to fix/prevent FCs (future version will handle orientation changes correctly)
Thanks again for using my app and for your support. As always, email me or post-up here for any comments, questions, issues, or suggestions.
Cheers!

Hey, great app. Not sure if I missed this feature, but it would be cool to copy paste a md5 before your app verifies the selected file, and simply says if it matches or not

titans808 said:
Hey, great app. Not sure if I missed this feature, but it would be cool to copy paste a md5 before your app verifies the selected file, and simply says if it matches or not
Click to expand...
Click to collapse
You are most welcome, thank you for the comments.
As a matter of fact, you can do this in this (new v1.2) version:
1. Press menu key
2. Select Preferences / Settings
3. Select Input Checksum (in the MD5 / SHA1 Comparison middle section)
4. Type (lol) or (more likely ) paste the checksum to be compared
5. Press back key to return to the main screen
6. Select your file and long-press the filename and select the appropriate checksum operation
7. After the checksum is computed, you'll get a pop-up indicating the status of the comparison of the newly-calculated checksum with the one you inputted in the menu
You can also check the Display Comparison Info checkbox to have the app display a pop-up message regarding the checksum comparison of the last two MD5 or SHA1 checksum comparisons that you perform. This would be helpful for checking two file successively.
Cheers and thanks again!

No, thank you, you did a great job of making a multifunctional app. Job well done
Sent from my ADR6300 using XDA App

v1.3 just published to the Market
All,
Just released version 1.3 to the Market. Nothing major--just some more things on the to-do list that I finally figured-out how to do.
version 1.3 - 2-Feb-2011:
- now supports SHA-224, SHA-256, SHA-384, and SHA-512 digest/checksum algorithms (along with the MD5 and SHA1 algorithms, these appear to be all functions that the MessageDigest API supports)
- will now also display checksum results in a pop-up to ensure viewing checksum results on all phones
- keep screen on while progress-bar is displayed in long-running calculations
- directory name is now remembered from last file selection
- added help menu function for file selection screen
Thanks and hope these changes are useful.
Cheers!

v1.4 of AFV (Android File Verifier) just uploaded
All,
I just uploaded my newest version of AFV to the Android Market.
Been working on this one for a while (sorry it took so long ).
Thanks again to bftb0 for suggesting the "launch / send" from other apps idea .
Hope you enjoy it!
Here's the change log:
version 1.4 - 7-Apr-2011:
- display elapsed time for long-running operations
- allow app to be invoked from other applications (tested with Astro File Manager, Estrongs File Explorer, OI File Manager); use the "Send" function
- added donate button (donate version of app will be published soon)
- added 'md5sum -c Type Check' function for .md5 files (equivalent to 'Verify Nandroid Backup') to make it clear that functionality exists for non-Nandroid
.md5 files too

AFV (Android File Verifier) v1.6 just published to the Market.
Change logs for v1.6 and v1.5:
[version 1.6 - 02-May-2011]:
- thanks to all who have donated or purchased the donate version (very much appreciated!)
- fix FC issue when null/empty URI is received via Send function (please contact me if you experience an FC or other issue)
- several other minor fixes
- dynamically identify external storage directory instead of hardcoding /sdcard
- make pop-up dialogs cancelable via back button
[version 1.5 - 11-Apr-2011]:
- fixed FC issue when last remembered directory is no longer present (renamed / deleted) and app is re-launched (thanks to Michael C. for bringing this to my attention)

Cool App
@scary alien : Cool app
Given you an award here
http://www.techofweb.com/google/verifying-android-files.html

techofweb said:
@scary alien : Cool app
Given you an award here
http://www.techofweb.com/google/verifying-android-files.html
Click to expand...
Click to collapse
Thank you very much!
I do very much appreciate the very nice article and your kind words.
Cheers!

version 1.7 just published
Change log (hope you enjoy!):
[version 1.7 - 12-May-2011]:
- display file size after file name in file selector (with menu option to disable)
- add 'Return to Main' menu option in file selector (so you don't have to hit back key)
- tighten-up Nandroid-verification function so that non-'nandroid.md5' files do not cause FCs [ note/reminder: the 'Nandroid Verify' function is done against the nandroid.md5 file in your Nandroid backup's directory
- revise/enhance results pop-up display for the Nandroid Verify function

Can I just say that I love your app, but I was a little disappointed that you don't post your apk anywhere. I was trying to help a user troubleshoot an issue on the CyanogenMod forums with not being able to get the Play Store installed, by verifying the md5sum of his ROM and gapps zips. I wanted to just send him to this thread to download the apk so he could manually install it, but it is nowhere to be found (including your google site page). Would you consider adding it as an attachment to this thread for those times that people can't get on the Play Store and need to use the app?

bassmadrigal said:
Can I just say that I love your app, but I was a little disappointed that you don't post your apk anywhere. I was trying to help a user troubleshoot an issue on the CyanogenMod forums with not being able to get the Play Store installed, by verifying the md5sum of his ROM and gapps zips. I wanted to just send him to this thread to download the apk so he could manually install it, but it is nowhere to be found (including your google site page). Would you consider adding it as an attachment to this thread for those times that people can't get on the Play Store and need to use the app?
Click to expand...
Click to collapse
Excellent suggestion, bassmadrigal and thank you for the kind words .
I've updated the OP with the v2.0b version that's currently available on the Play Market.
I'm actually up late working on a tweak to the app that will support the auto-verification of MD5 checksums in .tar.md5 files from a I request I received Wednesday. I hope to have this new version posted (and the OP updated) in a few days.
I'll also upload the Legacy version of the .apk here in a few minutes for those on older versions of Android.
Cheers and thank you again!
-SA

Version 2.1 just released
Just updated Play Store (and OP of this thread) with new v2.1 version.
Enjoy!
Thanks,
-SA
Change log:
[version 2.1 - 24-Feb-2013]:
- support auto-verification of MD5 checksum in *.tar.md5 files (thanks for Mike D. for this excellent suggestion)
- better recognize .md5 file entries formatted by other md5sum utilities (i.e., other than busybox md5sum applet)

I would really like to see a push for the sha-2 algorithm instead of md5 since its is subject to attack and they have found to create two files with same checksum ( https://en.wikipedia.org/wiki/MD5 ).
I am uncertain as to why the push for sha-2 checksum in the android community has not been taken up, instead of we rely on an 18 yr old algorithm that is subject to attack.

I think the main gist of publishing a MD5 and SHA1 digests for a file is not strictly for security or secrecy reasons but rather as one means of providing a way to help verify / validate the integrity of a downloaded file.
Certainly using a less vulnerable, stronger, more robust checksum is always desirable, MD5 and SHA1 sums are probably here to stay for a while (although I must admit to remembering the widespread use of CRC-16 and -32 in the not-too-distance past (well in the '80's anyways )).
Also, being aware of the file's known / expected size and the download source's author is helpful in vetting it's pedigree and authenticity.
Caveat emptor, etc. .

Great app...

[TOOL]RK29kitchen - firmware customizer for Linux and rk2918 based tablets

This package is designed to automate operations firmware update for the devices based on processor RK2918.
Important!
Use of this software package can cause damage to your device!
This software package is supplied "as is" and without warranty.
This software package may not meet your expectations.
ONLY FOR LINUX (and other *nix like OS)
You can:
- Unpack the firmware file consisting of one kind update.img (img mode, used RKBatchTool)
- Unpack the firmware file consisting of a set RK29xxLoader.bin Image/boot.img Image/system.img etc (Image mode, used RKTool)
- Change the name of the device and partition sizes (parameter file)
- Install su and superuser (root access)
- Install busybox in /system/xbin and create symlinks for the utilities that comes with busybox
- Choose and install/uninstall some system applications
- Change the file size system.img
- Create update.img
also
- Create their own plug-ins
- Create automated scripts based on an existing plugin library
- Modify the list of proposed system applications
- Plug-in to remove files from the "black list"
- some build.prop fixes
and
- dump current flash from device
Notes
The package runs on Linux operating systems (development and testing on OpenSUSE 11.4/12.2)
The user interface is implemented using utilities 'dialog'
Binary utilities (directory bin) can be compiled using:
# cd src /
# make && make install
Dependences: libusb-1.0, libusb-1.0-devel, libssl, libssl-devel, dialog, sudo, gcc
To work actively used sudo (you can set up password-less mode) - need to modify the partition 'system'
Use:
[full_or_partial_path/]menu.sh [workdir]
[full_or_partial_path/]batchImgRepack.sh [full_or_partial_path/]old.img
[full_or_partial_path/]batchImageRepack.sh [full_or_partial_path_to_Image]
flashdump
workdir may contain update.img (img mode) or set of files (Image mode)
Homepage
Latest version
Updates:
not use sudo if run as root
src/update.sh - update sources for used tools (start make && make install after update)

[App] [2.3+] OTA Verifier

Whenever there's an over-the-air (OTA) update sent-out or made available (either leaked or official), there's always a large number of users that end-up reporting that their installations have failed with the infamous and dreaded "E:Error in /sdcard/xxx.zip (Status 7) installation aborted." error message. So, I decided to try to write an app that would help folks figure-out what the issues might be so that they can get their OTA update installed.
The OTA Verifier app can be used to evaluate an over-the-air (OTA) update.zip or other flashable .zip file before you attempt the install or afterwards to help you figure-out why the installation may have failed. OTA Verifier will point-out what files and conditions are being tested so that you can more easily attempt to correct these issues.
Play Market Link (free!): OTA Verifier (beta)
Do I have to be rooted to use this?
No, but rooted devices will have more conditions that the app will be able to test/evalute because it will have access to protected files that non-rooted devices don't.
Will the app actually do the installation or change anything on my device?
No. The app will only evaluate the expressions and conditions contained inside the updater-script file inside the .zip file that's trying to be installed. None of the functions or commands that try to modify your device (i.e., delete/patch/format/extract, etc.) will be evaluated or executed. The app basically operates in "read-only" mode with respect to the .zip file being evaluated.
Will this app work on older devices or flashable .zip files that use the amend update-script files?
No, this app evaluates and interprets the newer edify updater-script files (notice the "r" in "updater").
How do I use this app?
Install and launch the app
Click the "Select File" button and navigate to desired .zip file
Long-press (press and hold) the file entry for the desired .zip file
Click the "Verify OTA .zip" file pop-up
Wait for the app to process the file (should take under a minute, depending on your device)
View the displayed results (text will also be copied to the clipboard)
Miscellaneous info:
1. Savvy root users probably already know that after a failed .zip file installation, you should be able to view the /cache/recovery/log file to view the information about what might have failed. OTA Verifier will try to uncover all of the issues and not just the first one that causes the installation to fail.
2. While I wrote this app principally to evaluate OTA update.zip files, the edify updater-script files are used and written by ROM devs and others who created flashable .zip files. This app can be used to evaluate those file's updater-script files, too.
How does this all work?
Here's the basic outline/structure of what the app does:
1. the .zip file is selected by the user via the file selector
2. list of frozen system apps are identified for later reporting
3. the updater-script file is extracted from the META-INF/com/google/android folder in the .zip file
4. this updater-script file is parsed and converted into reverse polish notation (RPN) for execution
5. edify functions that might modify your device are NOT evaluated; these include apply_patch, delete, delete_recursive, format, mount, package_extract_dir/file, run_program, set_perm[_recursive], symlink, unmount, write_raw_image, etc.
6. note: the update-binary executable is not used by or involved in this app; the edify script interpreter that the app uses was written by me, in Java, specifically for this app
7. the remaining edify script functions that test conditions (such as apply_patch_check, apply_patch_space, assert, concat, file_exists, file_getprop, getprop, greater_than_int, if-then-else-endif, ifelse, is_substring, less_than_int, read_file, ui_print, and various operators (!, !=, &&, (, ), ;, ||, +, ==)) are evaluated using an operand/operator stack from the RPN expression parsed from the updater-script statements
8. expressions that fail (return a null-string) or are bypassed (usually because a resource (file/partition) is protected/secured against read-access) are reported for the user
9. after the entire script has been processed, the results are displayed in a pop-up window on the device and the text of those results are copied to the clipboard
Planned / future features:
- preferences / settings
- logging of the output to a file on the /sdcard
- test if .zip file is signed or not
- display more stats
- "explanation mode" to interpret, in English, what the edify commands are testing
Successfully tested on:
Samsung Galaxy Nexus (CDMA) 4.1.1
Samsung Galaxy Nexus (GSM) 4.1.2
Asus Nexus 7 tablet 4.1.2
Motorola Droid X 2.3.4
The following edify commands/functions/operators are supported:
Code:
[COLOR="blue"]apply_patch_check[/COLOR] // apply_patch_check ( <filepath>, <sha1-checksum> [ , <sha1-checksum> ... ] )
// apply_patch_check ( <compoundvalue> )
<compoundvalue> := [ EMMC : <filepath> : <sha1-size> : <sha1-checksum> [ <sha1-size> : <sha1-checksum> ... ]
[ MTD : <dev-block> : <sha1-size> : <sha1-checksum> [ <sha1-size> : <sha1-checksum> ... ]
[ vfat : <dev-block> : <sha1-size> : <sha1-checksum> [ <sha1-size> : <sha1-checksum> ... ]
<dev-block> := filename in /dev/block
[COLOR="Blue"]apply_patch_space[/COLOR] // apply_patch_space ( <bytes> )
[COLOR="blue"]assert[/COLOR] // assert ( <expression> )
[COLOR="blue"]concat[/COLOR] // conact ( <string> , <string> )
[COLOR="blue"]file_exists[/COLOR] // file_exists ( <filepath> )
[COLOR="blue"]file_getprop[/COLOR] // file_getprop ( <filepath>, <propertyname> )
[COLOR="blue"]getprop[/COLOR] // getprop ( <propertyname> )
[COLOR="blue"]greater_than_int[/COLOR] // greater_than_int ( <integer>, <integer> )
[COLOR="blue"]if then else endif[/COLOR] // if <condition> then <expression> [ else <expression> ] endif
[COLOR="blue"]ifelse[/COLOR] // ifelse ( <condition>, <then-expression> [ <else-expression> ] )
[COLOR="blue"]is_substring[/COLOR] // is_substring ( <string> , <string> )
[COLOR="blue"]less_than_int[/COLOR] // less_than_int ( <integer>, <integer> )
[COLOR="blue"]read_file[/COLOR] // read_file ( <filepath> )
[COLOR="blue"]ui_print[/COLOR] // ui_print ( <string> ) parsed & executed, but output not displayed
[COLOR="blue"]![/COLOR] // logical NOT operator
[COLOR="blue"]!=[/COLOR] // not equals operator
[COLOR="blue"]&&[/COLOR] // logical AND operator
[COLOR="blue"]([/COLOR] // open paren: precedence / grouping
[COLOR="blue"])[/COLOR] // close paren: precedence / grouping
[COLOR="blue"];[/COLOR] // sequence/imperative (terminates & separates statements)
[COLOR="blue"]||[/COLOR] // logical OR operator
[COLOR="blue"]+[/COLOR] // string concatenation operator
[COLOR="blue"]==[/COLOR] // equals operator
[COLOR="blue"]#[/COLOR] // comment line
The following edify functions are NOT supported (the majority of them because they are intended to modify your device):
Code:
[COLOR="blue"]apply_patch[/COLOR]
[COLOR="blue"]delete[/COLOR]
[COLOR="blue"]delete_recursive[/COLOR]
[COLOR="blue"]format[/COLOR]
[COLOR="blue"]mount[/COLOR]
[COLOR="blue"]package_extract_dir[/COLOR]
[COLOR="blue"]package_extract_file[/COLOR]
[COLOR="blue"]run_program[/COLOR]
[COLOR="blue"]set_perm[/COLOR]
[COLOR="blue"]set_perm_recursive[/COLOR]
[COLOR="blue"]symlink[/COLOR]
[COLOR="blue"]unmount[/COLOR]
[COLOR="blue"]write_raw_image[/COLOR]
[COLOR="blue"]is_mounted[/COLOR] // innocuous, but still not supported
[COLOR="blue"]stdout[/COLOR] // innocuous, but still not supported
[COLOR="blue"]show_progress[/COLOR] // innocuous, but still not supported
[COLOR="blue"]set_progress[/COLOR] // innocuous, but still not supported
Keywords:
OTA, over-the-air, updater-script, edify, amend
Screenshots:
updated 9-May-2014

updated to version 1.3
Updated app with root-enabled file browser for navigating to protected/secured directories like /cache to select OTA's update zip file.
Full change log to date:
[v1.3 - 04-Nov-2012]:
- for rooted devices, change file browser to allow navigating and selecting .zip files in protected directories (like /cache)
[v1.2 - 29-Oct-2012]:
- minor fix to handle two reports of null pointer exceptions
[v1.1 - 28-Oct-2012]:
- remove unused SD card write permission
[v1.0 - 28-Oct-2012]:
- initial Play Market release

This is pretty cool.
Any chance you could direct me to an explanation for sha1-size (for apply_patch_check) is though? I'm working on some edify scripting stuff and trying to incorporate some asserts for a specific bootloader (important to what I'm doing), and this is honestly the best reference I've found for it yet.

osm0sis said:
This is pretty cool.
Any chance you could direct me to an explanation for sha1-size (for apply_patch_check) is though? I'm working on some edify scripting stuff and trying to incorporate some asserts for a specific bootloader (important to what I'm doing), and this is honestly the best reference I've found for it yet.
Click to expand...
Click to collapse
You bet!
I'm heading home from work here soon and I'll dig-up the details for you .
(yeah, I scoured the internet for detailed information on Edify scripting as well as reviewed the actual Google/Android code--there's not a complete compendium, unfortunately).
I'll ping you back after a bit...
Cheers!

osm0sis said:
Any chance you could direct me to an explanation for sha1-size (for apply_patch_check) is though?
Click to expand...
Click to collapse
Okay, here's what I know about the apply_patch_check command:
There are basically two formats:
Code:
apply_patch_check // apply_patch_check ( <filepath>, <sha1-checksum> [ , <sha1-checksum> ... ] )
// apply_patch_check ( <compoundvalue> )
<compoundvalue> := [ EMMC : <filepath> : <sha1-size> : <sha1-checksum> [ <sha1-size> : <sha1-checksum> ... ]
[ MTD : <dev-block> : <sha1-size> : <sha1-checksum> [ <sha1-size> : <sha1-checksum> ... ]
[ vfat : <dev-block> : <sha1-size> : <sha1-checksum> [ <sha1-size> : <sha1-checksum> ... ]
The first of which is what I think you typically see in updater-script files where you have a filename, followed by one or more SHA1 digests. Here's an example:
assert(apply_patch_check("/system/app/ApplicationsProvider.apk", "41bb5aaaa2791e68b55622fcca13f0e4efa757b2", "fc845332ae7f706824de73f64ae47f93866ad245"));​
The second format is what I call a compound value format, where the file or partition to be checked and the SHA1 digests to be compared, are all concatenated together in a single, colon-separated value. For example:
assert(apply_patch_check("EMMC:/dev/block/platform/omap/omap_hsmmc.0/by-name/boot:4247552:3f4d4f9549d307d152f8503983ee4ff5f46b0a43:4470784:fbd13c778b34fdb7917c1ccee6389aa9b13a92bd")); ​
In the above, I've colored the sizes in red of file/partition on which to compute the SHA1 checksum (colored in black). I figured this out and verified this by using dd to copy the portions of the partition in question and calculating the SHA1 checksums on it.
My app only supports parsing and evaluating two sets of lengths/SHA1s for the compound format at this time (that's all I've encountered so far in the scripts that I've viewed).
Does that help and/or answer your questions?
Cheers!

Thanks! Yeah that helps a lot, but unfortunately it doesn't seem to solve the problem I've been seeing..
Using dd to grab the partition img I can sha1sum that and that SHA1 doesn't allow it to pass the assert, or even a direct sha1_check of the partition.
Code:
run_program("/sbin/busybox", "dd", "if=/dev/block/platform/sdhci-tegra.3/by-name/USP"), "of=/tmp/bootloader.img")
ui_print(sha1_check(read_file("/tmp/bootloader.img"))); = 8c206a1a87599f532ce68675536f0b1546900d7a (also, bootloader.img is 2097152 in size)
ui_print(sha1_check(read_file("/dev/block/platform/sdhci-tegra.3/by-name/USP"))); = da39a3ee5e6b4b0d3255bfef95601890afd80709
assert(apply_patch_check("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/USP:2097152:8c206a1a87599f532ce68675536f0b1546900d7a")); = Fail
They just don't match and I'm completely baffled by it. I can work around it by using dd to pull the img first and using that for my asserts but it's not as clean as I'd like it.

osm0sis said:
Yeah that helps but I guess unfortunately it doesn't entirely solve the problem I've been seeing.
Using dd to grab the partition img I can sha1sum that and that SHA1 doesn't allow it to pass the assert, or even a direct sha1_check of the partition.
They just don't match and I'm completely baffled by it. I can work around it by using dd to pull the img and using that for my asserts but it's not as clean as I'd like it.
Click to expand...
Click to collapse
Is it for the Gnex or the N7 (I have those same devices)?
I'd be happy to test something for you...just PM me or send me an email ([email protected]).
I don't know if you're using my app to test with, but you can also manually run the update-binary directly on/from your phone (i.e., you don't have to run it in recovery, but you obviously need to be careful what your updater-script does ).
I'm still looking for the exact syntax in my notes, but I'll edit this post when I find it...brb.
~ ~ ~
edit: http://wiki.opticaldelusion.org/wiki/Update-binary shows this:
update-binary <api> <pipefd> <zip>
Click to expand...
Click to collapse
I know I did this during my early testing, but I can't remember the exact syntax...I'll try it and re-re-edit .

Man thanks so much, PM sent.
Sorry for cluttering up your thread with this semi-OT stuff.

osm0sis said:
Man thanks so much, PM sent.
Sorry for cluttering up your thread with this semi-OT stuff.
Click to expand...
Click to collapse
LOL, not a problem...it's all Edify-related and updater-script related...I'm betting that's what'll lead most folks here.
Happy to help .

==================
Detailed Analysis
==================
- you have no frozen system apps (good!)
- there were 2 failed expressions; see below for the details about these tests that will cause your OTA install to fail
- there were no bypassed expressions (good!)
-------------------------------
statistics:
frozen system apps: 0
success count: 526
fail count: 2
ignore count: 1587
partition count: 2
protected count: 2
bypassed count: 0
-------------------------------
updater-script analysis details:
FAILED: line #268:
assert(apply_patch_check("/system/app/XT9IME.apk", "8aba56a4406128e78f5729753252c3d93bc21cb4", "965b437bce65018eeb31ff9a381c3687542099e0"));
----------------------
FAILED: line #1038:
assert(apply_patch_check("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5013504:c48f8e86c73fb2c2ba1794f5ec98e27c9e206ed5:5060608:319331fae14fec8a88063751475fce26bae328e0"));
So a question, could this failure above be causing my 32 GB nexus 7 to have system update issues? (Not necessarily XT9IME.apk (which I shouldn't have deleted), more the other one) Is there a fix?
Sent from my Nexus 7 using Tapatalk HD
---------- Post added at 10:44 AM ---------- Previous post was at 10:39 AM ----------
==================
Detailed Analysis
==================
- you have no frozen system apps (good!)
- there were 2 failed expressions; see below for the details about these tests that will cause your OTA install to fail
- there were no bypassed expressions (good!)
-------------------------------
statistics:
frozen system apps: 0
success count: 526
fail count: 2
ignore count: 1587
partition count: 2
protected count: 2
bypassed count: 0
-------------------------------
updater-script analysis details:
FAILED: line #268:
assert(apply_patch_check("/system/app/XT9IME.apk", "8aba56a4406128e78f5729753252c3d93bc21cb4", "965b437bce65018eeb31ff9a381c3687542099e0"));
----------------------
FAILED: line #1038:
assert(apply_patch_check("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5013504:c48f8e86c73fb2c2ba1794f5ec98e27c9e206ed5:5060608:319331fae14fec8a88063751475fce26bae328e0"));
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
So a question, could this failure above be causing my 32 GB nexus 7 to have system update issues? (Not necessarily XT9IME.apk (which I shouldn't have deleted), more the other one) Is there a fix?

modwilly said:
So a question, could this failure above be causing my 32 GB nexus 7 to have system update issues? (Not necessarily XT9IME.apk (which I shouldn't have deleted), more the other one) Is there a fix?
Click to expand...
Click to collapse
Looks like you've updated the boot (LNX) partition in addition to deleting (or renaming/moving) the XT9IMG.apk?
So yes, the OTA will not install until you've put both items back to their expected state.
The fix, of course, depends on exactly what you did to change them in the first place.

version 2.1 uploaded to Play Store
Major re-write of app done for version 2.0 and above.
Recent change log:
[version 2.1 - 6-May-2014]:
- fix issue w/identification of non-existent files
[version 2.0 - 5-May-2014]:
- major app update: edify parsing, RPN processing and execution engine completely re-written
- original core app behavior and functionality remain the same, but code cleanup and re-write should mean better and more robust handling of future OTA updater-script expressions
Click to expand...
Click to collapse
Thanks and let me know if you have any questions.

@scary alien could you please tell me how to get apply_patch_space bytes? i am making ota script and i got almost all, still need to generate:
apply_patch_space(bytes) || abort("Not enough free space on /cache to apply patches.");
Click to expand...
Click to collapse
i just dunno how

ZduneX25 said:
@scary alien could you please tell me how to get apply_patch_space bytes? i am making ota script and i got almost all, still need to generate:
i just dunno how
Click to expand...
Click to collapse
It's just the available space (in bytes) in the /cache partition that you want to make sure is available (i.e., free space) for any operations your updater-script file will do concerning /cache.
For example:
apply_patch_space(1000000) || abort("Not enough free space on /cache to apply patches.");
Click to expand...
Click to collapse
Would verify that there is at least 1MB (1,000,000) free bytes available in /cache.
Does that answer what you're asking?
Lemme know--happy to help if I can.
Cheers!

@scary alien not really, i mean i know how it works, just dunno how to generate proper size in updater, for example:
i create regular ota: multiple .p files and some images, zipped, signed OTA.zip size is 20mb, /patch size is 7 mb, images 10 mb and /system (new files) 3mb, how do i know how many bytes i should set to make this ota install in recovery?
should i summarize .p files size or target (patched apk, jar) files size (would be around 90mb) or what else?

I think the size would depend on when your patch files are cleaned-up...i.e., after each patching operation or at the end. If its at the end, you'll of course need to account to all of the space you might use in /cache.
I don't know of a good way to tell you what the high water mark would be other than testing and recording the output of a "df /cache" command at various points in your updater-script file.

I could do that however I don't see it universal or handy, each ota has different size so it would need more/less free space every time.
There is how Google gets this value : https://github.com/MiCode/patchrom_tools/blob/kitkat/releasetools/edify_generator.py#L131 maybe you will understand better.

ZduneX25 said:
I could do that however I don't see it universal or handy, each ota has different size so it would need more/less free space every time.
There is how Google gets this value : https://github.com/MiCode/patchrom_tools/blob/kitkat/releasetools/edify_generator.py#L131 maybe you will understand better.
Click to expand...
Click to collapse
I think I understood what you meant...there's no easy way to make this universal for each OTA except to evaluate each file that might need to use space resources from the /cache partition.
Even the edify-generator git that you referenced does this dynamically:
releasetools/ota_from_target_files:
Code:
for diff in diffs:
tf, sf, d = diff.GetPatch()
if d is None or len(d) > tf.size * OPTIONS.patch_threshold:
# patch is almost as big as the file; don't bother patching
tf.AddToZip(output_zip)
verbatim_targets.append((tf.name, tf.size))
else:
common.ZipWriteStr(output_zip, "patch/" + tf.name + ".p", d)
patch_list.append((tf.name, tf, sf, tf.size, common.sha1(d).hexdigest()))
[COLOR="Red"]largest_source_size[/COLOR] = max([COLOR="red"]largest_source_size[/COLOR], sf.size)
:
:
:
if patch_list or updating_recovery or updating_boot:
script.[COLOR="Blue"][B]CacheFreeSpaceCheck[/B][/COLOR]([COLOR="red"]largest_source_size[/COLOR])

I have seen it, but here comes largest_source_size:
Code:
largest_source_size = 0
https://github.com/MiCode/patchrom_tools/blob/kitkat/releasetools/ota_from_target_files#L532

ZduneX25 said:
I have seen it, but here comes largest_source_size:
Code:
largest_source_size = 0
https://github.com/MiCode/patchrom_tools/blob/kitkat/releasetools/ota_from_target_files#L532
Click to expand...
Click to collapse
Yeah, that's just the initialization of that variable...it gets updated in the for-loop that I included above.
(you know that's not my tool, software, right?)

[APP] AROMA Installer

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
The World's First ANDROID Touch And Customizable ROM Installer
Don't Forget To Donate To Me:
------=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=------
_________________________________________
When you install Linux, Windows, Mac or applications on the PC
You can always customize your installation as you want.
WHY CAN'T WE DO THE SAME INSTALLING AN ANDROID ROM?
BECAUSE NOW
AROMA Installer
GIVES YOU THIS POSSIBILITY!​
_________________________________________
------=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=------​
FROM INDONESIAN DEVELOPERS TO PEOPLE AROUND THE WORLD​
W.A.R.N.I.N.G.!!!
THIS DEVDB DISCUSSION ONLY FOR DEVELOPMENT DISCUSSION.
USE Q&A TO ASK ABOUT SCRIPT, HOW TO, AND INSTALLATION​
FOR ROM CHEFS/DEVELOPERS ONLY
ROM Chef/Developers? What is that? ... Here the video.
DON'T ASK ABOUT HOW TO INSTALL IT, BECAUSE IT MEANS YOU DON'T KNOW WHAT IT IS FOR
IT ISN'T AN APPLICATION YOU CAN USE OR INSTALL ON TO YOUR PHONE LIKE ANGRY BIRDS OR FACEBOOK
MOST IMPORTANT THING BEFORE CUSTOMIZING IT
Make sure You took an update-binary from a working ROM, renamed it to update-binary-installer and overwrote the one in my AROMA Installer zip
BACKGROUND
Android has an advanced system for installing the OS and updates, unlike other mobile OS's that distribute the contents of the OS in static ROM image(s), Android distributes the OS and updates in a plain .zip file that contains all of the packages, files, and the updater for processing the installation.
The updater splits in 2 types, the binary (update-binary) and script (updater-script), while the binary is an executable file, and the script was a configuration script that tells the binary executable what to do.
But this advanced technology never expanded into its highest potential ability. The update-binary was simply the linux executable wrote in C that runs in root mode, and can do anything to your system; including accessing the Display FrameBuffer, accessing keys and the touch screen, set vibrate, run programs, parse files, load png(s) and .zip's, and read and write to the filesystem.
The old update-binary only supported a few functions that can controlled only by the updater-script to instal the files. It didn't have a single function that allowed the installer to interact with the user. There is a program called "yesno" that shows a "Yes" or "No" interface, but it wasn't enough to create a more customizable updater.
Now with AROMA Installer update-binary, all of this limitation is gone, and this advanced technology is expanded to the highest level of its pontential.
What is AROMA Installer?
"AROMA" was taken from Bahasa Indonesia (Indonesian Language) and it means "Scent", but it is also an abbreviation of "AMARULLZ ANDROID ROM MANIFESTATION". It is an advanced update-binary for Android that contains many features like Wizard Installation, Touch User Interface (AROMA UI), Customizable Packages, System Inspecting, Themeable, and User Interactive. All release versions will have "flower" codenames, for example, the 1st version is codenamed "Anggrek", which mean "Orchid".
How AROMA Installer Works?
How can it work in recovery mode, and how can it so smooth when it scrolls? It works because I hired Chuck Norris to force the recovery to run the installer, and the phone is too afraid to show any lag .
No, seriously, when the user selects the .zip file to install it, the recovery will extract the update-binary and run it with a few arguments. All processes are handled by the update-binary, and the recovery will only show the information passed by update-binary via a custom pipe. The great thing is that the update-binary can do anything if we can code it in C/C++, but not all people can easily play with C/C++. Its also not very effective or fun to compile it every time we need to change the process. That's why the custom script is used in AROMA Installer, it is simply edify scripting that is used as the normal updater-script, but with expanded functions available.
It wasn't a simple thing to archive something like this, because the update-binary is simply the "linux executable" that doesn't even support dynamic links of libraries, basic drawing functions like drawrect, drawline, and I don't think it OpenGL can be included in it's binary. It runs on it's own. Even User Interface was wrote from scratch to manipulate directly into the display framebuffer, user input was read directly from the raw kernel input device, png and .zip was read with a static link library, and the configuration was parsed in it's own program. It is the result of one full month of developing, but you can learn it instantly, without any need to know how to manage memory usage and pointers.
The AROMA Installer will read, parse, and run the script commands to show it's UI, calculate partition sizes, create, read, and write temporary prop files, set & get variables, do simple integer comparisons and math sequences, do the if else or inline if conditions, configure the UI color scheme, configure rom information, and much more.
Benefits For Users
AROMA Installer gives users the possibility to choose which mods and applications they want to Install on to their device. Sometimes we want the clean install, without bloatware; and sometimes we want the full set of applications on our device. With AROMA Installer, you are your phone's master!
Benefits For Chefs/Developers
AROMA Installer gives chefs many benefits:
You don't ever again have to hear someone ask to remove or include something they like into your ROM, just for you to yell "Hey, that is only your opinion! Only you and some other people like it; most people don't! Go remove the apps on your own with WINRAR, you ^$#&*&#$", remember they are still a customer , and with AROMA Installer, this problem can be solved.
If you are good at customizing the AROMA Installer it was possible to make your ROM compatible with many devices using just one ROM File. You save your time, bandwith and hosting maintanance.
With the great user interface in your ROM installation, users will be very happy with it.
With AROMA Installer, You Are The Greatest ROM Developer
XDA:DevDB Information
AROMA Installer, App for all devices (see above for details)
Contributors
amarullz
Source Code: https://github.com/amarullz/AROMA-Installer
Version Information
Status: Beta
Current Stable Version: 3.00
Stable Release Date: 2015-02-28
Current Beta Version: 3.00b1
Beta Release Date: 2015-02-28
Created 2013-08-17
Last Updated 2015-02-27

Reserved
Reserved for Release and Development Information

Reserved
Reserved for Wiki and Manual Table of Contents

Nice.
Sent from my LG-LS970 using xda app-developers app

Yay, first feature and review sent
Keep up awesome work amarullz!

Reading and Learning

Hey Amarullz,
Where are you at with the dynamic/JSON stuff or have you already implemented it?
Also, are you aware of Aroma randomly hanging at 0% when launching aroma-binary-installer? This happens on the HTC One.
Thanks,
Turge

Hiduplah Indonesia Raya...
Sent from my HTC Butterfly using xda premium

If you need a S4 tester im available right now and can join IRC.

Was I the first one using the bug report feature?

Turge said:
Hey Amarullz,
Where are you at with the dynamic/JSON stuff or have you already implemented it?
Also, are you aware of Aroma randomly hanging at 0% when launching aroma-binary-installer? This happens on the HTC One.
Thanks,
Turge
Click to expand...
Click to collapse
JSON Implementation will be available on new core (because current version doesn't included JSON library).
But for dynamic content, you can use "eval" function to run aroma script from text.
You can create dynamic script using shell, then use eval to run it.
Eval Example:
Code:
eval("alert(\"On Eval Function\",\"This Alert was executed from Eval Function...\", \"@info\");");
Eval Example with shell
alertcode.sh
Code:
#!/bin/sh
echo "alert(\"On Eval Function\",\"This Alert was executed from Eval Function...\", \"@info\");"
aroma-config
Code:
resexec("script/alertcode.sh");
eval(getvar("exec_buffer"));
Eval Example with shell file
alertcode.sh
Code:
#!/bin/sh
echo "alert(\"On Eval Function\",\"This Alert was executed from Eval Function...\", \"@info\");" >> /tmp/test.edify
aroma-config
Code:
eval(read("/tmp/test-edify"));
I didn't test the code, but I hope you understand what I mean.

--- removed ---

This is new AROMA Markup String Engine
This is the script for it:
Code:
<8>AROMA Markup String
<4>This is example of using <b>NEW AROMA Markup String <u>(AMS)</u> from <5>New AROMA CORE</b>. Now
<5>you can <f1>Change The Font Face and <7>Font Size. <4>And even including <f2>Some Image <6>With
simple AMS TAG:
<[file:///sdcard/0/apps.png;72dp;72dp]> was resized, and <f1>This image:
<f1>Font <[file:///sdcard/0/install.png]> without resized.
<6>
<f0>This is font ID=0 - Roboto-Regular.ttf
<f1>This is font ID=1 - RobotoCondensed-Bold.ttf
<f2>This is font ID=2 - DroidSerif-Italic.ttf
*** ugh.. xda convert high quality png into jpeg :silly: Not cool...

amarullz said:
This is new AROMA Markup String Engine
This is the script for it:
Code:
<8>AROMA Markup String
<4>This is example of using <b>NEW AROMA Markup String <u>(AMS)</u> from <5>New AROMA CORE</b>. Now
<5>you can <f1>Change The Font Face and <7>Font Size. <4>And even including <f2>Some Image <6>With
simple AMS TAG:
<[file:///sdcard/0/apps.png;72dp;72dp]> was resized, and <f1>This image:
<f1>Font <[file:///sdcard/0/install.png]> without resized.
<6>
<f0>This is font ID=0 - Roboto-Regular.ttf
<f1>This is font ID=1 - RobotoCondensed-Bold.ttf
<f2>This is font ID=2 - DroidSerif-Italic.ttf
*** ugh.. xda convert high quality png into jpeg :silly: Not cool...
Click to expand...
Click to collapse
Quick question, will there be a requirement for a closing tag like so:
<f1>text</f>
Click to expand...
Click to collapse
Sent from my SGH-I757M using XDA Premium 4 mobile app

sweet! thanks

titanic_fanatic said:
Quick question, will there be a requirement for a closing tag like so:
Sent from my SGH-I757M using XDA Premium 4 mobile app
Click to expand...
Click to collapse
AROMA Markup String doesn't strict like HTML. In fact it doesn't even save the previous state of formatting (It was linear formatting).
Code like this is valid, and will result very different in html:
Code:
Normal Text <b>Bold Text and <b>Next Bold Text</b> This will not bold.
and the color example (default color is black)
Code:
Black Color <#900>Red Color <#009>Blue Color</#> This is black - not red</#> This second closing was unusable
The closing tag in AMS isn't the pair of opening tag.
Same with font
Code:
Default font <f1>Font ID=1 <f2>Font ID=2 </f> Font ID=0/Default
For fontsize, you don't have any closing tag.
<0> default size
<1> .. <9> font size 1..9.
-------
NOTE: The sintax of image, fontsize and font tag is subject to change. Any suggested syntax is welcome... You can vote syntax below, or suggest your own syntax (easier to use and easier/efficient to parsed will be used).
And If You willing it, please share this vote with your friend...
My Font sintax suggestions:
Code:
1. <f0><f1><f2><f3> - </f> ---> Current
2. <font=0><font=1><font=2><font=3> - </font>
3. <f=1><f=0><f=0> - </f>
My Fontsize sintax suggestions:
Code:
1. <0><1><2>..<9> ---> Current
2. <fontsize=1><fontsize=1><fontsize=2>...<fontsize=9> - </fontsize>
3. <size=1><size=1><size=2>...<size=9> - </size>
4. <sz=1><sz=1><sz=2>...<sz=9> - </sz>
5. <$1><$1><$2>...<$9> - </$>
My Image sintax suggestions (width/height can be in dp or px - if dp/px not defined px will be used):
Code:
1. <[URL;width;height]> <[IMAGE_URL;width]> <[IMAGE_URL;0;height]> ---> Current
2. <img="URL" 40dp,50dp> <img="URL" 40px> <img="URL" 0,50>
3. <img=URL;40dp;50dp> <img=URL;40px> <img=URL;0;50px>
4. <img="URL" w=40dp h=50dp> <img="URL" w=40px> <img="URL" h=50px>
I know that tag with attribute was easier to read by human, but more compact sintax was easier for parser :laugh: .
So please vote for it...

amarullz said:
My Font sintax suggestions:
Code:
1. <f0><f1><f2><f3> - </f> ---> Current
2. <font=0><font=1><font=2><font=3> - </font>
3. <f=1><f=0><f=0> - </f>
Click to expand...
Click to collapse
Vote: 1
amarullz said:
My Fontsize sintax suggestions:
Code:
1. <0><1><2>..<9> ---> Current
2. <fontsize=1><fontsize=1><fontsize=2>...<fontsize=9> - </fontsize>
3. <size=1><size=1><size=2>...<size=9> - </size>
4. <sz=1><sz=1><sz=2>...<sz=9> - </sz>
5. <$1><$1><$2>...<$9> - </$>
Click to expand...
Click to collapse
Vote: 1
amarullz said:
My Image sintax suggestions (width/height can be in dp or px - if dp/px not defined px will be used):
Code:
1. <[URL;width;height]> <[IMAGE_URL;width]> <[IMAGE_URL;0;height]> ---> Current
2. <img="URL" 40dp,50dp> <img="URL" 40px> <img="URL" 0,50>
3. <img=URL;40dp;50dp> <img=URL;40px> <img=URL;0;50px>
4. <img="URL" w=40dp h=50dp> <img="URL" w=40px> <img="URL" h=50px>
Click to expand...
Click to collapse
Vote: 3
Sent from my SGH-I757M using XDA Premium 4 mobile app

amarullz said:
This is new AROMA Markup String Engine
This is the script for it:
Code:
<8>AROMA Markup String
<4>This is example of using <b>NEW AROMA Markup String <u>(AMS)</u> from <5>New AROMA CORE</b>. Now
<5>you can <f1>Change The Font Face and <7>Font Size. <4>And even including <f2>Some Image <6>With
simple AMS TAG:
<[file:///sdcard/0/apps.png;72dp;72dp]> was resized, and <f1>This image:
<f1>Font <[file:///sdcard/0/install.png]> without resized.
<6>
<f0>This is font ID=0 - Roboto-Regular.ttf
<f1>This is font ID=1 - RobotoCondensed-Bold.ttf
<f2>This is font ID=2 - DroidSerif-Italic.ttf
*** ugh.. xda convert high quality png into jpeg :silly: Not cool...
Click to expand...
Click to collapse
marvellous!!! :good::good:
@titanic_fanatic, you can say me thanks cause, I gave you a thanks by error.

titanic_fanatic said:
Vote: 1
Vote: 1
Vote: 3
Sent from my SGH-I757M using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I'm agree with that!

Have an idea to embed LUA - http://en.wikipedia.org/wiki/Lua_(programming_language) for more advance AROMA customizing.
And No, Main config Is still edify.
An idea is like this:
aroma-config:
* Show list of menu, select & checkbox
* Show Text box, alert, etc.
* Do simple calculations, run shell script, etc.
* I want to do some programming and custom interface --> lua("luascript.lua");
The lua script will be called from aroma-config. this lua script will containing all useful features like looping, variables, array, functions, etc.
Did I can do it with shell script??, Yes, but you can't communicate & access AROMA features directly (only with stdout).
The lua script (will be usable if it) contains all features that aroma-config already have. Plus custom UI (but you need programming skills),
You can create window, add controls into it, then show it, and manage control message (like, what will it do when some button clicked, or some checkbox checked).
This lua script also usable for you who want to make simple application (not just installer), you can make your own GUI.
Tell me if you like an Idea??

[DEV][TEMPLATE] AnyKernel3 - Easily Mod ROM Ramdisk + Pack Image.gz [Flashable Zip]

AnyKernel3 -- Flashable Zip Template for Kernel Releases with Ramdisk Modifications
"AnyKernel is a template for an update.zip that can apply any kernel to any ROM, regardless of ramdisk." - Koush
The concept of AnyKernel has been around for awhile, (originally by Koushik Dutta/ClockworkMod,) which allowed a device-specific kernel zImage to be flashed over device-specific ROM and use the ramdisk that came with the ROM to reduce the chance of any issues arising from the custom kernel pairing.
The drawback to this was that some kernels require modifications to the ramdisk to enable/set up kernel features, and in the old AnyKernel format there was no way to do this. Enter AnyKernel2.
AnyKernel2 pushed the format even further by allowing kernel developers to modify the underlying ramdisk for kernel feature support easily using a number of included command methods along with properties and variables to customize the installation experience to their kernel. AnyKernel3 adds the power of topjohnwu's magiskboot for wider format support by default.
A script based on Galaxy Nexus (tuna) is included for reference. An example of ramdisk-only changes can be seen in my GN Synapse Injector repo. For an example that also modifies ROM and properly injects init.d support using busybox run-parts and sepolicy-inject see CosmicDan's CosmicTweaks project. For a multi-partition example and an example of how to handle a device which only has a ramdisk when rooted see my N5X/6P BLOD Workaround Injector. Other working AK2/3 examples for more recent devices may be found on eng.stk's blu_spark device repos under Releases.
Please see the linked posts here for instructions on enabling full AVBv1 (Pixel), AVBv1, A/B slot and/or system-as-root (SAR) or 2-stage init (2SI) device support, and further guidelines for system-as-root/2-stage init (/system/system in recovery) modifications in general.
Please also see the post here for important notes about the current state of AOSP vendor_boot v4 support and AVBv2 flag options.
Magisk root is automatically detected and retained by patching the new Image.*-dtb as Magisk would!
My development work on my many projects comes out of my free time, so if you enjoy this project or anything else I've done on xda, please consider sponsoring my ongoing work using my GitHub Sponsors profile. For a one-time donation you can hit the donate link from my profile. Thank you for your support!
Source: https://github.com/osm0sis/AnyKernel3/
Download: https://github.com/osm0sis/AnyKernel3/archive/master.zip
Instructions
1) Place final kernel build product, e.g. Image.gz-dtb or zImage to name a couple, in the zip root (any separate dt, dtb, recovery_dtbo, dtbo and/or vendor_dlkm should also go here for devices that require custom ones, each will fallback to the original if not included)
2) Place any required ramdisk files in /ramdisk (/vendor_ramdisk for simple multi-partition vendor_boot v3 support) and module files in /modules (with the full path like /modules/system/lib/modules)
3) Place any required patch files (generally partial files which go with AK3 file editing commands) in /patch (/vendor_patch for simple multi-partition vendor_boot v3 support)
4) Modify the anykernel.sh to add your kernel's name, boot partition location, permissions for any added ramdisk files, and use methods for any required ramdisk modifications (optionally, also place banner and/or version files in the root to have these displayed during flash)
5) `zip -r9 UPDATE-AnyKernel3.zip * -x .git -x .github README.md *placeholder`
The LICENSE file must remain in the final zip to comply with licenses for binary redistribution and the license of the AK3 scripts.
If supporting a recovery that forces zip signature verification (like Cyanogen Recovery) then you will need to also sign your zip using the method I describe here:
[DEV][TEMPLATE] Complete Shell Script Flashable Zip Replacement + Signing [SCRIPT]
Not required, but any tweaks you can't hardcode into the source (best practice) should be added with an additional init.tweaks.rc or bootscript.sh to minimize the necessary ramdisk changes. On newer devices Magisk allows these within /overlay.d - see examples.
It is also extremely important to note that for the broadest AK3 compatibility it is always better to modify a ramdisk file rather than replace it.
If running into trouble when flashing an AK3 zip, the suffix -debugging may be added to the zip's filename to enable creation of a debug .tgz of /tmp for later examination while booted or on desktop.
Staying Up-To-Date
Now that you've got a ready zip for your device, you might be wondering how to keep it up-to-date with the latest AnyKernel commits. AnyKernel2 and AnyKernel3 have been painstakingly developed to allow you to just drop in the latest update-binary and tools directory and have everything "just work" for beginners not overly git or script savvy, but the best practice way is as follows:
1) Fork my AnyKernel3 repo on GitHub
2) `git clone https://github.com/<yourname>/AnyKernel3`
3) `git remote add upstream https://github.com/osm0sis/AnyKernel3`
4) `git checkout -b <devicename>`
5) Set it up like your <devicename> zip (i.e. remove any folders you don't use like ramdisk or patch, delete README.md, and add your anykernel.sh and optionally your Image.*-dtb if you want it up there) then commit all those changes
6) `git push --set-upstream origin <devicename>`
7) `git checkout master` then repeat steps 4-6 for any other devices you support
Then you should be able to `git pull upstream master` from your master branch and either merge or cherry-pick the new AK3 commits into your device branches as needed.
Enjoy!
Questions, comments and feedback welcome.
Credits & Thanks: All authors of the included binaries and the tools I used to port them over for their amazing work. koush for the original AnyKernel concept.
Disclaimer: Naturally, you take all the responsibility for what happens to your device when you start messing around with things.

Script Commands Reference
Everything to edit is self-contained in anykernel.sh. A quick-reference for the commands and properties included are as follows.
Properties / Variables
These are some values that will be read during the install process, allowing you to customize your installation, e.g. block= is a shell variable to specify the kernel/boot block partition that the dump_boot command method will copy and unpack.
Code:
kernel.string=KernelName by YourName @ xda-developers
do.devicecheck=1
do.modules=1
do.systemless=1
do.cleanup=1
do.cleanuponabort=0
device.name1=maguro
device.name2=toro
device.name3=toroplus
device.name4=tuna
supported.versions=6.0 - 7.1.2
supported.patchlevels=2019-07 -
block=/dev/block/platform/omap/omap_hsmmc.0/by-name/boot;
is_slot_device=0;
ramdisk_compression=auto;
patch_vbmeta_flag=auto;
do.devicecheck=1 specified requires at least device.name1 to be present. This should match ro.product.device, ro.build.product, ro.product.vendor.device or ro.vendor.product.device from the build.prop files for your device. There is support for as many device.name# properties as needed. You may remove any empty ones that aren't being used.
do.modules=1 will push the .ko contents of the modules directory to the same location relative to root (/) and apply correct permissions. On A/B devices this can only be done to the active slot.
do.systemless=1 (with do.modules=1) will instead push the full contents of the modules directory to create a simple "ak3-helper" Magisk module, allowing developers to effectively replace system files, including .ko files. If the current kernel is changed then the kernel helper module automatically removes itself to prevent conflicts.
do.cleanup=0 will keep the zip from removing its working directory in /tmp/anykernel (by default) - this can be useful if trying to debug in adb shell whether the patches worked correctly.
do.cleanuponabort=0 will keep the zip from removing its working directory in /tmp/anykernel (by default) in case of installation abort.
supported.versions= will match against ro.build.version.release from the current ROM's build.prop. It can be set to a list or range. As a list of one or more entries, e.g. 7.1.2 or 8.1.0, 9 it will look for exact matches, as a range, e.g. 7.1.2 - 9 it will check to make sure the current version falls within those limits. Whitespace optional, and supplied version values should be in the same number format they are in the build.prop value for that Android version.
supported.patchlevels= will match against ro.build.version.security_patch from the current ROM's build.prop. It can be set as a closed or open-ended range of dates in the format YYYY-MM, whitespace optional, e.g. 2019-04 - 2019-06, 2019-04 - or - 2019-06 where the last two examples show setting a minimum and maximum, respectively.
block=auto instead of a direct block filepath enables detection of the device boot partition for use with broad, device non-specific zips. Also accepts any partition filename (from by-name), e.g. boot, recovery, or vendor_boot.
is_slot_device=1 enables detection of the suffix for the active boot partition on slot-based devices and will add this to the end of the supplied block= path. Also accepts auto for use with broad, device non-specific zips.
ramdisk_compression=auto allows automatically repacking the ramdisk with the format detected during unpack. Changing auto to gz, lzo, lzma, xz, bz2, lz4, or lz4-l (for lz4 legacy) instead forces the repack as that format, and using cpio or none will (attempt to) force the repack as uncompressed.
patch_vbmeta_flag=auto allows automatically using the default AVBv2 vbmeta flag on repack, and use the Magisk configuration (Canary 23016+). Set to 0 forces keeping whatever is in the original AVBv2 flags, and set to 1 forces patching the flag (only necessary on few devices).
customdd="<arguments>" may be added to allow specifying additional dd parameters for devices that need to hack their kernel directly into a large partition like mmcblk0, or force use of dd for flashing.
slot_select=active|inactive may be added to allow specifying the target slot. If omitted the default remains active.
no_block_display=1 may be added to disable output of the detected final used partition+slot path for zips which choose to include their own custom output instead.
Command Methods
Code:
ui_print "<text>" [...]
abort ["<text>" [...]]
contains <string> <substring>
file_getprop <file> <property>
set_perm <owner> <group> <mode> <file> [<file2> ...]
set_perm_recursive <owner> <group> <dir_mode> <file_mode> <dir> [<dir2> ...]
dump_boot
split_boot
unpack_ramdisk
backup_file <file>
restore_file <file>
replace_string <file> <if search string> <original string> <replacement string> <scope>
replace_section <file> <begin search string> <end search string> <replacement string>
remove_section <file> <begin search string> <end search string>
insert_line <file> <if search string> before|after <line match string> <inserted line>
replace_line <file> <line replace string> <replacement line> <scope>
remove_line <file> <line match string> <scope>
prepend_file <file> <if search string> <patch file>
insert_file <file> <if search string> before|after <line match string> <patch file>
append_file <file> <if search string> <patch file>
replace_file <file> <permissions> <patch file>
patch_fstab <fstab file> <mount match name> <fs match type> block|mount|fstype|options|flags <original string> <replacement string>
patch_cmdline <cmdline entry name> <replacement string>
patch_prop <prop file> <prop name> <new prop value>
patch_ueventd <ueventd file> <device node> <permissions> <chown> <chgrp>
repack_ramdisk
flash_boot
flash_generic <partition name>
write_boot
reset_ak [keep]
setup_ak
"if search string" is the string it looks for to decide whether it needs to add the tweak or not, so generally something to indicate the tweak already exists. "cmdline entry name" behaves somewhat like this as a match check for the name of the cmdline entry to be changed/added by the patch_cmdline function, followed by the full entry to replace it. "prop name" also serves as a match check in patch_prop for a property in the given prop file, but is only the prop name as the prop value is specified separately.
Similarly, "line match string" and "line replace string" are the search strings that locate where the modification needs to be made for those commands, "begin search string" and "end search string" are both required to select the first and last lines of the script block to be replaced for replace_section, and "mount match name" and "fs match type" are both required to narrow the patch_fstab command down to the correct entry.
"scope" may be specified as "global" to force all instances of the string/line targeted by replace_string, replace_line or remove_line to be replaced/removed accordingly. Omitted or set to anything else and it will perform the default first-match action.
"before|after" requires you simply specify "before" or "after" for the placement of the inserted line, in relation to "line match string".
"block|mount|fstype|options|flags" requires you specify which part (listed in order) of the fstab entry you want to check and alter.
dump_boot and write_boot are the default method of unpacking/repacking, but for more granular control, or omitting ramdisk changes entirely ("OG AK" mode), these can be separated into split_boot; unpack_ramdisk and repack_ramdisk; flash_boot respectively. flash_generic can be used to flash an image to the corresponding partition. It is automatically included for dtbo and vendor_dlkm in write_boot but can be called separately if using "OG AK" mode or creating a simple partition flashing only zip.
Multi-partition zips can be created by removing the ramdisk and patch folders from the zip and including instead "-files" folders named for the partition (without slot suffix), e.g. boot-files + recovery-files, or kernel-files + ramdisk-files (on some Treble devices). These then contain Image.gz, and ramdisk, patch, etc. subfolders for each partition. To setup for the next partition, simply set block= (without slot suffix) and ramdisk_compression= for the new target partition and use the reset_ak command.
Similarly, multi-slot zips can be created with the normal zip layout for the active (current) slot, then resetting for the inactive slot by setting block= to the partition (without slot suffix) again, slot_select=inactive and ramdisk_compression= to the desired options for the target slot and using the reset_ak keep command, which will retain the patch and any added ramdisk files for the next slot.
backup_file may be used for testing to ensure ramdisk changes are made correctly, transparency for the end-user, or in a ramdisk-only "mod" zip. In the latter case restore_file could also be used to create a "restore" zip to undo the changes, but should be used with caution since the underlying patched files could be changed with ROM/kernel updates.
You may also use ui_print "<text>" to write messages back to the recovery during the modification process, abort "<text>" to abort with optional message, and file_getprop "<file>" "<property>" and contains "<string>" "<substring>" to simplify string testing logic you might want in your script.
Binary Inclusion
The AK3 repo includes current ARM builds of magiskboot, magiskpolicy, lptools_static and busybox by default to keep the basic package small. Builds for other architectures and optional binaries (see below) are available from the latest Magisk zip, or my latest AIK-mobile and Flashlt packages, respectively, here:
https://forum.xda-developers.com/t/...kernel-ramdisk-win-android-linux-mac.2073775/ (Android Image Kitchen thread)
https://forum.xda-developers.com/t/...-and-ends-multiple-devices-platforms.2239421/ (Odds and Ends thread)
Optional supported binaries which may be placed in /tools to enable built-in expanded functionality are as follows:
mkbootfs - for broken recoveries, or, booted flash support for a script/app via bind mount to /tmp (deprecated/use with caution)
flash_erase, nanddump, nandwrite - MTD block device support for devices where the dd command is not sufficient
dumpimage, mkimage - DENX U-Boot uImage format support
mboot - Intel OSIP Android image format support
unpackelf, mkbootimg - Sony ELF kernel.elf format support, repacking as AOSP standard boot.img for unlocked bootloaders
elftool (with unpackelf) - Sony ELF kernel.elf format support, repacking as ELF for older Sony devices
mkmtkhdr (with unpackelf) - MTK device boot image section headers support for Sony devices
futility + chromeos test keys directory - Google ChromeOS signature support
boot_signer-dexed.jar + avb keys directory - Google Android Verified Boot 1.0 (AVBv1) signature support
rkcrc - Rockchip KRNL ramdisk image support
Optionally moving ARM builds to tools/arm and putting x86 builds in tools/x86 will enable architecture detection for use with broad, device non-specific zips.

Boom . dibs on first :good:
You get 2 thank button presses fro me lol
Awesome work man as always

Good thing that this amazing work has it's own thread. Congrats buddy.
Sent from my Galaxy Nexus using XDA Premium 4 mobile app

Thanks guys!
I figured it would be nice to get it out there and also have it as a "Help Desk" thread for kernel devs who have questions about implementation, etc. too. Some devices might require switching it from dd to MTD-Utils, so I can help with that. So on and so forth.
Once we get a few devs who know how to use it, it should be pretty easy to help others. I'm looking at you Smitty. No pressure.

I finished my thanks ... but as always a great job.

ak said:
I finished my thanks ... but as always a great job.
Click to expand...
Click to collapse
So wait im confused. ?.. so 1) those that mean I can flash ak kerenl 4.2 with ur any kernel to my 4.4 .
2) those it have to be same kerenl for same phone manufacturer. Meaning can I be stupid enought to flash a nexus 4 kernel in my gnexus?
I understand any kernel cause I have been using smitty so thanks

milojoseph said:
So wait im confused. ?.. so 1) those that mean I can flash ak kerenl 4.2 with ur any kernel to my 4.4 .
2) those it have to be same kerenl for same phone manufacturer. Meaning can I be stupid enought to flash a nexus 4 kernel in my gnexus?
I understand any kernel cause I have been using smitty so thanks
Click to expand...
Click to collapse
Haha I wrote "device-specific" in the OP to try and avoid this very confusion.
Since I answered this same question earlier tonight in my Odds and Ends thread I'll just paste it here:
caspboy said:
so now devs can use kernels from other devices with their roms?
Click to expand...
Click to collapse
osm0sis said:
No. That's crazy talk. :laugh:
The concept of AnyKernel has been around for awhile, (originally by Koushik Dutta/ClockworkMod,) which allows device-specific kernels to be flashed over device-specific ROMs and use the ramdisk that came with the ROM to reduce the chance of any issues arising from the custom kernel pairing.
The drawback to this is that some kernels require modifications to the ramdisk to enable/set up kernel features, but in the old AnyKernel format there was no way to do this. Until now.
AnyKernel 2.0 makes it easy for kernel devs to use a number of simple command methods to automate the process of adding tweaks into a ROM's underlying ramdisk during the flashing process. :good:
Click to expand...
Click to collapse
Hopefully that helps. Basically exactly what's in the OP since that's where I edited it in from.
The only way I can explain it any further is with the very basics: that kernel boot.img files contain a zImage and a ramdisk. "AnyKernel Classic" just slaps the custom kernel zImage on top of the ROM's untouched default kernel boot.img ramdisk. AnyKernel 2.0 allows kernel devs to also modify the ramdisk to add anything required for kernel features in addition to the usual repacking it with the custom zImage and flashing it.

Great thread!! Best of lucky bro!!!
Sent from my Galaxy Nexus using xda app-developers app

AnyKernel will work on my phone now ? Thanks for enhancing awesome @osm0sis but DrRamdisk to the rest of you guys ?

wow,thats very cool,great work.

Github updated with my own forked native compiles of mkbootimg+unpackbootimg.
This should expand AnyKernel 2.0 device support a lot by using all the available offsets in mkbootimg, as exported by my drastically updated unpackbootimg. :good:

osm0sis said:
Github updated with my own forked native compiles of mkbootimg+unpackbootimg.
This should expand AnyKernel 2.0 device support a lot by using all the available offsets in mkbootimg, as exported by my drastically updated unpackbootimg. :good:
Click to expand...
Click to collapse
Hi osm0sis,
Have You update anykernel 2.0 to work with cyanogen11 roms ? Thanks for Your hard work !

Should already?
It uses the ROM kernel ramdisk like AnyKernel always has. Your custom kernel dev just needs to use it. Spread the word. :good:

osm0sis said:
Should already?
It uses the ROM kernel ramdisk like AnyKernel always has. Your custom kernel dev just needs to use it. Spread the word. :good:
Click to expand...
Click to collapse
Recently I had used Your method on Cyano11 but boot stopped on "Google".. new Cyano11 (that required ramdisk changes) had just come out and maybe anykernel 2.0 was not ready yet (I had just discovered your brillant work on It ! : Dita incrociate.
I'll try again ... if I have trouble going to ask you for help ...
I am already spreading the word : Cool:
Thanks man : Good:

What custom kernel were you trying to adapt to AnyKernel so you could flash it on CM?

osm0sis said:
What custom kernel were you trying to adapt to AnyKernel so you could flash it on CM?
Click to expand...
Click to collapse
Two kernels... My custom kernel (from cyanogenmod sources) and recently Fancy kernel (dirty-fancy)... now I want to try Fancy Kernel .. I need of a hibryd ramdisk for best final results and Your project is perfect for It !!! You're a genius !!!
Please, Can You link me Your dirty-V kernel re-pack by Anykernel 2.0 ? So I can follow It as an example. Thanks a lot...

So if I understand you, you're trying to make an AnyKernel 2.0 of Fancy Kernel so that you can flash it on any ROM for your device?
Should be doable. The DirtyV AnyKernel 2.0 is the example posted to the GitHub repo in the OP. Just follow the instructions to make your own anykernel script so that it will add the /sbin/ scripts and other ramdisk modifications (init.d, etc.) that @boype uses, instead of the DirtyV ones.
Good luck!

osm0sis said:
So if I understand you, you're trying to make an AnyKernel 2.0 of Fancy Kernel so that you can flash it on any ROM for your device?
Should be doable. The DirtyV AnyKernel 2.0 is the example posted to the GitHub repo in the OP. Just follow the instructions to make your own anykernel script so that it will add the /sbin/ scripts and other ramdisk modifications (init.d, etc.) that @boype uses, instead of the DirtyV ones.
Good luck!
Click to expand...
Click to collapse
Yes !
osm0sis ? If I want include init.rc original file by "real" ramdisk can I copy It as is into patch folder ?

It would go against the idea of AnyKernel to include the file like that. Remember, everything automatically comes from the original ramdisk, I just give you the ability to alter those files to add tweaks. :good: