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...

[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?)

Breaking: Android 4.3 For Google Nexus 4 Leaks (JWR66N) - Here's The System Dump

Breaking: Android 4.3 For Google Nexus 4 Leaks (JWR66N) - Here's The System Dump​
For the past few hours, I've been observing a curious case of Jeff Williams on Google+. Jeff posted a screenshot of what he claimed was a Nexus 4 he bought from a Googler... with a build of Android 4.3 on it. The same build, JWR66N, that we saw leaked earlier on a Galaxy S4 GPE by SamMobile.
{
"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"
}
In disbelief, some have called him a hoaxer, but a number of resourceful folks decided to get Jeff on IRC (channel #Android43 on freenode) and worked with him for hours, trying over and over to get the magical system dump that would prove Jeff's story to be real.
The system dump, which we have since confirmed as legitimate and along with dozens of other IRC members mirrored to multiple destinations, indeed belongs to a Nexus 4 (mako), and the build number is indeed JWR66N. The radio and bootloader are missing right now - Jeff promised them tomorrow - so I have my doubts about a working port to other Nexus 4s for the time being.
In the meantime, the system dump itself is ready to go, and Ron and I are ripping through it as we speak. We'll have a teardown ready for you soon if we do dig something up, and by the looks of things, there's enough for a post.
I'd like to thank Jeff for his persistence as well as IRC users efrant, gravufo, Jason__, vividboarder, Introspection, and everyone else who drove this one to the finish line.
Update: There's chatter on IRC that restoring the backup via TWRP recovery seems to work. We haven't tested this, so if you do decide to proceed, do so with caution and after making a full backup of your entire system.
AP mirror #1
AP mirror #2
AP mirror #3
AP multi-mirror
Even more mirrors (by hackthevoid)
Breaking: Android 4.2.2 (Build JDQ39) Update Rolling Out To GSM Galaxy Nexus, Nexus 7, Nexus 10​
exus owners may have a reason to stay up tonight, as a couple of Reddit users report that Android 4.2.2 has begun rolling out to the GSM Galaxy Nexus and the Nexus 7.
There's not much word regarding what the update (which carries build JDQ39) includes just yet, but readers may remember that Google promised a Bluetooth A2DP audio streaming fix in the "next release" of 4.2 after 4.2.1.
At the moment it would seem that Reddit users in the thread linked below are the only ones reporting success at grabbing the update, so it's hard to judge the thread's veracity. If 4.2.2 has hit your device, though, let us know in the comments below.
Update: It looks like the update is rolling out after all. We've received confirmation from a number of users on Google+, including Marco Duran, who kindly provided some shots of the 47.6MB download from the Nexus 10.
Source: Android Police

4.2.2 nexus 7
NEED OTA LINK FOR NEXUS 7:laugh::laugh:

Here's The Android 4.2.2 JDQ39 Update For The GSM Galaxy Nexus
Here's The Android 4.2.2 JDQ39 Update For The GSM Galaxy Nexus [Manual Installation Instructions]​
A couple of hours ago, Google started rolling out the Android 4.2.2 update to a very limited subset of Nexus devices (build JDQ39). At this point, almost nobody can get the OTA pulled by going through the Settings screen, but don't worry - one of our loyal readers extracted the OTA url for the Galaxy Nexus and sent it over to us (great work, Daniel Koch!).
For now, we only have the link for the takju Galaxy Nexus variant, i.e. GNex handsets bought from the Play Store. Once we get the yakju build, we'll update this post.
Note: Every Custom ROM flashing May have risk. So, please do it at your own Wish.
If you're not sure whether you have a takju or yakju variant, download Nexus Update Checker from the Play Store and see what it says.
Click to expand...
Click to collapse
What's New?
We don't have any reliable information at this point because Google hasn't pushed the 4.2.2 files to AOSP yet or published any changelogs. We suspect the Bluetooth bug has been fixed, but are unclear what else has changed right now.
There is a new radio in this OTA.
Prerequisites
Your device should be running build JOP40D before trying to install the update manually. If you for some reason don't have JOP40D, Google has it available in factory image form here.
For those ready to download and install manually, the process is easy. If you
have a custom recovery, just download the zip (linked below), move it to your device, and flash as usual
have the stock recovery, keep the zip file on your computer and follow a few easy instructions below
Manual Instructions
Step 1.
Reboot your Galaxy Nexus, holding the Volume Up and Volume Down buttons while it boots up. Once you see the fastboot menu and "Start," press Volume Up to navigate to "Recovery" and press the power button. Once you see an Android with a red exclamation point icon, press Volume Up and the Power button together, which will bring you to a new menu. Navigate to "apply update from adb."
Step 2.
Connect your Galaxy Nexus to your computer with a USB cable.
Make sure you have a recent version of adb that supports the sideload command (if you don't, download the latest Android SDK to ensure your adb is up-to-date).
Open up a command prompt (cmd in Windows, regular shell in Linux and Mac) in the same directory as the zip file you've downloaded.
Type in the following:
adb sideload 472aafeb9fe3.signed-takju-JDQ39-from-JOP40D.472aafeb.zip
Click to expand...
Click to collapse
You should see a progress bar, which will eventually hit 100%. At this point, your device is installing the update.
Step 3.
Reboot and enjoy! You are now running Android 4.2.2 on your Galaxy Nexus.
Download
Here's the OTA, hosted on Google's servers: takju build JDQ39.
AP mirror just in case it goes down: AndroidFileHost.
MD5: d37cd3aeeacc0d25a523acbebb5557f4
File size: 46.4 MB (48,672,997 bytes)
Source: Android Police

Shouldn't this file word being updated from recovery the normal way to?
I'm on Galaxy Nexus takju with TWRP recovery, and my updated failed..
EDIT: I get this error. assert failed: apply_patch _check ("system/lib/li
E: Error in /sdcard/filename.zip
(status7)
Error flashing zip
Updating partition details
/Söder

Re: Breaking: Android 4.2.2 (Build JDQ39) Update Rolling Out To GSM Galaxy Nexus, Nex
Good update
Sent from my GT-I8150 using xda app-developers app

soder said:
Shouldn't this file word being updated from recovery the normal way to?
I'm on Galaxy Nexus takju with TWRP recovery, and my updated failed..
EDIT: I get this error. assert failed: apply_patch _check ("system/lib/li
E: Error in /sdcard/filename.zip
(status7)
Error flashing zip
Updating partition details
/Söder
Click to expand...
Click to collapse
Try to flash using CWM buddy. Also are you applying the commands..??

soder said:
Shouldn't this file word being updated from recovery the normal way to?
I'm on Galaxy Nexus takju with TWRP recovery, and my updated failed..
EDIT: I get this error. assert failed: apply_patch _check ("system/lib/li
E: Error in /sdcard/filename.zip
(status7)
Error flashing zip
Updating partition details
/Söder
Click to expand...
Click to collapse
Dude it's not a regular flashable zip. You need a takju stock recovery.

m.kochan10 said:
Dude it's not a regular flashable zip. You need a takju stock recovery.
Click to expand...
Click to collapse
But, as I remember it, the 4.2.1 update was that kind of that kind of zip to?
And I was told I could flash it in a custom recovery? Or do I remember it wrong?
EDIT: This is where I got that info I think
http://forum.xda-developers.com/showthread.php?p=34706283#post34706283
and also from here
http://forum.xda-developers.com/showthread.php?t=1592689&page=84
Also:
"For those ready to download and install manually, the process is easy. If you
have a custom recovery, just download the zip (linked below), move it to your device, and flash as usual"
EDIT2: I now remember that I might have edited my gps.conf, and created a new file. That might have anything to do with it? How do I get back an "untouched" version? I go have a backup of the stock rom, but how do I get the file back untouched?
/Söder

Re: Breaking: Android 4.2.2 (Build JDQ39) Update Rolling Out To GSM Galaxy Nexus, Nex
Now the source needs to be updated so I can get it on my Samsung galaxy s1
Sent from my SCH-I500 using Tapatalk 2

Android 4.2.2 (JDQ39) Source Has Started Pushing To AOSP
Android 4.2.2 (JDQ39) Source Has Started Pushing To AOSP [Updated]​
It's begun - the newest version of Android, 4.2.2, is being pushed to AOSP right now. We saw the accompanying Nexus OTA rollout start last night, with update files slowly springing up thereafter. Right now, 4.2.2 builds can be downloaded for the Takju Galaxy Nexus, Nexus 7 (Wi-Fi), and Nexus 10.
The build number is JDQ39 and the tag in AOSP is android-4.2.2_r1. Here are a few of the many directories that have been updated:
/device/common/+/android-4.2.2_r1
/platform/dalvik/+/android-4.2.2_r1
/platform/build/+/android-4.2.2_r1
While the push has just started this morning, source will likely continue to show up throughout the day, and we'll update this page as that happens. The Android Building Google Group should have a post by JBQ when the push is complete.
Update: It appears the push has finished, all Android 4.2.2 code should be in AOSP now.
They're working on compiling a full developer changelog right now, and once we've done that, we'll try to come up with a more human-readable one.
[Developer Changelog] Here's What's New In Android 4.2.2 (JDQ39)​
Following yesterday's Android 4.2.2 OTAs to various Nexus devices, Google today followed up with the push of all 4.2.2 open source code changes to AOSP. There is a lot here to parse through this time around compared to the minor 4.2.1_r1.2 commit from 10 days ago.
We've already identified some obvious user-facing changes, which we'll post about separately soon to keep it clean and organized. The purpose of this post is, as before, to find the low-level changes that may not be obvious. So move the beard out of the way and dig in.
Update: Ron detailed some new things here: New Android 4.2.2 Features: Toggle From Quick Settings, Better App Download Notifications, and Some New Sounds!
What's New?
Things we've discovered so far, in brief:
Play Store downloads now show time left to download.
Long-pressing Wi-Fi and BT now toggles them in the notification Quick Settings.
More secure ADB thanks to the new whitelist.
BT bug fixes? I've seen conflicting reports whether this is fixed - citation needed if anything's been done to it. Can you spot the right commits?
Update #1: Play a tone when wireless charging begins (if below 95% battery). Use new low battery and wireless charging sounds on Mako. Here are the new sounds: WirelessChargingStarted.ogg and LowBattery.ogg.
Here is the list of developer commits in 4.2.2 (AOSP tag android-4.2.2_r1, JDQ39) compared to 4.2.1's latest revision (AOSP tag android-4.2.1_r1.2, JOP40G).
Note: For whatever reason, some of these we may have seen before - perhaps someone who understands the intricacies of AOSP's git structure can explain why they're getting included in the diff, but for the most part, this is all new stuff.
Code:
Project name: /platform/development
•Chris Banes - Update bitmapfun sample to call recycle()
•Dirk Dougherty - Add redirect for removed file.
•Dirk Dougherty - Minor updates to keep androiddevdocs redirect in sync with devsite version (in frameworks/base)
•Adam Koch - Bitmapfun Sample: Fix bug where background image loading could hang
•Chet Haase - Cherrypick from Change-Id: I4ae984cf776604cede32b98db6b1eb3cb6c59c7e
•Adam Koch - Bitmapfun Sample: Change cache memory calculation to use maxMemory()
•Adam Koch - Bitmapfun Sample: Fix inSampleSize selection and update dependencies
•Katie McCormick - Network sample: fix typo in manifest
•Xavier Ducrohet - Update platform tools rev to 16.0.2
•Dirk Dougherty - Add ko and ru to validLangs.
•Joe Malin - Android Training: Threads sample app
•Dirk Dougherty - Add redirect for IAB v3 restructure.
•Dianne Hackborn - SDK Only: Fix search interaction with various samples.
•Dirk Dougherty - Redirects /guide/google to /google/.
•Xavier Ducrohet - Move plat-tools SDK component rev to 16.0.1
•&& repo sync -j8 - Doc change: sample app for Notifications class
•Scott Main - docs: update redirects for articles
•Scott Main - docs: add redirects for best practices pages that moved to training
•Scott Main - docs: a few bonus redirects for dac
•Andy Stadler - Cleanup eclipse .classpath for Gallery2
•Scott Main - docs: redirect next steps to building first app class
Project name: /platform/cts
•Leo Liao - DO NOT MERGE Add missing features of JB and JB MR1
•Leo Liao - Add missing features of JELLY_BEAN to feature list
•Brian Muramatsu - Updated Holo test assets for JB MR1
•Nick Kralevich - FileSystemPermissionTest: add directories
•Brian Muramatsu - DO NOT MERGE Update CTS Verifier to R4
•Brian Muramatsu - DO NOT MERGE Update CTS Verifier to R5
•Laurent Tu - Restore CtsVerifier rate for passive updates
•Brian Muramatsu - Some Holo Test Improvements
•Nick Kralevich - Try reading every file on /sys
•Brian Muramatsu - DO NOT MERGE Update CTS Verifier version again
•Marco Nelissen - Improve testSetNextMediaPlayer test
•Brian Muramatsu - DO NOT MERGE Update CTS Verifier version to 4.2 R3
•Brian Muramatsu - DO NOT MERGE Update CTS Verifier version to 4.1_R4
•Laurent Tu - Assert mean and stdev of update deltas
•Nick Kralevich - Add CVE to Exynos vulnerability test.
•Brian Muramatsu - DO NOT MERGE Update CTS Verifier Version to 4.1_R3
•Laurent Tu - DO NOT MERGE Relax LocationVerifier assertions.
•steven_huang - DO NOT MERGE Filter out the overdue location cases in GPS test
•Brian Muramatsu - DO NOT MERGE Update CTS Verifier Version to 4.2_r2
•Laurent Tu - DO NOT MERGE Relax LocationVerifier assertions.
•Brian Muramatsu - DO NOT MERGE Update CTS Verifier Version to 4.2_r2
•Laurent Tu - DO NOT MERGE Relax LocationVerifier assertions.
•Brian Muramatsu - DO NOT MERGE Update CTS Verifier Version to 4.1_R3
•Laurent Tu - DO NOT MERGE Relax LocationVerifier assertions.
•steven_huang - DO NOT MERGE Filter out the overdue location cases in GPS test
•Nick Kralevich - Add Exynos vulnerability tests.
•Adam Momtaz - CTS tests for UiAutomator at API 17
•Marco Nelissen - Add test for MediaScanner misbehavior
•Andreas Huber - Add a CTS test that iterates through all codecs using MediaCodecList and
•Andreas Huber - Adds a CTS test verifying audio encoder functionality. (AAC, AMR-NB, AMR-WB)
•Adam Momtaz - Fixed a mistakenly deleted line from the last submit
•Marco Nelissen - Fix ringtone test
•Brian Muramatsu - Update BuildVersionTest to support 4.2.2
•Fabrice Di Meglio - Fix bug #7664208 android.widget.cts.TextViewTest#testResetTextAlignment failures on JD
•Eino-Ville Talvala - CTS Verifier: Fix Camera Formats preview orientation.
•Fabrice Di Meglio - Fix bug #7664305 android.widget.cts.TextViewTest#testResetTextDirection failures on JD
•Adam Momtaz - UiAutomator test APK and Tests for CTS
•Fabrice Di Meglio - Add more CTS tests for the reset of RTL properties
•Keun young Park - DO NOR MERGE make reboot default in CTS (merge from mr1)
•Keun young Park - add log to print time-out when time-out happens
•Nick Kralevich - Add more tests for restricted broadcasts.
•Keun young Park - add 4.2.1 to version list
•Svetoslav Ganov - Cannot move edit text cursor to first position using character granularity.
•Keun young Park - change all file writes to random access with O_SYNC
•Brett Chabot - Add UiAutomator test skeleton to CTS.
•Svetoslav Ganov - Fix the shell commands used to clean up after the accessibility tests.
•Svetoslav Ganov - Add NumberPicker CTS tests.
•Nick Kralevich - FileSystemPermissionTest: Expand block device tests.
•Keun young Park - force reboot after accessibility test
•Guru Nagarajan - Version number for CTS 4.2 modified: tools/tradefed-host/src/com/android/cts/tradefed/build/CtsBuildProvider.java
•Brian Muramatsu - Report suite name to result server
•Igor Murashkin - Camera: New test to check app firing intent after capturing picture/video
Project name: /platform/prebuilts/sdk
•Ying Wang - Drop official SDK 17
Project name: /platform/prebuilts/misc
•Brett Chabot - Manually update tradefed prebuilt from jb.
•Xavier Ducrohet - Update Layoutlib_api to API 9. do not merge.
Project name: /platform/hardware/libhardware
•Mathias Agopian - Fix HWC documentation.
Project name: /platform/hardware/libhardware_legacy
•Eric Laurent - audio policy: notification delay - DO NOT MERGE
•Eric Laurent - audio policy: fix volume problem - DO NOT MERGE
•John Grossman - audio policy: fix dynamic parameter - DO NOT MERGE
•Jason Simmons - audio policy: direct output fix - DO NOT MERGE
•Irfan Sheriff - Fix stop supplicant api
Project name: /platform/hardware/ril
•Wink Saville - Update documenation for DATA_REGISTRATION_STATE
remaining Can be view here -> [URL="https://gist.github.com/archon810/4772945#file-changelog_android-4-2-1_r1-2_android-4-2-2_r1-txt"]ile-changelog_android-4-2-1_r1-2_android-4-2-2_r1-txt[/URL]
Detailed Changelog
Full_changelog_android-4.2.1_r1.2_android-4.2.2_r1.txt
Source: Android Police

Thanks for change log, I have not yet received the update but know that flashing will be good to get a fresh start.

nexus4?

Android 4.2.2 adds new sounds and notification toggles
Android 4.2.2 adds new sounds and notification toggles​
Why just the other day, we told you that Android 4.2.2 was being sent out to the Google Nexus 10, Google Nexus 7 and the Samsung GALAXY Nexus. While there has not yet been any changelist, we do have some information from those who have installed it on their tablet or phone. First of all, there is a new notification bar that shows you the time remaining and the percentage left of an in-progress app download. A change to Quick Settings lets you long press on the Bluetooth or Wi-Fi square to turn them into toggle switches. Now here is where it gets confusing. The Airplane Mode box is a single press toggle while some boxes do not change any settings.
Calculate speed of in-progress downloads and estimate time remaining until completion. Uses a moving average that is weighted 1:1 with the most recent 500ms sample. Funnels timing data to notifications through DownloadHandler."-How Google calculates the time remaining of an app download
Click to expand...
Click to collapse
Android 4.2.2 also brings a couple of new sounds, The two short bursts that tell you that your battery is low has been replaced while there is now a sound for wireless charging. Previously, the latter had no sound at all.
It should be interesting to see how the Android 4.2.2 update affects the next distribution data from Google. Also, we could see Android 4.0 drop more as some devices get updated to Android 4.1. The large chunk of Android users sporting a device powered by Gingerbread is only going to dissipate slowly as those owners start to upgrade once their 2-year contract expires. Those Android 2.3 phones will be replaced by Android 4.1 by the time the updates are in full swing, providing another reason to expect Ice Cream Sandwich to continue to melt.
If you have installed the Android 4.2.2 update on any of your devices, drop us a comment with some of the other changes that you might have noticed.
Source: PhoneArena

The Nexus 4 Finally Gets Android 4.2.2 (JDQ39) As Well - Here Are Instructions For In
ctakah27 said:
nexus4?
Click to expand...
Click to collapse
The Nexus 4 Finally Gets Android 4.2.2 (JDQ39) As Well - Here Are Instructions For Installing It Manually​
Good news, everyone! The Nexus 4 Android 4.2.2 OTA (JDQ39) is finally here, surprisingly late in the update cycle, following the Nexus 10 and older Nexus devices, such as both variants of the Nexus 7 and both variants of the Galaxy Nexus. Chances are you probably don't have the coveted update notification just yet, but who wants to wait if you can sideload it manually? Rooted, unrooted, stock or custom recovery - it matters not.
What's New?
To see what's new in Android 4.2.2, see New Android 4.2.2 Features: Toggle From Quick Settings, Better App Download Notifications, and Some New Sounds!
Code:
[B]Heads up:[/B] There is also a new radio in this update.
Prerequisites
Your device should be running build JOP40D before trying to install the update manually. If you for some reason don't have JOP40D, Google has it available in factory image form here.
For those ready to download and install manually, the process is easy. If you
have a custom recovery, just download the zip (linked below), move it to your device, and flash as usual
have the stock recovery or a custom recovery that supports sideloading, keep the zip file on your computer and follow a few easy instructions below
Manual Instructions
Step 1.
Reboot your Nexus 4, holding the Volume Down button while it boots up. Once you see the fastboot menu and "Start," press Volume Up to navigate to "Recovery" and press the power button. Once you see an Android with a red exclamation point icon, hold Power and press Volume Up a few times, which will bring you to a new menu. Navigate to "apply update from adb."
Step 2.
Connect your Nexus 4 to your computer with a USB cable.
Make sure you have a recent version of adb that supports the sideload command (if you don't, download the latest Android SDK to ensure your adb is up-to-date).
Open up a command prompt (cmd in Windows, regular shell in Linux and Mac) in the same directory as the zip file you've downloaded.
Type in the following:
Code:
adb sideload de8b8d101614.signed-occam-JDQ39-from-JOP40D.de8b8d10.zip
You should see a progress bar, which will eventually hit 100%. At this point, your device is installing the update.
Step 3.
Reboot and enjoy! You are now running Android 4.2.2 on your Nexus 4.
Download
Here's the OTA, hosted on Google's servers: build JDQ39.
MD5: 1c752738f65acfd48f2d3b6e6e11a654
File size: 51.0 MB (53,529,568 bytes)
Source: AndroidPolice

Thank You
Thanks for change log!

rishabhgangwar said:
Thanks for change log!
Click to expand...
Click to collapse
Pressing thanks button can speak louder then words in Xda buddy..

question
do we need to wipe data to complete this action? is there any problem could face SDCARD folder?

New 4.3 Update found Check the OP.:good:
Breaking: Android 4.3 For Google Nexus 4 Leaks (JWR66N) - Here's The System Dump

Disturbed™ said:
New 4.3 Update found Check the OP.:good:
Breaking: Android 4.3 For Google Nexus 4 Leaks (JWR66N) - Here's The System Dump
Click to expand...
Click to collapse
thanks for the convincing statements :good:

[GUIDE] Proxyme - Android System Access Tool

The purpose of this thread is to provide a guide for users who have Proxyme preloaded in their device's firmware and want to find out how to use it effectively. Ideally, this will be a place to share experiences and ideas to further improve the tool and provide solutions to problems that people may have.
Introduction
Proxyme ( proc-zahym ) represents a system access solution comprised of the following components:
System service - provides access to privileged system environment
SSH daemon - provides secure shell (ssh) and file (scp) access (based on dropbear)
proxyme.apk - user interface module
This solution is offered as a preloaded option in firmware images and consequently cannot (should not) be installed as a regular app, either from the Play Store or being side loaded. The reason for pre-loading stems from the requirements of the system service component to be able to integrate at system level and not be bound by operating restrictions within the Android application and framework platform environment (Zygote and Dalvik sandbox). The Play Store has been enlisted as the primary and preferred source in providing updates to the user interface component; the actual app you will be interacting with.
Proxyme offers the following functionality through its user interface:
Installation/de-installation of the su binary to provide/remove root access
(useful only for other applications which require root level access)
The persistent behaviour of the su binary can be controlled by a one-shot switch
Register/de-register tag-along scripts for su enable and disable actions
(more details on this below)
Control availability and location of busybox toolbox
Start/Stop SSH daemon
Configure listening port for the SSH daemon
Configure user accounts for the SSH daemon
Submit and execute a shell script
SU Binary
The option to enable or disable the su binary switch (on/off) in the user interface is the equivalent of rooting and unrooting the device. When enabled, you are providing root access to apps which require it to perform correctly. Currently, Proxyme does not have built-in support for monitoring and 'policing' the actual access to root.
Auto Root @ Boot
This switch in the Proxyme app allows you to indicate whether the su binary should be installed or removed during a reboot or startup of the device. Setting it to the 'on' position will make the su binary persistent throughout reboot cycles and leave your phone permanently 'rooted'.
Registering Tag-along Scripts
Whenever you enable or disable the su binary with the on/off switch in the user interface, there exists an option to execute a user script just prior to and one unique to each action. This is possible by pre-registering a script for one of or both enable/disable actions. A script can virtually perform anything and is always executed within root context. Note that you must be very cautious about the scripts you are registering and be certain about their intentions, because a rogue script could cause irreparable damage to you device.
Each script has the option to override, and thus block, the intended action (enable or disable) by setting a system property named proxyme.override to anything but blank.
One purpose of having tag-along scripts would be to 'freeze' and 'unfreeze' specific root-shy apps, which do not 'like' rooted systems. This is one area where we can share the experience of pre-coded scripts for certain target apps and I do hope it will be put to good use.
To submit a script file, tap on one of the SU Enable Script or SU Disable Script text elements to start browsing for a file.
Busybox
Busybox is just that, busybox. Options are available to determine one of two hard-configured locations where it can be installed and to enable or disable it.
More to follow later...
SSH Daemon
The SSH daemon is based on dropbear. It has been modified to support logon accounts in Android, which are configured with the following parameters:
username
password
home directory
which shell to use
user ID
group ID
For whatever reasons, you can restrict access by specifying non-root user and group (0:0) IDs. The IDs you can choose from are derived from a system list which was used and known within Android at the moment of booting the device. If you have installed new apps in the meantime and would like to use their newly assigned IDs, then please reboot the phone to update this list.
Executing Shell Scripts
The ability to submit and execute a shell script from the user interface can be considered a convenient and quick way to get some tasks done. Take note however that your scripts are run in a privileged environment under the root account and that there are risks involved. A rogue or insufficiently tested script can cause major problems if/when it makes changes to key system partitions, which are normally mounted read only for obvious reasons.
Most rom images will include a sample de-bloating script,which removes ROM specific branding apps. The script. /sdcard/Proxyme/debloat.sh, shows how this is done and could serve as a base for more extensive clean-up of firmware components, if you so desire.
Operational Notes
Whenever a device boots from a factory reset condition (i.e. after wiping data), there will be no UID/GID list available in the user management screen. The reason for this is that the SuMeD setup process will complete before the app data store, the location where aforementioned list is stored. has been initialised. Restart the device in order to make this list available.
Behind The Scenes
For details regarding how Proxyme's system service components are integrated in a firmware image, please follow this trail...
Device Support
Before taking the next step to flash your phone/device, please be aware of the risks involved with performing such an operation. Prepare the device properly, i.e. sufficient battery charge, and be well informed of the correct flashing procedure(s) for your device's make and model. On Samsung devices, rooting will probably trigger 'custom' flag(s) and consequently render the warranty void. No matter how adventurous you may feel, it is always a bad idea to try to flash a firmware image which is not intended for your device. Having said all that, note that you will be flashing your phone at your own risk. You are solely responsible for anything you do to your phone/device, so make sure you are well informed and well prepared before deciding to flash or install anything on it.
The following list will be updated as soon as new firmware images are prepared for new and old devices.
Samsung Galaxy Note 10.1 2014
SM-P600 - (reference post)
Samsung Galaxy J
SC-02F (Docomo) - (reference thread)
SGH-N075T (Taiwan) - (reference thread)
Samsung Note 3
SM-N9005 - (reference post)
SM-N900A - (reference post - unconfirmed)
Samsung Galaxy S4
SHV-E330K - (reference thread)
SHV-E330L - (reference thread)
SHV-E330S - (reference thread)
SGH-I337 - (reference post - unconfirmed)
SC-04E - (reference post)
Samsung Galaxy Grand 2
SM-G710L - (reference post)
Samsung Galaxy S3
GT-I9300 - (reference post)
SC-03E - (reference thread)
SHV-E210K - (reference thread)
SHV-E210L - (reference thread)
SHV-E210S - (reference post)
SHW-M440S - (reference post)
Samsung Galaxy S2 LTE
SHV-E110S - (reference thread)
Samsung Galaxy S2
SHW-M250K - (reference post)
Planned Changes
built-in control of su access (much like what Superuser currently does)
choice of built-in simple file browser or use intents to initiate external app(s) for browsing and selecting files
...

Proxyme - Behind The Scenes
This section details how Proxyme's system service components are integrated in a firmware image.
If you are not up to speed with how a typical Android system is constructed, then I would like to suggest you at least make yourself familiar with this topic in order to fully understand what to do with the following text.
The system service components are integrated in the /system partition (mount point) in Android. In the case of changing a live system this will require mounting the appropriate partition read/write before applying the updates. If a static firmware image is to be updated, then extract the component which represents the /system partition from the package and apply the updates before re-packing the firmware image.
The following list describes the major system service components:
hijacker - this is a module you need to write, which has the role of initiating the system service in a privileged environment.
hjprepper - this module is started by the hijacker to prepare the environment prior to starting SuMeD
SuMeD - this one is what it's all about. The Proxyme app relies on this daemon to be up and running in order to perform any of its privileged functions
SSHD - the SSH daemon is represented by an updated implementation of dropbear on Android
Hijacker
The hijacker is a program you would normally have to write to replace an existing program in your rom, which is started during the boot process by for example initd. This part of the integration process requires your (creative) input, since you need to analyse the rom you are working on and figure out how and where to position the hijacker module. If you do find an existing module to hijack, make sure to always call that original module from your hijacker once it has managed to execute the hjprepper program. In some roms it suffices to start hjprepper from a shell script, which is run with root access... they exist, you just have to look for them.
This is what your hijacker could look like in C
Code:
#define PROP_HIJACK "proxyme.hijack.system"
#define HIJACKEE "/system/bin/original-program"
#define PREPPER "/system/xbin/hjprepper"
int main( int argc, char *argv[] )
{
char *lArgv[5];
char **lArgList;
int lArgCnt;
pid_t pid;
lArgList = (char **)malloc( sizeof(void *) * (argc + 1) );
for ( lArgCnt = 0; lArgCnt < argc; lArgCnt++ )
{
lArgList[ lArgCnt ] = argv[ lArgCnt ];
}
lArgList[ lArgCnt ] = NULL;
/* Fork parent process */
pid = fork();
if ( pid < 0 )
{
property_set( PROP_HIJACK, (char *)"Hijacker Startup... spawning failed, prep first before xfer" );
system( "/system/xbin/hjprepper" );
execv( HIJACKEE, lArgv );
exit( EXIT_SUCCESS );
}
else if ( pid > 0 )
{
property_set( PROP_HIJACK, (char *)"Hijacker startup... spawned, parent ascends phase 2" );
execv( HIJACKEE, lArgv );
exit( EXIT_SUCCESS );
}
if ( execl(PREPPER, PREPPER, (char *)NULL) < 0 )
{
property_set( PROP_HIJACK, (char *)"Hijacker startup... failed to call prepper" );
}
exit( EXIT_SUCCESS );
}
hjprepper
This program is responsible for setting up an operating environment for the SuMeD daemon. If you have full control over a rom's boot image, then include a call in your init process to start this module once during boot. If not, then use a hijacker program or look for existing and suitable scripts to initiate hjprepper.
hjprepper starts the SuMeD daemon once it completes the setup and configuration procedure.
SuMeD
This bad boy is responsible for the user requested actions through interaction with the Proxyme app.
Prebuilt Packages
To get you started, there are pre-built modules available,which you can download here. Currently, availability is limited to Android 4.3 and 4.4.2 only. The following zip archives are organized in a folder tree structure,which serves as a guide for where to place the modules within the /system path.
4.3 Prebuilts
4.4.2 Prebuilts

Filler 2
Filler 2

Filler 3
Filler 3

Please add support in latest SHV-E110S 4.1.2 rom(s)
Title says/asks it all...

Can You guide build pre-rooted rom by proxyme? Thank you very much.

linhbs said:
Can You guide build pre-rooted rom by proxyme? Thank you very much.
Click to expand...
Click to collapse
Behind The Scenes section has been added to the OP.

Can this method be used to prebuilts S3, S4, Note3 not Korea? Thanks so much.

linhbs said:
Can this method be used to prebuilts S3, S4, Note3 not Korea? Thanks so much.
Click to expand...
Click to collapse
Yes. You need to figure out how to get the SuMeD daemon started and that depends on the rom you want to integrate it in. The Behind The Scenes post highlights what areas to focus on when doing this.
Note that the first post includes 2 firmware images (both Android 4.3 and 4.4.2) for the international Note3 (SM-N9005). It's a no-brainer to copy the files from the appropriate directories to an equivalent and same level version firmware for another region of the same device.

Please add support N900A 4.4.2. Thank you very much.

linhbs said:
Please add support N900A 4.4.2. Thank you very much.
Click to expand...
Click to collapse
Has 4.4.2 been released on that device? If yes, a download link for the official stock firmware will help speed up the process. If not, then we wait or you could send a PM to davidcsv with the 10 or 11 digit s/n and he will monitor and download the latest release as soon as it becomes available...after that your new firmware image will be uploaded within a day.

Link: http://www.androidfilehost.com/?fid=23321874045862490. Thank you for your interest!

linhbs said:
Link: http://www.androidfilehost.com/?fid=23321874045862490. Thank you for your interest!
Click to expand...
Click to collapse
N900AUCECMLG (preloaded with Proxyme) (2014-01-04)
This rom implicitly performs a factory reset, so backup your data before flashing it. Unpack the zip archive and specify the resulting .tar.md5 filename in the PDA/AP section of the latest version of Odin.
Use Proxyme to execute the /sdcard/Proxyme/debloat.sh script to get rid of the k n o x messages.
mega.co.nz
torrent, mirror
Apparently, this firmware image is a pre-release/leaked image and not the final deal. It includes an updated bootloader and related components, meaning that it will not be straightforward to revert back to an older version of the firmware. If you encounter problems with this Proxyme preloaded image, then I'd suggest flashing the image from the original download link.
All feedback is welcome and will be appreciated. Enjoy!

Thank you very much. I ask you to add proxyme in I337 4.4.2 rom. Thank you very much.
Link: http://www.androidfilehost.com/?fid=23329332407566813

linhbs said:
Thank you very much. I ask you to add proxyme in I337 4.4.2 rom. Thank you very much.
Link: http://www.androidfilehost.com/?fid=23329332407566813
Click to expand...
Click to collapse
I337UCUFMLD (preloaded with Proxyme) (2014-01-02)
This rom implicitly performs a factory reset, so backup your data before flashing it. Unpack the zip archive and specify the resulting .tar.md5 filename in the PDA/AP section of the latest version of Odin.
Use Proxyme to execute the /sdcard/Proxyme/debloat.sh script to get rid of the k n o x messages.
mega.co.nz
torrent, mirror
Apparently, this firmware image is also a pre-release/leaked image and not the final deal. It too includes an updated bootloader and related components, meaning that it will not be straightforward to revert back to an older version of the firmware. If you encounter problems with this Proxyme preloaded image, then I'd suggest flashing the image from the original download link. A Google search shows that this image does have a few minor issues, so beware.
All feedback is welcome and will be appreciated. Enjoy!

Thank so much. I find the phone test. Will respond to you.

SC-04E Stock Firmware Proxyme Rooter images
Root Ready Stock Images
(Unfortunately, flashing these ROMs will trigger KNOX)
Kitkat 4.4
SC04EOMUFNI3 (Proxyme) (Build Date 2014-09-19)
This zip archive contains an Odin flashable file. It is not the complete stock image, so you MUST have OMUFNI3 already running on your phone or you will need to download it from the above reference sites, which carry complete stock firmware images, and flash it before continuing with this file. Instructions are included in the zip archive.
uploaded.net
mediafire
torrent, mirror2

I337:
- Before flash rom: I337UCUEMK2 version 4.3
- After flash rom I337UCUFMLD (preloaded with Proxyme) fail.

Good.

linhbs said:
I337:
- Before flash rom: I337UCUEMK2 version 4.3
- After flash rom I337UCUFMLD (preloaded with Proxyme) fail.
Click to expand...
Click to collapse
Please post the complete log from the message box in Odin. One more question, is your phone 16GB or 32GB model?
update: and also try again with newer version of Odin v3.09 instead of v3.07

PLZ HELP: Malware Infestation on Lenovo A5500-HV Tab

model number : lenovo a5500-hv
android version: 4.4.2
baseband version: a5500-hv.v34, 2014/05/08 22:28
kernel version: 3.4.67
build number: a5500hv_a442_000_011_140508_row
As shared in subject, my tab ANDROID is infected by malware where multiple issues have starting lately
a) Constant popup message stating" Unfortunately, com.system.update has stopped"
b) Constant popup message stating" Unfortunately, org.snow.down.update has stopped"
c) Constant popup displaying to INSTALL application" com.android.keyguard"
d) Automatic checking (on) in Settings> Security> Allow installation of apps from unknown sources, despite my regular check off( its gets reactivated again). Device Administrators viewed are Android Device Manager (ticked), Daemon Service( twice listed- unchecked).
e) Installed Malwarebytes Anti-malware, upon scanning detected these 11 malwares, which it is unable to delete ( Norton is unable to detect those even). Any open app which I try to use after some seconds are abruptly closed.
Malware name- Path
Android/ Backdoor.Triada.c - /system/priv-app/higher.apk ( File linked to be uninstalled- AppManage)
Android/ Backdoor.Triada.js - /system/priv-app/BCTService.apk ( File linked to be uninstalled- bcct_service)
Android/ Trojan.Rootnik.I - /system/priv-app/Bseting.apk ( File linked to be uninstalled- com.android.sync)
Android/ Trojan.SMSSend.ge - /system/app/com.android.token.apk ( File linked to be uninstalled- com.android.taken)
Android/ Trojan.OveeAd.F - /system/priv-app/com.mws.tqy.vsdp.apk ( File linked to be uninstalled- com.system.update)
Android/ Backdoor.Triada.J - /system/priv-app/com_android_goglemap_services.apk ( File linked to be uninstalled- GoogleMapService)
Android/Trojan.Dropper.Shedun.dc - /system/priv-app/parlmast.apk ( File linked to be uninstalled- GuardService)
Android/Trojan.Dropper.Agent.MJ - /system/priv-apk/Sooner.apk ( File linked to be uninstalled- PhoneService)
Android/Trojan.OveeAd.J - /system/priv-apk/com.tsr.eny.hyu.apk ( File linked to be uninstalled- system.bin)
Android/Trojan.Guerrilla.Q - /system/priv-apk/NAT.apk ( File linked to be uninstalled- SysTool)
Android/Trojan.Triada.m - /system/priv-apk/com.glb.filemanager.apk ( File linked to be uninstalled- UPDATE)
PS: If I try to connect to Internet, app icons are downloaded and auto open displaying porn images.
Please assist to REMOVE the MALWARE INFECTION. Tried FACTORY DATA RESET from Settings, but no help. Tab not Rooted

Did research, Tried cm's stubborn Trojan remover from play store and it did the trick- as in disabled the infected processes but at end took my mail ID with followup request if raised to get the device cleaned from malware. Cross checked from Malwarebytes and kaspersky, and looks seemingly clean with no active culprits. Though not checked with WiFi or data connection through sim.
Sent from my A0001 using XDA-Developers mobile app

Seems after removing app (due to questionable reputation) malware's came back.
Sent from my A0001 using XDA-Developers mobile app