[Android Software Development] Lens_flare:
Stage 4

Last part. We recently ported miui, all is great and mostly functions, But.. am I the only one or that one looks incomplete? One could make its port complete by following next stage:

Stage 4. Advanced tweaks and specific hardware fixes

USB subsystem(mass storage/tether/debugging sign)

First of all, little self - check:

you have to be on old USB Gadget framework kernel source. Those you could clarify by talking with cm dev. Also I'm not rejecting it could work for others but in slightly modified sequence.

Starting from framework-res.apk.

You have to disassemble it first, but before you use actual "apktool d", you should also issue:

apktool if framework-res.apk

that is necessary for decoding internal resources correctly.

Disassemble base and MIUI frameworks and leave base one as we will work with MIUI one and will use base as a reference.

After disassembling, let's go to res/values in it:

As old usb gadget needs old mass storage path which was applicable to gingerbread, we should add that path to strings.xml.

If you only disassembled that file, you should see something like that:

<string name="launchBrowserDefault">Launch Browser?</string>
<string name="SetupCallDefault">Accept Call?</string>
</resources>

exact line to add at the near end:

<string name="config_legacyUmsLunFile">/sys/devices/platform/usb_mass_storage/lun0/file</string>

so that you will get something like that:

<string name="launchBrowserDefault">Launch Browser?</string>
<string name="SetupCallDefault">Accept Call?</string>
<string name="config_legacyUmsLunFile">/sys/devices/platform/usb_mass_storage/lun0/file</string>
</resources>

Remark:

that case is the only applicable to devices which have old kind SD card only. Look at the framework-res on your device, it also might have different LUN file path(actually it is a file, which collects all your SD data to be mounted as usb drive), that you should always replace in mind my defines with yours to make actual usb work.

Devices with flash memory(also called EMMC or embedded SD on flash) and SD[or without SD support at all], should be treat in custom way unfortunately I don't know, consult with your device CM devs for more details. And hey, most of these devices are on new usb gadget, so don't need my guide at all :p

<<

After addition, save strings.xml and go to res/xml in the same framework-res.That's where you also should use base framework-res.

copy from base to miui storage_list.xml and replace when prompted. That file provides only your device-specific SD support, not nexus S or whatever miui base you use.

Assemble miui framework-res.apk and, attention! disassemble it again. That action allows you to see resource ID-s for each line exactly in manner they will be used in living rom.

Remark:

Each resource-drawable, string, boolean switcher etc is treated by its ID - personal identificator. Resources are used in other frameworks and APK to identify something necessary for them. framework-res.apk is a resource storage, which handled by android.content.res package classes like ResourceManager.

USB subsystem also uses some resource to provide to user actual USB status and right mass storage.

<<

Make sure you have both base and miui framework-res, then open both: res/values/public.xml.

Now, we could start the main part - services.jar mod

After adding line "config_legacyUmsLunFile" there will be its id in public.xml after compiling. That's why I stand you should disassemble assembled framework-res again. Remember both ID-s from base and from miui.

Also you need ID-s from both base and miui for following resources:

"stat_sys_adb" - usb debugging icon

"adb_active_notification_title" - usb debugging short message

"adb_active_notification_message" - usb debugging long message

JellyBean-specific:

"config_oemUsbModeOverride" - usb mode override flag

Remark:

public.xml is a resource dictionary, example of line:

<public type="drawable" name="stat_sys_adb" id="0x010804f8" />

means as follows: public type="drawable", drawable - mere picture for different resolution, drawn on the screen, public type subsequently is a type of resource. name="stat_sys_adb" - name of resource, that may be name of acual file or string or bool define etc. id="0x010804f8" - hexadecimal resource identifier. Important note: most resource users are treat resource name without leading zero, for example, 0x010804f8 in usb smalis presented as 0x10804f8, that fact will be necessary on finding and replacing resources(I'd call it matching process), exactly what we are going to do with USB folder smalis.

<<

Open USB folder in miui services.jar (smali/com/android/server/usb), you will see smalis, as usual. Replace its contents with those in base services.jar' usb folder.

Then we are going to match resources: each ID you found in public.xml should be bound to resource call in smali. Let's start:

we will work with miui usb folder smalis. Open UsbService.smali, now remember what id was bound to config_legacyUmsLunFile in base public.xml, for example it was 0x01040029, eliminate leading zero and search file contents for resource 0x1040029, so you will find its entry. Replace that entry with resource you got from public.xml in miui, again, without leading zero. Search for the same ID in LegacyUsbDeviceManager.smali and replace it to miui one.

If you got how that process work, remaining task is match other resource id-s that listed above (usb debugging icon, long and short message). They will be in following files

LegacyUsbDeviceManager$LegacyUsbHandler

UsbDeviceManager$UsbHandler

JellyBean-specific:

UsbDeviceManager.smali also contains necessary switch - config_oemUsbModeOverride, also match ID-s with miui framework and here you go.

USB debugging message is not so necessary as mass storage [coz if resource of mass storage file not found, you won't get usb subsystem to work].

After matching is done, assemble services.jar.

Done! USB subsystem now works.

Another moment could be necessary is to change USB tether interface device to usb0 (as Nexus S is using rndis0 instead, and base whatever you choosed may also have another tether interface)

To change it, you again need a disassembled framework-res.apk(don't forget "apktool if") In it navigate to res/values/arrays.xml.

find the following:

<string-array name="config_tether_usb_regexs">

in nexus S full block will look like that:

<string-array name="config_tether_usb_regexs">
<item>[COLOR="Orange"]rndis0[/COLOR]</item>
</string-array>

Look, I highlighted interface name for you! So the only part you should do it is just replace it to yours. Example for usb0:

<string-array name="config_tether_usb_regexs">
<item>[COLOR="Orange"]usb0[/COLOR]</item>
</string-array>

Interface name could be seen in the same file but in base rom.

By The Way, do you see

<string-array name="config_tether_wifi_regexs">
<item>[COLOR="Orange"]wl0.1[/COLOR]</item>
</string-array>

right after usb one? That is the interface for wifi tether, that you also should change to yours (one your base needed) and that is it! I saw somewhere following interface variant:

<string-array name="config_tether_wifi_regex[/B]">
<item>[COLOR="orange"]tiap//d[/COLOR]</item>
</string-array>

which is for Sony [Ericsson] devices with Texas Instruments wifi chip, just see yours in base to check this out.

in the same file you may also fix Autobrightness levels, I mean those ones:

<integer-array name="config_autoBrightnessLevels">
<integer-array name="config_autoBrightnessLcdBacklightValues">
<integer-array name="config_autoBrightnessButtonBacklightValues">
<integer-array name="config_autoBrightnessKeyboardBacklightValues">

MIUI doesn't have autobrightness tweaks so that is the only way those levels could be applied.

To fully close framework-res and don't come back no more, let's see other things you could do with it:

Minimal brightness too low

There is a bug with brightness: when you regulating it to minmal, screen comes black and won't come back until wipe.

Reason is banal - screen highlight couldn't handle so low value (in nexus S it's 10), first of all find a line at res/values/integers.xml:

<integer name="config_screenBrightnessDim">10</integer>

in most cases value "20" will be reliable, so change "10" to "20":

<integer name="config_screenBrightnessDim">20</integer>

Fix "Network won't automatically picks up"

The problem on some devices like HTC on 7x30 QC architecture, is in one little switch [res/values/bools.xml] :

<bool name="skip_restoring_network_selection">[COLOR="orange"]true[/COLOR]</bool>

just change it to "false":

<bool name="skip_restoring_network_selection">[COLOR="orange"]false[/COLOR]</bool>

and network will come up.

Fix "Deep sleep issue on some devices"

Problem reported Wildfire S users resolved by that little define [res/values/bools.xml] :

<bool name="config_bluetooth_adapter_quick_switch">[COLOR="orange"]true[/COLOR]</bool>

change it to "false":

<bool name="config_bluetooth_adapter_quick_switch">[COLOR="orange"]false[/COLOR]</bool>

and issue will be resolved.

Also, it might be interesting to check out all bools.xml defines to see if something should be changed.

Fixing wrong hardware-software keyboard relationship [auto-rotate and showing issues] (also for galaxy tab 7)

Those with built-in hardware keyboard may experiencing following issue: when hardware keyboard opened, you also see a software keyboard and when you just need a software keyboard, it won't show. Also auto-rotate won't work properly when keyboard is activated.

Seems on Galaxy Tab 7 Samsung(or maybe Cyanogen Mod?) handles software keyboard in relation of some kind of dummy hardware keyboard, so it's our case too.

ICS-only:

To fix that issue, disassemble miui android.policy.jar and navigate to smali/com/android/internal/policy/impl/PhoneWindowManager.smali

there are three constants, according to the source: 0(0x0) - lid closed, 1(0x1) - lid open, and -1(-0x1) - lid absent.

they are located after a function "GetSwitchState".

Original idea was to swap these constants so that system gets fooled about your keyboard state:

code that exists:

const/4 v1, 0x1

-> code that you will get after mod:

const/4 v1, 0x0

the same you should proceed with zero:

const/4 v1, 0x0

->

const/4 v1, 0x1

you might also have to change

const/4 v1, -0x1

->

const/4 v1, 0x1

to get rid of absent state.

another ways to fix this up:

res/values/bools.xml

change

<bool name="config_forceDisableHardwareKeyboard">[COLOR="Orange"]false[/COLOR]</bool>

->

<bool name="config_forceDisableHardwareKeyboard">[COLOR="Orange"]true[/COLOR]</bool>

as we see, it force-disables hardware keyboard so that only soft one will show up.

for devices with hardware keyboard that might also be a deal:

res/values/integers.xml

change the following two line:

<integer name="config_lidOpenRotation">90</integer>
<integer name="config_lidKeyboardAccessibility">1</integer>

Next questions will be related to various APK fixes:

before we start you need to know that all apk are depend on framework-res resources, so before you start disassembling them, let's clarify steps: "apktool if" each framework with resources you have in miui, in stock there are two:

apktool if framework-res.apk

apktool if framework-miui-res.apk

then each apk could be disassembled as usual.

Getting rid of MIUI start screen

Have you mentioned it? Ya, that annoying setup wizard.. In the end it suggests you to input your XIAOMI account which some users may never had and won't create. Keep them out of stress - get rid of that wizard!

Let me show how:

there are 2 ways, one - fully infiltrate that wizard from user's eye, second - will let you choose a language(useful in multilanguage releases) and setup wifi, then go right to homescreen.

Common moment: disassemble Provision.apk and go to smali contents - com/android/provision and choose DefaultActivity.smali

First method - codename "infiltration":

we will modify contents of "isProvisioned" method.

Kill all except "const/4 v1" and "return v1" in it, change const/4 v1 to 0x1 so you will get something like that:

.method private deviceIsProvisioned()Z
.locals 3

.prologue
const/4 v1, 0x1

return v1
.end method

actually, we are just saying to setup wizard that device is already passed its steps and don't need them anymore. So that setup wizard won't even be showed.

Second method - codename "multilang":

it is based on exploit, which is as follows: one could bypass xiaomi account prompt if before flashing miui he pull off sim card and then on setupwizard won't set up wifi. Wizard will send you to "sim not found" dialog, which then will allow one to "dismiss" account request.

Line which asks about SIM state is as follows:

invoke-virtual {v1}, Landroid/telephony/TelephonyManager;->getSimState()I

then

move-result v1
const/4 v2, 0x5

some variable now consists of returned value.

To initialte that value to fail a check, I've just changed constant value to one that telephony manager will never return: -0x5

const/4 v2, -0x5

Now its time to point fail to logical end of wizard, we are going to change label..

if-ne v1, v2, :[COLOR="DarkOrange"]cond_5[/COLOR]

if not equals v1, v2 (if (v1!=v2) in С manner ) go to label cond_5. As we stated, v1 won't be equal v2,so it will go to cond_5, which is not a place we wish to go (coz of unbelieveable hardcode). But there is a wishable place - cond_6:

invoke-direct {p0}, Lcom/android/provision/DefaultActivity;->finishSetup()V

yyyyeah, right to finish :D

so we are changing cond_5 to cond_6:

if-ne v1, v2, :[COLOR="DarkOrange"]cond_6[/COLOR]

that's it! In the end you will get: language selection->wifi setup->homescreen, almost briliant! :D

Whether you choosed first or second method - assemble apk you got after all things done.

Fixing not working mic in calls

Disassemble Phone.apk and navigate to res/values/bools.xml to change:

<bool name="send_mic_mute_to_AudioManager">[COLOR="Orange"]false[/COLOR]</bool>

->

<bool name="send_mic_mute_to_AudioManager">[COLOR="orange"]true[/COLOR]</bool>

Fixing pin code prompt on xperia devices

Disassemble Phone.apk and navigate to res/values/bools.xml to change:

<bool name="ignore_sim_network_locked_events">[COLOR="orange"]false[/COLOR]</bool>

->

<bool name="ignore_sim_network_locked_events">[COLOR="orange"]true[/COLOR]</bool>

Enabling hidden settings

Did you know that you may activate LEDs settings? Or maybe use camera key to trigger some useful functions? If not, follow the next little tuto.

Disassemble Settings.apk, navigate to bools.xml in res/values.

Activating LED settings

It would be enough to change

<bool name="has_led">[COLOR="orange"]false[/COLOR]</bool>

->

<bool name="has_led">[COLOR="orange"]true[/COLOR]</bool>

As you may got, other hidden settings are also there, I'll just list them and assume all of them needs just replacement false to true to make them activated

Multitouch gestures

Still didn't mentioned how they works, but, xiaomi wouldn't make something just for its appearence in settings.

<bool name="has_multi_touch">[COLOR="orange"]false[/COLOR]</bool>

MI button

Mi button on any device that has camera button!

What is MI button? It's a tweak that allows dedicated button to do something instead of its mere function (for example-issuing camera app as for cam button). You may adjust any app in rom to be executed, any switch from miui switchers and also trigger some actions like "menu", "call", "screen off toggle"(allows you to switch screen on and off, so possibly replace power button which is mostly weak) and "screenshot".

how to activate it? - the same:

<bool name="has_camera_key">[COLOR="orange"]false[/COLOR]</bool>

change to "true"

Dock settings

mere dock station settings dialog.

<bool name="has_dock_settings">[COLOR="orange"]false[/COLOR]</bool>

Trackball settings

for devices such as nexus one with active trackball.

<bool name="has_track_ball">[COLOR="orange"]false[/COLOR]</bool>

"Black bar" fix

more details - https://www.dropbox.com/s/6u63tozthmj6xa9/Screenshot_2012-08-07-09-49-09.png

Let's get MiuiSystemUI.apk and disassemble it.

Locate to res/values/drawables.xml and delete first line:

<item type="drawable" name="notification_header_bg">#ff000000</item>

it might vary but always contains black colour (#ff000000). Recompile modified systemUI.

Least but hope not last define for that guide, hope it will fill up with latest and greatest from MIUI devices users and porters around the world.

Cheers, L_F.