Mlais M52 is dead, long live Mlais!

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.

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

-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:54

CommonsWare

On a seperate thread his wisdom shone:

Since Android Studio uses the new Gradle-based build system, you should be putting assets/ inside of the source sets (e.g., src/main/assets/), if I understand correctly.

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

Or they might not.