I bought this phone cheap, for £85. http://techan0.blogspot.co.uk/2015/07/on-buying-mlais-m52-red-note-mt6752-and.html. Anything cheaper I would have immediately regretted, believe me I've made that mistake many times. Anything much more expensive and I'd have felt the pinch of staggering depreciation and let down when the manufacturer abandoned us for their latest "flagship".
I'm calling time on this phone despite it being my daily work horse (that's hardly a compliment considering the abuse I dish it when writing apps). It has been over three months since an official update, it's been six months since a version update (4.4 to 5.0). There have actually been more version updates for this phone than the hugely popular Lenovo A820 I had before. It's just that things move on so fast these days that no manufacturer offers long term support to keep up with Google. It's rare that a phone is so successful that the community take it upon themselves to push quality updates (as recently exhibited in I.nfraR.ed's A820 KitKat ROM).
The M52, despite my best efforts, has not been such a success to date. The budget end of the high spec phablet market is overcrowded, there is so much choice that phone design is practically left to the consumer. There is a nuance for every taste. I chose the M52 because plastic is cheaper and is easier for the radio signal to penetrate. I think I was in the minority with Mlais on this.
The most tangible failing of this phone, arguably, totally acceptable for the price. Some view it as a product of Mlais' inexperience in the design of phones (ie a design flaw rather than compromise). I am referring to the white patches on the screen. It makes an already unprepossessing phone rather more ugly. It's a matter of taste, but for a work horse, I'm still amazed by the high quality camera, totally legible screen and freedom from bloat-ware and lag.
There is work afoot (in Russian!) regarding a 5.1 port to this phone. Personally I don't see any need for the upgrade. Like the A820 skipping 4.2 and 4.3. If 6.0 brought big changes I might work on that port, software support is overrated when it seems to be mostly bug and security fixes.
Corporate users may require this for their valuable data, but they're probably the people most likely to bank roll Apple for the sake of inspiring (false) confidence in their clients. I certainly can't see any of them taking a free upgrade of unknown provenance.
I'm signing off the MTK phones blog for a bit as I want to broaden my interests. I'll surely be back when I next upgrade.
Monday 19 October 2015
Sunday 16 August 2015
Proguard Observations: bundling assets in assets not raw (since Android Studio)
I love Proguard. For years I stuck religiously to C and C++. After some of my work got loose in the wild I began to appreciate the commercial merits of Java. At the very least in Android.
When your C code tombstones might as well have occurred in some one else's code you are depending on it makes sense to stick with the hurd, that's Java. My mixed mode apps did not focus on making my Java private, I had relied on C and C++ for that. Android Studio abandoned C / C++ development.
Proguard can be made to work very easily in Android Studio. Me saying this and you observing are 2 completely different things so I encourage you to learn about reverse engineering with apktool. You will probably have already used Google's own reverse engineering tools day to day when you view read-only source code from a decompiled library.
Apktool produces smali that is architecturally equivalent to the original obfuscated Java. Obfuscation is Proguard's thing. Smali has the distinct advantage of being amenable to direct recompilation from apktool itself. Apktool is the most frequently updated reverse engineering tool external to Google (developed by iBotPeaches from XDA). Smali is still obscure though. I've seen so little of it in books and tutorials that I wonder just how removed from Java byte code it can actually be. Keep your sanity and relevance, without having to learn smali. Other tools, especially dex2jar and JD-GUI do the business of reverse engineering. Using these I was able to make the following observations about proguard and Android Studio.
Problem
I have an html file in res/raw:
By default res/raw links from generated 'R' files are broken by proguard. Trying the following option doesn't help this
Eric Lafortune alluded to there being reasons for Proguard's default behaviour somewhere on SO. The following is needed but it means all aliases from the massive 'R' file are readily accessible to a decompiler:
Solution 1: try using res/assets instead of res/raw
This has exactly the same effect. The page doesn't load after proguard. I know I can hard link the HTML string but for now I need to document this bug so I don't return to it later.
To be thorough, I tried just
and using the asset (assets) directory. This time I can see that all the R$* classes are present in the rev-eng'd project. All except the R$raw I'd just obviated. No R$assets? No nothing. I must be doing something wrong, and I was.
Ignoring CommonsWare earlier advice:
On a seperate thread his wisdom shone:
Or they might not.
When your C code tombstones might as well have occurred in some one else's code you are depending on it makes sense to stick with the hurd, that's Java. My mixed mode apps did not focus on making my Java private, I had relied on C and C++ for that. Android Studio abandoned C / C++ development.
Proguard can be made to work very easily in Android Studio. Me saying this and you observing are 2 completely different things so I encourage you to learn about reverse engineering with apktool. You will probably have already used Google's own reverse engineering tools day to day when you view read-only source code from a decompiled library.
Apktool produces smali that is architecturally equivalent to the original obfuscated Java. Obfuscation is Proguard's thing. Smali has the distinct advantage of being amenable to direct recompilation from apktool itself. Apktool is the most frequently updated reverse engineering tool external to Google (developed by iBotPeaches from XDA). Smali is still obscure though. I've seen so little of it in books and tutorials that I wonder just how removed from Java byte code it can actually be. Keep your sanity and relevance, without having to learn smali. Other tools, especially dex2jar and JD-GUI do the business of reverse engineering. Using these I was able to make the following observations about proguard and Android Studio.
Problem
I have an html file in res/raw:
By default res/raw links from generated 'R' files are broken by proguard. Trying the following option doesn't help this
-keep class *.R
Eric Lafortune alluded to there being reasons for Proguard's default behaviour somewhere on SO. The following is needed but it means all aliases from the massive 'R' file are readily accessible to a decompiler:
-keep class *.R -keepclasseswithmembers class **.R$* {public static <fields>;}
Solution 1: try using res/assets instead of res/raw
myWebView.loadUrl("file:///android_asset/help.html");
This has exactly the same effect. The page doesn't load after proguard. I know I can hard link the HTML string but for now I need to document this bug so I don't return to it later.
To be thorough, I tried just
-keepclasseswithmembers class **.R$* {public static <fields>;}
and using the asset (assets) directory. This time I can see that all the R$* classes are present in the rev-eng'd project. All except the R$raw I'd just obviated. No R$assets? No nothing. I must be doing something wrong, and I was.
Ignoring CommonsWare earlier advice:
I am asking this because if you have a button with an id btnSaveArticle, for a hacker it becomes too easy to grasp what the code around is doing by looking at the name.
Using Hierarchy View, it would take them less than 30 seconds to determine the actual ID of the "Save Article" button, no matter what you name it. And I can envision even faster solutions with a bit of custom tooling.
am I wasting my time?IMHO, yes.
answered Aug 16 '13 at 12:54CommonsWare
On a seperate thread his wisdom shone:
Since Android Studio uses the new Gradle-based build system, you should be puttingOf course I am still wasting mine and my user's time because placing the html in assets prevents it from accessing other folders, where, for example, icons might be found.assets/inside of the source sets (e.g.,src/main/assets/), if I understand correctly.
Or they might not.
MLais M52 Teardown
I got stuck trying to swap SIMs and decided the put on engineers that delivered this bargain machine for £85 had not tested this and that the pins had some how bent to deny me access. As will become apparent it was the metal girdle pressing the SIM card against the contacts that was the culprit, or, more specifically, a wayward curl of plastic from the SIM itself blocking (easily removed with a sharp blade).
Anyway, on with the teardown:
The boards are visible after the usual procedure to remove the back plastic:
Both camera modules are instantly accessible and should their interface ever become standardised (#ahem# #project ara# #ahem#) we could find drop in replacements. I've been looking at many camera modules, for many uses, mostly for quad copters, and sadly nothing is standardised at the level of integration of flagship phone cameras.
Got your cameras out and away from dust and harm? Good. These are the locations (drawn in mauve) of the electrical connections that must be unfastened for the circuit board to be levered out.
That's showing them undone. I should go through them one by one so you needn't sweat it about breaking any when you try. Does anyone still do this or is it just the Know-How team at PC World when they grade their computers refurbished? Here goes, clockwise from the power button at the bottom left.
With the 4 screws removed one proceeds to lever the PCB up from the top, be very careful at the bottom because there is a broad ribbon I couldn't find a way to disconnect running behind the battery. I must record here, because it isn't in any of my pictures, that I couldn't find how to undo this last connector, on my Lenovo teardown it's a vertical plug in connector like the two camera modules here.
This is the rear of the PCB in all its glory. The blue square is very likely masking the MT6572, I can see the beginning of an M and it is right the size and place with enough attention given to cooling. Trying to remove the blue foam leaves a layer on the chip which isn't convenient when all the while that stubborn last ribbon is the last link between PCB and phone. With more experience and motivation I'm sure I could deal with both obstacles.
The chip models might be some use to ROM developers so here they all are beginning from the front:
What's this? Behind a heatsink the inscription,
6671122.1
1510 NX
is visible (or HX or even MX)
GOODIX
GT9157
1443-B37A
147C1200
E5L 401 xxxx (or E5I)
see http://www.goodix.com/Products/touchscreen-chip-for-mobilephone/hotknot/
This is our touchscreen controller and supports a form of NFC screentouch communication called "HotKnot" (probably only with other GT9157s)
Primary camera, ribbon marking is
JAL-JBL
-A128B
(8604)
Front camera ribbon markings:
JAL-JBL-
A128F(4-8)
a radio transceiver
MEDIATEK
MT6169V
1513-AMTH
BTP2NV39
The 2Gb DDR3 ram
SAMSUNG 516
KMR820001M-B609
Some probably unique number.
Other phones with the MT6169V
Pioneer K88L
Meizu-MX4
TCL Momoda 4G
After reading some other teardowns I notice that they aren't so easy to find and the MLais is not very anti-tamper for my part. There are some metal screens I didn't try very hard to look behind but much less than on equivalent phones, though the phones listed above do tend to have many more chips than I discovered, they are a bit older, or perhaps I am missing some.
Anyway, on with the teardown:
The boards are visible after the usual procedure to remove the back plastic:
- battery out, then hold the power to short any residual charge
- undo screws (about a dozen on this monster) including one with a security sticker on it, they can be tight so have a good bit
- nails or if they matter plastic like a toothpick
Both camera modules are instantly accessible and should their interface ever become standardised (#ahem# #project ara# #ahem#) we could find drop in replacements. I've been looking at many camera modules, for many uses, mostly for quad copters, and sadly nothing is standardised at the level of integration of flagship phone cameras.
Got your cameras out and away from dust and harm? Good. These are the locations (drawn in mauve) of the electrical connections that must be unfastened for the circuit board to be levered out.
That's showing them undone. I should go through them one by one so you needn't sweat it about breaking any when you try. Does anyone still do this or is it just the Know-How team at PC World when they grade their computers refurbished? Here goes, clockwise from the power button at the bottom left.
- Power button - tricky this as you kneed a sharp blade slid precisely along the plastic shell to lever up the flexible button. It will retain most of its stickyness and has mechanical fixation by other means.
- Wide ribbon - flip up the black lever where the cable enters.
- Main camera module - lift directly up applying even force if you're careful.
- Goodix orange chip ribbon - flip the black lever at the back where it pins the ribbon.
- Front camera - pull connector directly upwards, don't worry about the black tape on top, it isn't connected elsewhere
- Volume button ribbon - afforded its own ribbon connector! No expense spared! Like the Goodix connector of similar size, flip the black lever from the opposite side of cable entry
With the 4 screws removed one proceeds to lever the PCB up from the top, be very careful at the bottom because there is a broad ribbon I couldn't find a way to disconnect running behind the battery. I must record here, because it isn't in any of my pictures, that I couldn't find how to undo this last connector, on my Lenovo teardown it's a vertical plug in connector like the two camera modules here.
This is the rear of the PCB in all its glory. The blue square is very likely masking the MT6572, I can see the beginning of an M and it is right the size and place with enough attention given to cooling. Trying to remove the blue foam leaves a layer on the chip which isn't convenient when all the while that stubborn last ribbon is the last link between PCB and phone. With more experience and motivation I'm sure I could deal with both obstacles.
The chip models might be some use to ROM developers so here they all are beginning from the front:
6671122.1
1510 NX
is visible (or HX or even MX)
GT9157
1443-B37A
147C1200
E5L 401 xxxx (or E5I)
see http://www.goodix.com/Products/touchscreen-chip-for-mobilephone/hotknot/
This is our touchscreen controller and supports a form of NFC screentouch communication called "HotKnot" (probably only with other GT9157s)
JAL-JBL
-A128B
(8604)
JAL-JBL-
A128F(4-8)
On The Flip Side
MEDIATEK
MT6169V
1513-AMTH
BTP2NV39
SAMSUNG 516
KMR820001M-B609
Some probably unique number.
Other phones with the MT6169V
Pioneer K88L
Meizu-MX4
TCL Momoda 4G
After reading some other teardowns I notice that they aren't so easy to find and the MLais is not very anti-tamper for my part. There are some metal screens I didn't try very hard to look behind but much less than on equivalent phones, though the phones listed above do tend to have many more chips than I discovered, they are a bit older, or perhaps I am missing some.
Sunday 2 August 2015
Restore IMEI with IMEI&SN Writer
Restore Lenovo A820's IMEI with IMEI&SN Writer
If you don't understand something or have any doubts don't do it, I take no responsibility for relaying my experience here. This is taken from my much longer post Driver Sanity in Windows, Restoring IMEI to Lenovo A820 with all dead ends and fails removed. I can only support the single method tested herein.When I get a new MTK phone, the instructions for that don't consider I might already have drivers installed. This can lead to driver conflicts. Another thing you should beware of before asking for help is that you don't have devices flagged in Device Manager. If your Device Manager looks as flat as this:
Then this isn't a problem for you and you can continue to the Out With the Old (Unseen Driver Conflicts) section.
Install Missing Manufacturer / OEM (eg Dell, HP, Acer etc) Drivers
For years I put up with an unidentified, but disabled "Simple PCI communication interface" or "Simple PCI communication controller". Only after struggling to connect my phone on a VCOM/COM port did I decide keeping this motherboard device deactivated might be a bad idea. I dug out my original factory "drivers and apps" disk and put it in the DVD drive. About 3 minutes later it loaded :)It wasn't necessary to use the manufacturer's installer. I activated the offending hardware from device manager and either uninstalled it first or just showed it to my DVD drive (more on this process in just a moment, it is this process that is the crux of this document). Windows very efficiently installed just the driver and none of the bloat, it was a minor device I might have lived without.
Out With the Old (Unseen Driver Conflicts)
Consider the following where Lenovo Composite ADB Interface is in some way undesirable:
You may have previous installations cached allowing Windows to automagickly reinstall the device. Every time this happens repeat the above procedure to arrive at a "clean" installation w.r.t. this particular driver.
I stress this is only for third party drivers, things Windows or your OEM may have preinstalled, may be harder to find better/correct drivers for.
When Window's cache of drivers is empty it will either either ask you for one or list it in Device Manager with an exclamation mark nest to it. Job done.
Restoring IMEI
You'll notice in previous screenshots the "Ports (COM & LPT)" entry is displayed in Device Manager. The problem with my VCOM driver was that, initially, it was only fleetingly visible the instant a connection was made with the powered down phone. Device Manager would flicker, display the entry for a second, then flicker again removing all mention of "Ports (COM & LPT)". You have just a second to right click an offending driver. Once right clicked the clock stops and you can carefully click uninstall. Then tab away and check the instructions. If you have to open the "Ports (COM & LPT)" you'll almost certainly miss it and get frustrated fast. If you have something else there, that's one less click you need in that second. That's why my "Ports (COM & LPT)" is visible, a modem or (old) printer can be used for this purpose.This driver is essential for META mode to connect your phone with the low level MTK tools. The correct driver will maintain an entry in "Ports (COM & LPT)" all the while the phone is connected in META mode. My driver, from previous ROM upgrades and subsequent phone purchases proved incorrect.
To be sure of any driver's provenance you must uninstall all previous drivers as outlined in the Out With the Old (Unseen Driver Conflicts) section above. To know when Windows is ready for the correct driver watch for an exclamation mark on the entry, in the case of this particular device the entry will read, "MT65xx Preloader".
At this point you can install the new driver(s). The file I was given was DriverInstall_v5.14.53_WinXP_Win7.exe,
MD5: aefe6fc53400b8f9a313cbacd4a4f50b,published my MediaTek. When I go to install it Windows warns that the publisher is unknown. Continue as any other installation. When you are asked (in red!) to install an unsigned driver, go for it, four times! I think this is just MediaTek being cheap not getting MicroSoft to sign and test their drivers. MicroSoft's high false positive rate causes users to blithely dismiss all sorts of security warnings. I don't guarantee these drivers, I use them as do many others.
SHA1: 2f12e07f5785defb81e9f8ab7e501b5d951c8c0f
I'd actually just dismissed exactly four of these warnings installing for my other phone's ROM, with an entirely different installer, a script, so I "knew" what was happening. It would install the unsigned drivers first then install the signed ones over the top. Often signed drivers don't work so I was happy to try unsigned.
With just these drivers installed they should be sufficient to enter META mode. I'd never before been asked to install four consecutive unsigned drivers in a row, MLais publish a how-to telling me to do this, so now I do.
ADB Drivers
I believe my old VCOM driver was being supplied by the SP_Driver_v1.x pack and causing incompatibility. I can't describe how to install these and ADB drivers here, that is outside the scope of this article. Approved drivers are:sp_drivers_v1.5_lenovo.zip:
MD5: 2e9d1ca627056703f471f2bbe1b199eaI instead used SP_Drivers_EXE_v1.6 from Pakyto's "RESTAURAR IMEI.zip"
SHA1: 79bbc822e6af5d394ccabe229a8a2640bf146848
MD5: 0be4b2fb53c18d9bc392e5e4cc6f6972
SHA1: d483be492df8785efe00b4416e5f7ba9229895e8
Software Sources
I didn't ultimately use Pakyto's apdb_modemdb_A820 because the name of his Modem Database included P780 instead of A820.(from Pakyto)
BPLGUInfoCustomAppSrcP_MT6589_S00_P780_V23
MD5: 0f244cd43a65b9aee65a31b73cbcc00c
SHA1: c6a5a4102c77fbb2493323bc7c9ae9f458a506a7
APDB_MT6589_S01_MAIN2.1_W10.24
MD5: 80a45a9bb5bd5416692901de6974d871
SHA1: 76638fb9cd4234437a5c64f149134b9cb81bcae8
The following are more A820 specific:
(from https://yadi.sk/d/ylJyJbDjZWm7k, from http://www.mcrf.ru/forum/archive/index.php/t-36527.html)
apdb_modemdb_A820.7z
MD5: f770b3e08a5ec076b592493b38591d44
SHA1: 062578a596b90d05b1cf6a2c37bff324740cc3d6
BPLGUInfoCustomAppSrcP_MT6589_S00_A820_V16
MD5: f5a6a5a28ee227533ccb41c35e7155db
SHA1: 8d41e8d604cc9c4a750b7eb9305f641746d2691f
APDB_MT6589_S01_MAIN2.1_W10.24
MD5: 80a45a9bb5bd5416692901de6974d871
SHA1: 76638fb9cd4234437a5c64f149134b9cb81bcae8
from somewhere I found:
imei&sn writer v1.5.3.rar
MD5: 52f43ae9e73b2279493977ad4f9b68ac
SHA1: f15224419dd9bc440bc006ff53d5efef53fefed5
which contains the 2012 tool IMEI&SN Writer.exe
IMEI&SN Writer
It reported a success when I just flashed the IMEI:
Success, but I was too tired to remember to what extent. In any case it wasn't acceptable so I repeated with all the fields filled in and it fixed it.
For step 3, Select DB, use the files described above in Software Sources, or google "apdb_modemdb_A820" and see my checksums. Or try the following (verified).
IMEI&SN Writer V1.5.3.7z (3.25Mb)
MD5: 955fc522fd47376e6f7e3c6e3b1b9fc0
SHA1: dd6e0c0a80a57502c6d8fe2436dd6fc6a19e8798
apdb_modemdb_A820_20150729.7z (5.34Mb)
MD5: 6e6ee6541b5800e8386da1ba7436a9da
SHA1: e80700159bc31ba2d94cdfbfeb351b023e581e2f
Wednesday 29 July 2015
Driver Sanity in Windows, Restoring IMEI to Lenovo A820
Driver Sanity in Windows, wrt Restoring IMEI
This guide contains a lot of pictures and checksums, but also a lot of text. If you can't understand something or have any doubts don't do it, I take no responsibility for relaying my experiences here.I have countless drivers for my Lenovo A820. I collect them. At times I cull them, and keep what I need in 7zip archives.
When I get a new MTK phone, the instructions for that don't consider I might already have drivers installed. This can lead to driver conflicts. Another thing you should beware of before asking for help is that you don't have devices flagged in Device Manager. If your Device Manager looks as flat as this:
Then this isn't a problem for you and you can continue to the Out With the Old (Unseen Driver Conflicts) section.
Install Missing Manufacturer / OEM (eg Dell, HP, Acer etc) Drivers
For years I put up with an unidentified, but disabled "Simple PCI communication interface" or "Simple PCI communication controller". Only after struggling to connect my phone on a VCOM/COM port did I decide keeping this motherboard device deactivated might be a bad idea. I dug out my original factory "drivers and apps" disk and put it in the DVD drive. About 3 minutes later it loaded :)It wasn't necessary to use the manufacturer's installer. I activated the offending hardware from device manager and either uninstalled it first or just showed it to my DVD drive (more on this process in just a moment, it is this process that is the crux of this document). Windows very efficiently installed just the driver and none of the bloat, it was a minor device I might have lived without.
Out With the Old (Unseen Driver Conflicts)
Infrared taught me a very important lesson in driver management, which essentially saved me having to reinstall Windows or find another, cleaner installation.Consider the following:
The highlighted "Lenovo Composite ADB Interface" is not actually what Infrared used in his pdf tutorial, so obviously there is some flexibility, or his guide may, in my case, have been slightly off. Actually, for the purposes of restoring IMEI, I don't find this entry particularly useful; it only appears when Android is running and hence is not seen by low level tools like SN Station and "IMEI and SN Writer" that saved my IMEI.
I would not have been confident to delete all the drivers without Infrared's guidance and Windows would just install them again after each uninstallation.
Then delete the software which Windows will invariably have "kept safe" to "simplify" future installations.
You may have previous installations cached allowing Windows to automagikly reinstall the device. Every time this happens repeat the above procedure to arrive at a "clean" installation w.r.t. this particular driver. Awesome!
I stress this is only for third party drivers, things Windows or your OEM may have preinstalled, may be harder to find better/correct drivers for.
When Window's cache of drivers is empty it will either ask you for one or list it in Device Manager with an exclamation mark nest to it. Job done.
I can't tell you which driver you need for your procedure, its very likely device and possibly ROM specific.
Restoring IMEI
You'll notice in previous screenshots the "Ports (COM & LPT)" entry is displayed in Device Manager. This is because I had my modem in. It helped direct me where I needed to look to find the COM port for the phone. This was, for a long time, only visible fleetingly the instant a connection was made with the powered down phone. Device Manager would flicker once, display the entry for a second, then flicker twice more removing all mention of "Ports (COM & LPT)". You have just a second to right click an offending driver. Once right clicked the clock stops and you can carefully click uninstall. Then tab away and check the instructions. If you have to open the "Ports (COM & LPT)" you'll almost certainly miss it and get frustrated fast. If you have something else there, that's one less click you need in that second.This driver is essential for META mode to connect your phone with the low level MTK tools. The correct driver will maintain an entry in "Ports (COM & LPT)" all the while the phone is connected in META mode. My driver, from previous ROM upgrades and subsequent phone purchases proved incorrect.
This is the correct one, the incorrect one could well appear identical (mine had a much lower COM number (about 6)). To be sure you must uninstall all previous drivers as outlined in the Out With the Old (Unseen Driver Conflicts) section above. To know when Windows is ready for the correct driver watch for an exclamation mark on the entry, in the case of this particular device the entry will read, "MT65xx Preloader".
At this point you can install the new driver(s). The file I was given (from dropbox) was DriverInstall_v5.14.53_WinXP_Win7.exe,
MD5: aefe6fc53400b8f9a313cbacd4a4f50b,published my MediaTek. When I go to install it Windows warns that the publisher is unknown. Continue as any other installation. When you are asked (in red!) to install an unsigned driver, go for it, four times! I think this is just MediaTek being cheap not getting MicroSoft to sign and test their drivers. MicroSoft's high false positive rate causes users to blithely dismiss all sorts of security warnings. I don't guarantee these drivers, I use them as do many others.
SHA1: 2f12e07f5785defb81e9f8ab7e501b5d951c8c0f
I'd actually just dismissed exactly four of these warnings installing for my other phone's ROM, with an entirely different installer, a script, so I "knew" what was happening. It would install the unsigned drivers first then install the signed ones over the top. Often signed drivers don't work so I was happy to try unsigned.
With just these drivers installed they should be sufficient to enter META mode. I'd never before been asked to install four consecutive unsigned drivers in a row, MLais publish a how-to telling me to do this, so now I do.
ADB Drivers
You may want to install an ADB driver just in case, while the phone is running. I have not attempted IMEI restoration without. In all likelihood it will never show up in device manager during the process.Infrared has sp_drivers_v1.5_lenovo.zip:
MD5: 2e9d1ca627056703f471f2bbe1b199ea
SHA1: 79bbc822e6af5d394ccabe229a8a2640bf146848
I instead used SP_Drivers_EXE_v1.6 from Pakyto's "RESTAURAR IMEI.zip"
MD5: 0be4b2fb53c18d9bc392e5e4cc6f6972
SHA1: d483be492df8785efe00b4416e5f7ba9229895e8
Purely because the zip came with the apdb_modemdb_A820 folder which I could not find from infrared. This folder contains the AP Database and Modem Database essential to all good IMEI recovery tools. With these files there is no need for an image of NVRAM.img (5Mb) as convenient as it may be to rely on software for it.
It's likely in your search for SN_Station and IMEI tools you will be asked to download other drivers. YMMV and I can't provide an optimal solution for all cases, just my experience. Installing drivers by force is often expedient.
I don't see the necessity of these drivers but for completeness I will repeat what Infrared has said, and leave the proof as an exercise for later.
SN_Station / SN_Write_Station_Tool
Infrared's guide to using SN_Station / SN_Write_Station_Tool concurs with at least two other sources I have seen (by Pakyto and BalcanGSM). BalcanGSM lead me to another solution, which I present later.For completeness I'll outline the process. I didn't ultimately use Pakyto's apdb_modemdb_A820 because the name of his Modem Database differed to that in Infrared's screenshot.
(from Pakyto)
BPLGUInfoCustomAppSrcP_MT6589_S00_P780_V23
MD5: 0f244cd43a65b9aee65a31b73cbcc00c
SHA1: c6a5a4102c77fbb2493323bc7c9ae9f458a506a7
APDB_MT6589_S01_MAIN2.1_W10.24
MD5: 80a45a9bb5bd5416692901de6974d871
SHA1: 76638fb9cd4234437a5c64f149134b9cb81bcae8
(from https://yadi.sk/d/ylJyJbDjZWm7k, from http://www.mcrf.ru/forum/archive/index.php/t-36527.html)
apdb_modemdb_A820.7z
MD5: f770b3e08a5ec076b592493b38591d44
SHA1: 062578a596b90d05b1cf6a2c37bff324740cc3d6
BPLGUInfoCustomAppSrcP_MT6589_S00_A820_V16
MD5: f5a6a5a28ee227533ccb41c35e7155db
SHA1: 8d41e8d604cc9c4a750b7eb9305f641746d2691f
APDB_MT6589_S01_MAIN2.1_W10.24
MD5: 80a45a9bb5bd5416692901de6974d871
SHA1: 76638fb9cd4234437a5c64f149134b9cb81bcae8
I could not find Infrared's but they are specific to device and come with "original" / "stock" ROMs. I didn't find any with them but the stock S139 on NeedRom should contain them, many others don't. If Pakyto says BPLGUInfoCustomAppSrcP works on the A820, that's good enough for me, but I have only tested BPLGUInfoCustomAppSrcP_MT6589_S00_A820_V16 and am still readjusting to having my IMEI's back.
Pakyto said that the hardest part of using this tool was getting the right drivers. I hope this is clarified in the preceding sections. I found just getting it to install at all was hard, rather than click anything with "msi" in you must click the smaller "setup.exe".
The tool has a one page interface with a slightly strange UI after:
• Power off disconnected phone.
• Set everything up as above then click start. (In IMEI Options Pakyto advises using Check Sum, infrared says not, same with function select and 4in1 or IMEI).
• You will be asked for your serial number, IMEI1, IMEI2 (probably first + 1), BT and WiFi numbers. Once an entry is made for each number the tool continues and can't be revised, which surprised me for a while.
When all data is entered and the log updates as shown below, connect phone:
>>Step: Meta Disconnect with target. >>Step: Enter func_imei_meta_hdlr_smart_phone_modem(); Write IMEI to smartphone modem nvram >>—————————————————<< >>Step1: Start to Connect with target… COM port searching and preloader handshake…>>>>>>plug in here<<<<<
<<<<<<phone now shows meta mode>>>>>>
COM port searching and preloader handshake ok COM port searching and Kernel handshake…<<<<<<nothing for 5 mins>>>>>>>
<<<<<<eventually SN Station times out>>>>>>
If I connect when already in META mode I don't even pass the preloader handshake. If I connect when the phone is totally off I pass the preloader handshake but hang waiting for the kernel handshake, as shown above. I tried with "official" (quotes because I can't find them from Lenovo anymore) S139 and S147 ROMs, I know the S139 was rooted but I don't understand why the kernel handshake failed.
I used SN_Writer_2.1324.0:
it was the highest version available and came bundled with Pakyto's "RESTAURAR IMEI.zip" described above. There are many options which may have needed tweaking.
Now, apparently your phone is fixed. I hear this is only a suitable restore procedure from extra virgin stock ROMs. (i.e. format, then downloaded with SP Flash Tools, then use SN_Station.) I'm not 100% convinced because it is long winded and I couldn't restore my IMEI at all using SN_Station. I've seen more concise guides neglecting to mention the formatting and stock ROM download, I suspect it is superfluous caution but often that setup can at least bring phones to a common state.
From links at http://en.miui.com/thread-10061-1-1.html I also picked up
SN_Write_tool_exe_v2.1132.0.rar
MD5: a79a4f4296ce6c3f807180ebed5ea0ff
SHA1: 0aaa640af00d3a663d42f68f88422bfddb88562c
and
SN_Write_tool_exe_v2.1228.0 as part of
Android imei tool.rar
MD5: 15840d67eb37b1ac67aa92d21228887e
SHA1: 6aa6746f6fb8cc26db50cd4a13575d3c67f6d9d3
but that wouldn't install because it was missing "DistFile.cab".
From androidurdu.net I found
SN_Write_tool_v2.1124.1.zip
MD5: 3d51ba55e724ce5e9a5dd908fce63b81
SHA1: 7d49de3cdfd2f3626d157c550193813cd0d9cf10
After many hours I gave up and from somewhere I found
imei&sn writer v1.5.3.rar
MD5: 52f43ae9e73b2279493977ad4f9b68ac
SHA1: f15224419dd9bc440bc006ff53d5efef53fefed5
which contains the 2012 tool IMEI&SN Writer.exe
IMEI&SN Writer
This uses exactly the same files as SN_Station above. I don't know why it doesn't get more love, it saved my phone.It reported a success when I just flashed the IMEI, far more success than I had with SN_Station.
Success, but I was too tired to remember to what extent. In any case it wasn't acceptable so I repeated with all the fields filled in and it fixed it.
For step 3, Select DB, use exactly the same database files described in the section on SN_Station, or google "apdb_modemdb_A820" and see my checksums. Or try the following (verified).
IMEI&SN Writer V1.5.3.7z (3.25Mb)
MD5: 955fc522fd47376e6f7e3c6e3b1b9fc0
SHA1: dd6e0c0a80a57502c6d8fe2436dd6fc6a19e8798
apdb_modemdb_A820_20150729.7z (5.34Mb)
MD5: 6e6ee6541b5800e8386da1ba7436a9da
SHA1: e80700159bc31ba2d94cdfbfeb351b023e581e2f
Sunday 26 July 2015
Lenovo A820 Teardown
Follow this guide if you're worried about replacing your screen or something.
Remove tight rear cover to expose six screws, shown in yellow, the middle right one had a protective 's' security sticker over it.
Don't try and separate the plastics, the separation is performed at the screen junction with the black plastic. The screen is plastic but heavy and transparent. Slide a finger nail in somewhere and slowly work it around, hearing a click as each catch pops.
You are greeted with the backs of two PCBs. I've tip-exed out my identifying codes. The bottom PCB can be prised off but is connected at its top edge by some flat cable connector I didn't proceed to investigate further, there was little electronics of interest there and the PCB itself is paper thin.
The top PCB is much thicker and held in place by 2 very loose and obvious screws and three cable connectors.
This shows the connectors undone. Use soft plastic like a toothpick. The top one has a catch opposite the cable that flicks up. The aerial connector at the bottom left is removed with by pulling with your finger nails. The bottom right one lifts straight up. You will need to lever the PCB out of its housing. A plastic blade would be ideal, again the toothpick and metal blade would do in a pinch.
After breaking the friction with the casing movement stops after a few mm. Their is no connector for the volume rocker. The volume rocker is flexible and must be prised from the casing using a sharp knife to break the adhesive. A few mm more and some tape is found to connect a heatsink / shield on the opposite face to the SIM connectors to another "silver box" remaining with the screen part of the phone. If I had a cracked screen I should have looked further. It's very sticky tape and I removed more than I would have liked. There is one more hidden connection. Use a toothpick to prise it from the PCB as you pull it up. The connection is to the flat cable running along the battery compartment to the mic and screen connections.
This is the new face the PCB reveals, when almost completely detached (vestiges of tape remain).
On the other side of the tape are more markings.
And finally the chips, in case we're compiling our own Android and want more details.
The MediaTek markings were obscured by a pink heat sink sponge thing and this made photographing difficult. I should have tried harder to read but this is my best photo, and with reference to others I believe the markings are (lines are duplicated where there is doubt):
As usual assembly is the reverse of removal. I used a smooth plasic spatula, yeah, a toothpick, to help reattach most of the very sticky silver tape. I also wedged it under the hidden connector to increase its reactive force as I pressed the PCB down on to it.
Remove tight rear cover to expose six screws, shown in yellow, the middle right one had a protective 's' security sticker over it.
Don't try and separate the plastics, the separation is performed at the screen junction with the black plastic. The screen is plastic but heavy and transparent. Slide a finger nail in somewhere and slowly work it around, hearing a click as each catch pops.
You are greeted with the backs of two PCBs. I've tip-exed out my identifying codes. The bottom PCB can be prised off but is connected at its top edge by some flat cable connector I didn't proceed to investigate further, there was little electronics of interest there and the PCB itself is paper thin.
The top PCB is much thicker and held in place by 2 very loose and obvious screws and three cable connectors.
This shows the connectors undone. Use soft plastic like a toothpick. The top one has a catch opposite the cable that flicks up. The aerial connector at the bottom left is removed with by pulling with your finger nails. The bottom right one lifts straight up. You will need to lever the PCB out of its housing. A plastic blade would be ideal, again the toothpick and metal blade would do in a pinch.
After breaking the friction with the casing movement stops after a few mm. Their is no connector for the volume rocker. The volume rocker is flexible and must be prised from the casing using a sharp knife to break the adhesive. A few mm more and some tape is found to connect a heatsink / shield on the opposite face to the SIM connectors to another "silver box" remaining with the screen part of the phone. If I had a cracked screen I should have looked further. It's very sticky tape and I removed more than I would have liked. There is one more hidden connection. Use a toothpick to prise it from the PCB as you pull it up. The connection is to the flat cable running along the battery compartment to the mic and screen connections.
This is the new face the PCB reveals, when almost completely detached (vestiges of tape remain).
On the other side of the tape are more markings.
And finally the chips, in case we're compiling our own Android and want more details.
The MediaTek markings were obscured by a pink heat sink sponge thing and this made photographing difficult. I should have tried harder to read but this is my best photo, and with reference to others I believe the markings are (lines are duplicated where there is doubt):
| MEDIATEK |
|---|
| ARM
APM |
| MT6589 W
MT6589 WVK MT6589 WMK |
| 1309-ATA
1309-ATAH |
| DTNFU?29
DTNFU |
As usual assembly is the reverse of removal. I used a smooth plasic spatula, yeah, a toothpick, to help reattach most of the very sticky silver tape. I also wedged it under the hidden connector to increase its reactive force as I pressed the PCB down on to it.
Thursday 23 July 2015
M52 Red Note ROM Updation and Modding
MLais obviate the ROM scene with their clean ROM. Taking out the trash is much easier. There are many bloatware lists already online, just Google, "safe to delete apk files", or "BLOATWARE LISTS". Few pertain to this year, MediaTek, or Lollipop. I probably just lack imagination, or sleep, to create an original post tonight. Enough waffle:
Anything else, LEAVE ALONE! These are only my opinions, think of them as mini reviews. Perhaps I can add another column for more phones once the porting scene develops.
Another refinement for rooted users is moving favoured apps to the /system partition. One advantage is they become both privileged (in apps-priv folder) and protected. Immediately removing root access promotes this protection. System apps update themselves outside of the system partition which exposes them to at least the danger of accidental erasure (rolling back) when a factory reset is performed. Most factory resetting here is done when I mess up something with my tinkering
1) Add favoured apps. File explorers, alarm clocks, music and browsers, of permanent utility.
2) Move them with another app, from /data/app to /system/app.
3) Delete default system apps that have been superseded by new system apps. HINT, most likely the /system/priv-apps. @cough@ AOSP keyboard @cough@4) Write down what gets changed so it can be repeated if disaster strikes
5) Beware of modifying /system/build.props. The trivial mods I made the 20150526 killed its successor. Even tweaking a single line cause an intermittent fault screen fault.
update 3/10/2015
I've since modified build.props, it's not having much effect though- couldn't rename the device in wifi and bluetoot. com.agold.launcher.wallpaper was rev-enged and deflated to allow wallpaper theming, it appears to have worked but did complain initially.
I'll be upgrading before I do any more modding. Whatever bugs I come up against can be dismissed by Google because my device is already "broken" once rooted. Google is slowly starting to toe the security industry's party line; support for rooted devices is not a given. eFuses and SE Linux are meant to support consumer services to rival Apple, time will tell how well this direction will integrate Android's dev community.
| Full name | Display name | Purpose | Size (Mb) | Confi- dence (<10) | Effect of removal |
|---|---|---|---|---|---|
| /system/res | Sound and Audio Tests | Test data | 10 | 9 | None |
| /system/app/MtkWeatherProvider | Unseen | Reads tea leaves | 0.3 | 9 | None |
| /system/app/MtkWeatherWidget | Unseen | Rolls bone dice | 9 | 9 | None |
| com.android.deskclock | Clock | Widget. inferior alarm | 2 | 9 | None |
| com.agold.launcher.wallpaper | System Wallpaper | Default MTK wallpaper | 10 | 9 | Features FC if accessed |
| com.android.wallpaper | Live (wallpaper) | Default android wallpaper | 2 | 8 | None |
| com.google.android.marvin-talkback | Talk | Screen reader | 1.5 | 4 | No reader |
| AgingTest.apk | Unseen | Factory test for battery, not trojan | 11 | 8 | None |
| agold.AgoldFactoryTest.apk | Unseen | Factory test for QA | 9 | 9 | ? |
Anything else, LEAVE ALONE! These are only my opinions, think of them as mini reviews. Perhaps I can add another column for more phones once the porting scene develops.
Another refinement for rooted users is moving favoured apps to the /system partition. One advantage is they become both privileged (in apps-priv folder) and protected. Immediately removing root access promotes this protection. System apps update themselves outside of the system partition which exposes them to at least the danger of accidental erasure (rolling back) when a factory reset is performed. Most factory resetting here is done when I mess up something with my tinkering
1) Add favoured apps. File explorers, alarm clocks, music and browsers, of permanent utility.
2) Move them with another app, from /data/app to /system/app.
3) Delete default system apps that have been superseded by new system apps. HINT, most likely the /system/priv-apps. @cough@ AOSP keyboard @cough@4) Write down what gets changed so it can be repeated if disaster strikes
5) Beware of modifying /system/build.props. The trivial mods I made the 20150526 killed its successor. Even tweaking a single line cause an intermittent fault screen fault.
update 3/10/2015
I've since modified build.props, it's not having much effect though- couldn't rename the device in wifi and bluetoot. com.agold.launcher.wallpaper was rev-enged and deflated to allow wallpaper theming, it appears to have worked but did complain initially.
I'll be upgrading before I do any more modding. Whatever bugs I come up against can be dismissed by Google because my device is already "broken" once rooted. Google is slowly starting to toe the security industry's party line; support for rooted devices is not a given. eFuses and SE Linux are meant to support consumer services to rival Apple, time will tell how well this direction will integrate Android's dev community.
Subscribe to:
Posts (Atom)