Get to Know About Android Screen Resolution

Android develops quickly in the latest years. Data in November 2012 shows that Android occupies 76% share of the global smartphone operating system market. It updates its operate system almost every average 5 months. As for this, handset-makers constantly release their new products which run on the latest Android OS to attract consumers. For this, we benefit a lot, for that we can have bigger resolution screen, thinner,faster digital device to have fun. When it comes to Android screen, how much do you know about it? Especially when you pick up a phone in the market, it's a key point to consider.Actually the conception of resolution is easy. We know what pixel means,Screen image is made up of many squares. If screen resolution is 240x320, which means this screen height in 320 squares, width at 240 squares. As for how big the square will be, it depends on the screen size.For screens with the same resolution 240x320, the smaller screen gets better display effect. For the same amount of squares in the same volume, the display effect will be better when the square is smaller.

You can imagine that if a 3.5 inch screen and a 4.7 inch screen get the same resolution 480x800, it's sure that the 3.5 inch screen will have better display effect while we can see the small grid caused by square in the 4.7 inch screen.

I once use Dopod 565 which released in 2004. It's early smartphone that time. It gets resolution in 176x220, this kind of resolution is described as QVGA.

VGA means resolution is 480x640. QVGA 240x320 resolution is commonly used for a long time after QVGA. QVGA(for it's only one quarter of VGA, so named QVGA ) is widely used by Nokia. Chinese named it as Q screen for those QVGA screen resolution.

Nokia N series handset all take QVGA resolution screen, like NOKIA N95/N96/N73/N78. They are all popular in the market. Blackberry 8 series also almost take QVGA resolution. At that time, most cellphone got a 2.6 inch screen. Of course except for Dopod D700, which is equipped with a 3.5 inch screen(it's a big screen at that time), it only gets 240x320 resolution. You can imagine how square show in this cellphone. Lower resolution doesn't show much difference for image display, but it does in words display.

In the development of VGA, we also meet other resolutions, like HVGA, HGVA is 320x480(for it's only half of VGA, so it named Half-VGA). HVGA resolution was also widely used, like iPhone which released in 2007. From the first generation to the third, iPhone took the 3.5 HVGA resolution screen. The early model for HTC also take HVGA resolution, like HTC G1/G2/G3.

As an extension of VGA, there are screens with 360x640 resolution.It once widely used by Nokia, like NOKIA 5230, flagship models N8 and E7 in early Nokia period. Before N8 was released, this resolution is everywhere  it didn't catch up with trend.

There was a popular resolution named WVGA in 2011, it's 480x800 (for it's wider than VGA,so it gets this name). Many flagship models took this resolution like HTC G7(Desire)、HTC G10(DesireHD)、Samsung i9000(Galaxy S)、i9100(Galaxy S II). As smartphone develops, those models take the same resolution but different screen size, for example HTC G7 is 3.8' inch，Samsung i9000 is 4 inch，HTC G10 is 4.3' inch. So they surely go different in words display.

WVGA also gets a extended resolution named FWVGA, 480x854(the name comes from the taken 16:9 screen).Many Motorola model last year take this resolution,like Moto Droid、Milestone、Droid. Nokia N9 also take this resolution.

qHD resolution image

As the screen technology develops, high definition screen is widely used. Many brand phone makers are taking qHD resolution,540x960. Flagship models from a lot brand phone makers already qHD screen, like HTC G14(Sensation)，Moto Droid 3、Droid Razr。

iPhone 4 contributes to the extend of. iPhone 4 which was released in 2010 take the screen resolution to a higher degree (640x960, 3.5' inch). Now you can't tell from pixel grains, which is a big forward step for screen display.
                         

If we say iPhone 4 lead a new improvement in smartphone screen resolution, then Android lead a smart phone HD screen resolution. We meet a lot 720P(1280x720) resolution smartphones in 2012 like Samsung Galaxy S3, HTC One X, Sony LT29i, LG Optimus 4X etc . But it seems that Android smartphone makers enjoy making HD resolution smartphone although it increases the cost. At this moment, we can see HD smartphone with 1080P which is coming, like OPPO Find 5, HTC One, HTC Droid DNA, HTC Butterfly, Huawei Ascend D2. It gets higher resolution than some 1366x768 PC. HD resolution screen really gives us more delicate images,words.video enjoyment.

What will the smartphone screen will be like in the future?

Call of Mini: Zombies v1.3 [Unlimited Money] Apk + Data Android

The Smash-Hit #1 Action Game in the App Store is now on Android!
A SMALL TOWN INFECTED… UNDEAD ROAM the STREETS…
LOCK 'n' LOAD and come out GUNS BLAZING in HD GLORY!
A strange virus has taken hold in a small town; one after another, the town's people have succumbed, losing their appetite for food and gaining one for BRAINS.

A few brave men hold out against all hope, machine guns and rocket launchers their only aid. Will they survive another day?

That's up to YOU.
• Amazing 3D VISUALS
• Fast & furious RUN-AND-GUN ACTION
• Awesome WEAPONS in the ARMORY

8 immersive & expansive MAPS
16 powerful & unique WEAPONS
12 awesome AVATARS with special STRENGTHS
17 totally terrifying ENEMY ZOMBIE BREEDS

Click to Download

APK File
Direct Download Link - Direct Download Link

SD Data Files
Direct Download Link - Direct Download Link

Using Cryptography to Store Credentials Safely

Posted by Trevor Johns, Android Developer Relations team

Following our talk "Security and Privacy in Android Apps" at Google I/O last year, many people had specific questions about how to use cryptography in Android. Many of those revolved around which APIs to use for a specific purpose. Let's look at how to use cryptography to safely store user credentials, such as passwords and auth tokens, on local storage.

An anti-pattern

A common (but incorrect) pattern that we've recently become aware of is to use SecureRandom as a means of generating deterministic key material, which would then be used to encrypt local credential caches. Examples are not hard to find, such as here, here, here, and elsewhere.

In this pattern, rather than storing an encryption key directly as a string inside an APK, the code uses a proxy string to generate the key instead — similar to a passphrase. This essentially obfuscates the key so that it's not readily visible to attackers. However, a skilled attacker would be able to easily see around this strategy. We don't recommend it.

The fact is, Android's existing security model already provides plenty of protection for this kind of data. User credentials should be stored with the MODE_PRIVATE flag set and stored in internal storage, rather than on an SD card, since permissions aren't enforced on external storage. Combined with device encryption, this provides protection from most types of attacks targeting credentials.

However, there's another problem with using SecureRandom in the way described above. Starting with Android 4.2, the default
SecureRandom provider is OpenSSL, and a developer can no longer override SecureRandom’s internal state. Consider the following code:

  SecureRandom secureRandom = new SecureRandom();
  byte[] b = new byte[] { (byte) 1 };
  secureRandom.setSeed(b);
  // Prior to Android 4.2, the next line would always return the same number!
  System.out.println(secureRandom.nextInt());

The old Bouncy Castle-based implementation allowed overriding the internally generated, /dev/urandom based key for each SecureRandom instance. Developers which attempted to explicitly seed the random number generator would find that their seed replaces, not supplements, the existing seed (contrary to the reference implementation’s documentation). Under OpenSSL, this error-prone behavior is no longer possible.

Unfortunately, applications who relied on the old behavior will find that the output from SecureRandom changes randomly every time their application starts up. (This is actually a very desirable trait for a random number generator!) Attempting to obfuscate encryption keys in this manner will no longer work.

The right way

A more reasonable approach is simply to generate a truly random AES key when an application is first launched:

public static SecretKey generateKey() throws NoSuchAlgorithmException {
    // Generate a 256-bit key
    final int outputKeyLength = 256;

    SecureRandom secureRandom = new SecureRandom();
    // Do *not* seed secureRandom! Automatically seeded from system entropy.
    KeyGenerator keyGenerator = KeyGenerator.getInstance("AES");
    keyGenerator.init(outputKeyLength, secureRandom);
    SecretKey key = keyGenerator.generateKey();
    return key;
}

Note that the security of this approach relies on safeguarding the generated key, which is is predicated on the security of the internal storage. Leaving the target file unencrypted (but set to MODE_PRIVATE) would provide similar security.

Even more security

If your app needs additional encryption, a recommended approach is to require a passphase or PIN to access your application. This passphrase could be fed into PBKDF2 to generate the encryption key. (PBKDF2 is a commonly used algorithm for deriving key material from a passphrase, using a technique known as "key stretching".) Android provides an implementation of this algorithm inside SecretKeyFactory as PBKDF2WithHmacSHA1:

public static SecretKey generateKey(char[] passphraseOrPin, byte[] salt) throws NoSuchAlgorithmException, InvalidKeySpecException {
    // Number of PBKDF2 hardening rounds to use. Larger values increase
    // computation time. You should select a value that causes computation
    // to take >100ms.
    final int iterations = 1000; 

    // Generate a 256-bit key
    final int outputKeyLength = 256;

    SecretKeyFactory secretKeyFactory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
    KeySpec keySpec = new PBEKeySpec(passphraseOrPin, salt, iterations, outputKeyLength);
    SecretKey secretKey = secretKeyFactory.generateSecret(keySpec);
    return secretKey;
}

The salt should be a random string, again generated using SecureRandom and persisted on internal storage alongside any encrypted data. This is important to mitigate the risk of attackers using a rainbow table to precompute password hashes.

Check your apps for proper use of SecureRandom

As mentioned above and in the New Security Features in Jelly Bean, the default implementation of SecureRandom is changed in Android 4.2. Using it to deterministically generate keys is no longer possible.

If you're one of the developers who's been generating keys the wrong way, we recommend upgrading your app today to prevent subtle problems as more users upgrade to devices running Android 4.2 or later.

Join the discussion on



+Android Developers