All posts tagged android

Currently, we already have a thread for xpose module to help users to run mutiple Skype ID on their android here: http://forum.xda-developers.com/xpos…e-app-t2860388

I also followed that thread from October. However recently I just found out a small tip for who wants to run 2 skype id on same android device without xpose module.

HOW TO:
1. Download and Install version from google play normally: https://play.google.com/store/apps/d…e.raider&hl=en.
(If you cannot access google play or you don’t have google play on your phone, just go to this thread: http://forum.xda-developers.com/show….php?t=2392504 to request apk file or use evozi’s website to download it)

2. Download and install version from skype China’s website. Because Google service is not availabe in China so Skype must publish a version for this market on their website.
Link for Skype China Website’s download page: http://skype.gmw.cn/down/skype-for-mobiles.html

EXPLAIN
I checked the package name, one from GPlay is “com.skype.rider” and one from Skype China’s website is “com.skype.rover”. That’s the same method with the xposed module I mentioned (2 apps with 2 different package name) but it can be considered as official way from Skype 😛 and of course it’s more stable in my opinion

Hope this can be useful for users as me for using 2 skype ids at the same time. Of course if you want to run more than 2 id, using xpose module still works well. But for 2 ids, this is much easier.

Let me know if this doesn’t work for you! As per today, I am able to install to skype without any issues using this method.

I realize that much of this is common knowledge on XDA. Still, every day I see people post about how their phone “loses” 10% as soon as it comes off the charger. I also have friends who can’t understand why their battery drains so quickly. Trying to explain this to people without hard numbers is often met with doubt, so I figured that I’d actually plot it out with real data.

So it’s not a piece that is optimized for this audience, but I hope that you find it interesting.

————————————————–

Your Smartphone is Lying to You
(and it’s not such a bad thing)

Climbing out of bed, about to start your day, you unplug your new smartphone from its wall charger and quickly check your email. You’ve left it plugged in overnight, and the battery gauge shows 100%. After a quick shower, you remember that you forgot to send your client a file last night. You pick up your phone again, but the battery gauge now reads 90%. A 10% drop in 10 minutes? The phone must be defective, right?

A common complaint about today’s smartphones is their short battery life compared to older cell phones. Years ago, if you accidentally left your charger at home, your phone could still make it through a weeklong vacation with life to spare (I did it more than once). With the newest phones on the market, you might be lucky enough to make it through a weekend.

And why should we expect anything else? Phones used to have a very short list of features: make and receive phone calls. Today we use them for email, web surfing, GPS navigation, photos, video, games, and a host of other tasks. They used to sport tiny displays, while we now have giant touch screens with bright and vibrant colors. All of these features come at a cost: large energy requirements.

Interestingly enough, improvements in battery management technology have compounded the average user’s perception of this problem. Older phones were rather inelegant in their charging behavior; usually filling the battery to capacity and then switching to a trickle current to maintain the highest charge possible. This offered the highest usage time in the short-term, but was damaging the battery over the course of ownership. As explained at Battery University, “The time at which the battery stays at [maximum charge] should be as short as possible. Prolonged high voltage promotes corrosion, especially at elevated temperatures.”[1]

This is why many new phones will “lose” up to 10% within a few minutes of coming off the charger. The reality is that the battery was only at 100% capacity for a brief moment, after which the battery management system allowed it to slowly dip down to around 90%. Leaving the phone plugged in overnight does not make a difference: the phone only uses the wall current to maintain a partial charge state.

To monitor this, I installed CurrentWidget on my HTC ADR6300 (Droid Incredible), an app that can log how much electric current is being drawn from the battery or received from the charger. Setting it to record log entries every 10 seconds, I have collected a few days worth of data. While many variables are involved (phone hardware, ROM, kernel, etc) and no two devices will perform exactly the same, the trends that I will describe are becoming more common in new phones. This is not just isolated to a single platform or a single manufacturer.

Chart 1 shows system reported battery levels over the course of one night, with the phone plugged in to a charger. Notice that as the battery level approaches 100%, the charging current gradually decreases. After a full charge is reached, wall current is cut completely, with the phone switching back to the battery for all of its power. It isn’t until about two hours later that you can see the phone starts receiving wall current again, and even then it is only in brief bursts.

The steep drop in reported battery seen past the 6.5 hour mark shows the phone being unplugged. While the current draw does increase at this point (since the phone is being used), it still cannot account for the reported 6% depletion in 3 minutes. It should also be obvious that maintaining a 100% charge state is impossible given the long spans in which the phone is only operating on battery power.

Using the data from CurrentWidget, however, it is quite easy to project the actual battery state. Starting with the assumption that the first battery percentage reading is accurate, each subsequent point is calculated based on mA draw and time. Chart 2 includes this projection.

Now we can see that the 6% drop after unplugging is simply the battery gauge catching up with reality.

The phone manufacturers essentially have three choices:
1. Use older charging styles which actually maintain a full battery, thereby decreasing its eventual life
2. Use new charging methods and have an accurate battery gauge
3. Use new charging methods and have the inaccurate battery gauge

Option one has clearly fallen out of favor as it prematurely wears devices. Option two, while being honest, would most likely be met with many complaints. After all, how many people want to see their phone draining down to 90% while it is still plugged in? Option three therefore offers an odd compromise. Maybe phone companies think that users will be less likely to worry about a quick drop off the charger than they will worry about a “defective” charger that doesn’t keep their phone at 100% while plugged in.

Bump It. Or Should You?

One technique that has gained popularity in the user community is “bump charging.” To bump charge a device, turn it off completely, and plug it into a charger. Wait until the indicator light shows a full charge (on the ADR6300, for example, the charging LED changes from amber to green) but do not yet turn the device back on. Instead, disconnect and immediately reconnect the power cord. The device will now accept more charge before saying it is full. This disconnect/reconnect process can be repeated multiple times, each time squeezing just a little bit more into the battery. Does it work?

The following chart plots battery depletion after the device has received a hefty bump charge (6 cycles) and then turned on to use battery power. Note that the system does not show the battery dropping from 100% until well over an hour of unplugged use, at which point it starts to steadily decline. Again, however, it should be obvious that the battery gauge is not syncing up with reality. How could the rate of depletion be increasing over the first 5 hours while the rate of current draw is relatively steady? And why does the projected battery line separate from the reported levels, but then exactly mirror the later rises and falls?

The answer, of course, is that bump charging definitely works. Rather than anchoring our projected values to the first data point of 100%, what happens if we anchor against a later point in the plot?

Aligning the data suggests that a heavy bump charge increases initial capacity by approximately 15%. Note that the only other time that the lines separate in this graph was once again when the phone was put on the charger and topped up to 100%. Just as with the first set of graphs, the phone kept reporting 100% until it was unplugged, dropped rapidly, and again caught up with our projections.

So what does it all mean?

If you absolutely need the highest capacity on a device like this, you will need to bump charge. There are currently people experimenting with “fixes” for this, but I have yet to see one that works. Be warned, however, that repeated bump charging will wear your battery faster and begin to reduce its capacity. If you are a “power user” who will buy a new battery a few months from now anyway, this presumably isn’t a concern. If you are an average consumer who uses a device for a few years, I would recommend that you stay away from bump charging. The bottom line is that you don’t really “need” to do it unless you are actually depleting your battery to 0% on a regular basis.

If you are someone who can top off your phone on a regular basis, do it. Plug it in when you’re at home. Plug it in when you’re at your desk. As explained by Battery University, “Several partial discharges with frequent recharges are better for lithium-ion than one deep one. Recharging a partially charged lithium-ion does not cause harm because there is no memory.”[2]

Beyond that, the best advice I can offer is to stop paying such close attention to your battery gauge and to just use your phone. Charge it whenever you can, and then stop obsessing over the exact numbers. If you really need more usage time, buy an extended-capacity battery and use it normally.

 

1. When you to open “android-ndk-r10c-darwin-x86_64.bin” with “Archive Utility.app” or other app.
2. Then you’ve got “android-ndk-r10c-darwin-x86_64.bin.cpgz”, OH! Crap it’s not extract but archive .bin to .cpgz extension.
Warning!! extracted file take more disk space up to 3.55 GB on disk
[Solution 1] recommended!!
1. open Terminal then type “chmod +x [path]/android-ndk-r10c-darwin-x86_64.bin” and press “Enter”, after that type only “[path]/android-ndk-r10c-darwin-x86_64.bin” and press “Enter” as below image.

After that Terminal was extract with 7-Zip SFX, as below detail.
7-Zip SFX 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
p7zip Version 9.20 (locale=utf8,Utf16=on,HugeFiles=on,4 CPUs)
Processing archive: /Users/dtkad/Downloads/android-ndk-r10c-darwin-x86_64.bin
2. just wait process until Terminal show “Everything is Ok”

[Solution 2]

1. It’s too easy just rename by remove “.bin” if your non-extension file can be execute.
“android-ndk-r10c-darwin-x86_64.bin”
to
“android-ndk-r10c-darwin-x86_64”
you should see it’s as execute file, check it by right-click and choose “Get Info”, you will see detail like below image.
2. double click on “android-ndk-r10c-darwin-x86_64” execute file or open with “Archive Utility.app”,  so if you not see “Archive Utility.app” in both Launchpad and Application folder, it should be here “/System/Library/CoreServices” like below image.
then the Terminal was run and execute file will do extract process, leave it run until it’s show message as below.

 

Everything is Ok
logout
[Process completed]
 
3. Let’s see your extracted folder “android-ndk-r10c”, it’s contain in “Users” by default, for example my users is “poraweeraksasin” from step 2. name on bar, see below image.

If you want to split a Single Linear layout into a Two Columns(Like newspaper Columns). Here’s the layout for it. Use recursively as per your requirement:


 <LinearLayout
        xmlns:android="http://schemas.android.com/apk/res/android"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:orientation="horizontal" >

        <LinearLayout
            android:layout_width="0dp"
            android:layout_height="match_parent"
            android:layout_weight="1"
            android:orientation="vertical" >

            <ImageView
                android:layout_width="wrap_content"
                android:layout_height="wrap_content"
                android:src="@drawable/item" />

            <TextView
                android:id="@+id/text"
                android:layout_width="wrap_content"
                android:layout_height="wrap_content"/>

        </LinearLayout>

        <LinearLayout
            android:layout_width="0dp"
            android:layout_height="match_parent"
            android:layout_weight="1"
            android:orientation="vertical" >

            <ImageView
                content here/>

            <TextView
                content here/>

        </LinearLayout>
    </LinearLayout>

I’ve tried a lot of android’s adb drivers and honestly it’s not easy to install. Recently I tried to install Oneplus 2/x driver on my system which somehow messed up my android’s sdk and somehow corrupted every app that I made using it. The problem is that these drivers mess up the adb_usb.ini file which we are not supposed to modify (This makes me post about how to solve this issue).

So here it is:

Android USB UnifL

Among other projects, leshcatlabs.net is developing so called Androidadb-USBUnifL Driver.

Those drivers are based on latest Google adb-USB Drivers and aimed to support wide range of Android devices.

Key benefits of adb-USBUnifL drivers as follows:

1. Latest Google adb-USB driver

2. Wide range of already supported non-Google Android devices.

3.Androidadb-USB UnifL driver is using private certificate, that means you don’t have toenableTest Mode“.

Isn’t that wonderful?

Now go test it out!