LightBlog

lundi 30 mars 2015

Would the LG G4 Fare Well With The Snapdragon 808?

We do it all day. Let us teach you what we've learned. Learn how the experts market their startups. Grab the free ebook.
From our sponsors
 

 

xda-developers
Android and Windows Phone Development Community

Would the LG G4 Fare Well With The Snapdragon 808?
3/30/2015 10:00:32 PM

Screen Shot 2015-03-30 at 8.04.06 PM

The LG G4 has a lot to prove, given that last year's LG G3 was among the best smartphones of 2014. The Global Mobile Awards given out during the time of MWC 2015 named it the Smartphone of The Year (SOTY?) alongside the iPhone 6, and at the time of its release it packed the very best in Android specifications, from the powerful Snapdragon 801 to the class-leading 1440p display. The camera, battery life and feature set were also deemed excellent, and it went on to gain the love of many Android fans.

The new G4 is still shrouded in mystery, but given we are approaching the release period of last year's model, it is expected to see leaks beginning to pop. Not too long ago we had an LG G4 Note leak that was not quite what it seemed, however, and the internet buzzed with speculation regarding the veracity of the claim, given that the stylus resembled an antenna and the build looked mid-range. I bring this up to mention that, like we've seen countless time this past release cycle, leaks can be fake and forged, if not misleading. With this said, we suggest you take the following speculation on the alleged leak with a grain of salt.

Leaked Benchmarks, Again

The LG G4 allegedly ran its prowess through GFXBench, which many of Screen Shot 2015-03-30 at 7.31.14 PMyou may know as a graphics-intensive benchmark that is a usual test to predict performance under heavy 3D stress. The test usually goes through multiple stages that put the SoC (particularly the GPU) through its paces in on-screen and off-screen scenarios, some with stunning visuals and others with tiny condensed and stressing mosaics. As such, what we are mainly going to talk about is the graphics aspect of what appears to be in the LG G4.

The benchmark information has details surrounding a 15MP camera that supports 4K recording as well as an enticing 7MP front-facing camera. It also states that the device will run Android 5.1 (which is great, considering said update brought forth improved performance for certain devices), 3GB of RAM and 32GB of storage. These all look plausible, but keep in mind one could forge this information and fool those reading the benchmark results. The alluring bit in the specification sheet is the SoC which looks to sport a hexa core CPU clocked at 1.8GHz for two high-power Cortex A57 cores, aided by four power-efficient A53 ones – all in a big.LITTLE arrangement as seen in the Snapdragon 810 and plenty of Exynos chipsets. The GPU listed is the Adreno 418, and this package's details make it obvious that the chipset inside is the Snapdragon 808.

A New Dragon

Given the issues brought forth by the Snapdragon 810, many might be happy to know that these could be the specifications the device will ship with. The LG G3 was never the fastest phone, as the 1440p screen came too early in the evolution of mobile silicon, and the Snapdragon 801 inside the device was too small of a step up from 2013's 800 to support the 70% additional pixels. This is mainly attributed to the GPU inside which remained the same Adreno 330, and the Snapdragon 805 brought with it a more efficient Adreno 420 that could sustain 1440p and still deliver a performance bump. This being said, the Snapdragon 808 is not a 2015 flagship chipset, and despite its model number settling between the 805 and the 810, it doesn't seem to perform better than the former.

While not all of the tests are available for comparison, a quick match-up against last years' Nexus 6 shows that the G4 is not surpassing the top game of 2014. In fact, these tests show that the frames per second are 15% to 20% lower than what the Snapdragon 805 in the Nexus 6 delivered. The obvious culprit here is the Adreno 418 inside the 808.

Screen Shot 2015-03-30 at 8.10.57 PMThe 808's hexa core CPU doesn't seem bad at a glance: with Global Task Scheduling, all cores can be summoned for high-performance tasks. Moreover, the frequency arrangement can differ between clusters, which can aid battery efficiency given that that's the purpose of the A53 set. In regards to the GPU, the Adreno 418 is said to be 20% faster than the Adreno 330 found inside the Snapdragon 800 & 801, but still behind the Adreno 430. For reference, the Adreno 420 was 40% faster than the 330, which was a large reason for the increased adoption in 1440p panels in the second half of 2014. With a stronger GPU, the additional pixels aren't as taxing and performance doesn't take as big of a hit.

The other limitation that the 808 has is that it does not address DDR4 RAM like the Snapdragon 810 does. This means that, if the leak is legitimate, the faster RAM found in the M9 and S6 would not show up in the LG G4. The advantage the 808 does still have is that the 64-bit nature of the SoC would allow OEMs to address 4GB of RAM as seen in the (presumably) much cheaper ZenFone 2… but despite the enticing possibility, this leaked benchmark shows the standard 3GB.

All of these specifications go on to suggest the conclusion that while the model number is misleadingly higher than the Snapdragon 805, the SoC is better suited as a successor to the Snapdragon 801, especially given the GPU inside is behind the 805's Adreno 420. This seemingly shows in the benchmarks – whilst the Snapdragon 810 in the M9 displayed impressive leaps forward in some GPU benchmarks, much of it was because on-screen results benefitted from its 1080p screen. The LG G4 allegedly sports a 1440p screen, with the same set of RAM as the Nexus 6, yet it scores significantly lower. Is the 808 good enough to star in a flagship?

Between a Chip and a Hot Place

LG is in a complicated spot right now, as their LG G Flex 2 was blasted by critics and angry enthusiasts for its thermal constraints, throttling and generally sub-par performance. This was also the device that promised a huge step forward in performance due to the Snapdragon 810 inside, which in the end turned out to be flawed. If they do go with a Snapdragon 808, the decision would be understandable given that the bad reputation that the Snapdragon 810 has amassed, alongside the notorious results it offered on LG's own G Flex 2, could make for yet another controversy or PR disaster.

At the same time, the G3 suffered from a GPU that was simply not optimized to handle the stress of a 1440p, and that coupled with LG's relatively heavy UI made the device show more stutters than a premium flagship is expected to. That didn't stop the phone from gathering staggeringly positive reputation, but the performance and overheating caused by the screen still remind us that every component is connected, and in these premium devices they must all be tuned properly to deliver the best performance in every aspect.

Conclusion

Screen Shot 2015-03-30 at 7.43.22 PMIf these benchmarks are true, can we expect a speedy G4? Intuition tells us that it would certainly be faster than the G3, given that the GPU is noticeably faster than the Adreno 330, and the chipsets have a 64-bit nature that's natively supported by Android 5.1, which also has further optimizations.  But, as these benchmarks suggest, GPU performance is still not up to par with the greatest of 2014, and while the SoC would handle the high-resolution display a lot better than the G3, one would think that it would make more sense to pair up the device with a Snapdragon 805. Since there's not much in-depth information regarding the hexa core CPU in the 808 we can't touch upon that, but given Qualcomm's track record for 64-bit, ARMv8-based big.LITTLE CPU architectures in flagships we must remain skeptical.

High-resolution displays bring with themselves big requirements to provide good user experiences. In the case of 1440p, we've already seen what a shortage in processing power can deliver. If you are into 3D gaming on your phone, you better cross your fingers and expect a surprise that renders these leaked scores or specifications obsolete. While the 808 might bring some steps forward over the 805, the GPU could prevent LG from delivering the true flagship performance we all desire for the third time in a row.

 LG is sending invites for a flagship unveiling on April 28th, so either way we’ll learn more soon. Stay tuned to our Portal for further coverage on the LG G4!

Would you like the other 2015 Qualcomm chipset in the LG G4?

The post Would the LG G4 Fare Well With The Snapdragon 808? appeared first on xda-developers.

 

You are receiving this email because you subscribed to this feed at feedmyinbox.com

If you no longer wish to receive these emails, you can unsubscribe from this feed, or manage all your subscriptions

Photos+ and Google Drive Together

We do it all day. Let us teach you what we've learned. Learn how the experts market their startups. Grab the free ebook.
From our sponsors
 

 

xda-developers
Android and Windows Phone Development Community

Photos+ and Google Drive Together
3/30/2015 1:47:47 PM

Screenshot 2015-03-30 at 19.36.34

Starting today, photos and videos stored in Google+ photos will also be available in Google Drive, to find them just look for the “Photos” menu in Drive on Android and the web. Photos+ will not be going anywhere any time soon but now you can organise all your photos in one place.

 

The post Photos+ and Google Drive Together appeared first on xda-developers.

 

You are receiving this email because you subscribed to this feed at feedmyinbox.com

If you no longer wish to receive these emails, you can unsubscribe from this feed, or manage all your subscriptions

DexPatcher: Patch Android APKs Using Java

We do it all day. Let us teach you what we've learned. Learn how the experts market their startups. Grab the free ebook.
From our sponsors
 

 

xda-developers
Android and Windows Phone Development Community

DexPatcher: Patch Android APKs Using Java
3/30/2015 1:41:29 PM

DexPatcher Patch

You’ve probably seen or installed modified applications, be it a patched dialer for your resolution or a custom WhatsApp version with added features. How do developers do that, though? A lot of the time, the applications’ source code isn’t even available, so how does it all work? We’ll see that first, then take a look at a new tool that aims to make the process much easier, and finally compare it to the popular Xposed framework to see how they differ.

Modifying APKs: How Does It Work?

You might have heard about how APKs are usually modified — developers plug themselves into the matrix, start seeing everything in Smali, and gain the ability to modify things using the power of the Source. A phone call is enough to get them out once that’s done, at which point they’re ready to share the shiny new APKs.

More seriously… Let’s start at the beginning. If you’re not familiar with modding Android applications, you might be wondering what smali is. Developers usually use the Java programming language to code Android apps in. A program (the compiler) then “translates” that code to another format suitable for your device, resulting in .dex files contained inside the application package (or APK).

At that point, you can’t access the original source code anymore (unless you’re the developer or the application is open source). However, what you do have is the APK, since it’s what is installed on your device. From it, you can get the dex files (usually classes.dex) and then try to translate it back to a format you can understand. That’s where smali comes in, as a more readable but faithful translation. You can go one step further and translate it back to Java, though that process isn’t faithful enough — you’ll get an understandable result, but chances are you won’t be able to translate it the other way around again as some details will be lost along the way. In other words, any modifications you might make will be for naught since you won’t be able to turn it back into an APK again to install it on your device… at least not without a lot of effort.

smali/baksmali is actually an assembler/dissembler for the dex format — that’s what it literally means in Icelandic. However, we usually refer to the format smali understands when we say ‘Smali’ (think of it as instructions defining every little detail, even if it’s not all needed by us humans — it’s therefore more verbose than Java). Also note that the above explanation is a bit simplified, but should be a close analogy while still being easy to understand.

What would a developer need to do to modify an app (without access to the source), then? The process is more or less as follows:

  1. Get the APK (from the web or from the device).
  2. Use something like apktool to decompile the APK to Smali. (apktool makes use of smali/baksmali, but makes it much easier to decompile and rebuild APKs, and also takes care of decoding resources like XML files.)
  3. Extract classes.dex from the APK, then use dex2jar and finally a Java decompiler to get (incomplete, often broken, but mostly understandable) Java code. (This is optional, but can be helpful as Smali is much more difficult to understand.)
  4. Identify what to modify.
  5. Actually modify it by editing the Smali code directly.
  6. Alternatively, write the modification in Java, compile it, decompile it again to Smali, then copy the resulting Smali code over.
  7. Once all is over, use apktool again to rebuild the APK.
  8. Sign the APK (to verify the identify of the author; all packages must be signed) and finally install it.

Writing Smali code is quite difficult and prone to error. Smaller changes can be made in Smali, but adding new features with it is more challenging. Additionally, you won’t have any compile time errors, so even typos may only be detected at runtime. Expanding and sharing Smali patches can also be troublesome, as diffs tend to be very specific to a particular APK version. Although some tools exist to make parts of the process explained above easier (Virtuous Ten Studio comes to mind), it can still get tiresome.

Introducing DexPatcher

DexPatcher by XDA Senior Member Lanchon aims to fix these issues, by making the process simpler and allowing developers to completely avoid dealing with Smali. Instead, devs can write patches in Java alone and have DexPatcher handle everything else.

This has the main advantage of having easily readable and manageable patch files. Patching APKs also becomes more convenient in general. We’ll see a full example on how to use DexPatcher in a bit, but here’s a quick overview of what it offers first:

  • Open source.
  • Cross-platform: it should run on Linux, Mac and Windows.
  • Patch files: modifications you make are contained in Java patch files you can independently share.
  • Java: it’s not Smali.

You also gain the advantage of build-time error checking, so bugs show up early in the development cycle. The Java compiled provides its usual compile time checking (with access to the original APK symbols), and DexPatcher enforces compatibility of source and patch when patching, providing helpful information and giving warnings when you seem to be doing something legal but fishy.

In addition to that, DexPatcher comes with a set of helper scripts (only available on Linux, though they could be ported over to other platforms as well). These take care of setting up the workspace, extracting the target APK’s classes and resources, decompiling the classes to Java (the CFR Java decompiler is used for the latter), and finally building and signing the patched APK once you’re done.

Let’s take a look at an example (on Linux):

Install the DexPatcher Scripts

$ # Make a directory where we can test stuff out and enter it. $ mkdir xda-test $ cd xda-test $ git clone https://github.com/Lanchon/DexPatcher-scripts.git dexpatcher  # Clone the DexPatcher helper scripts repo. $ cd dexpatcher $ chmod +x dxp-*  # Not necessary, but for clarity: we need to make sure the files we'll call later are executable. 

Configure the DexPatcher Scripts

Open dxp.config in your favorite text editor and make sure to change the necessary variables to suit your system. You only need to change the following line to point to your Android SDK’s installation location instead:

dxp_android_sdk_dir=(~/android/sdk) 

(DexPatcher will automatically pick the highest platform version available. Additionally, you can also modify other config options to have it use your own versions of some tools instead of the bundled defaults.)
For ease of access, we can add the dexpatcher directory to our PATH, or even symlink the different dxp-* scripts to a location that is already in your PATH, such as ~/bin:

export PATH=$PWD:$PATH 

Modify an Application

For this example, we’ll use a simple and open source application. Of course, patching the source code directly would be possible in this particular case, but that’s no fun at all!

We’ll take the “Get ID” application by basil2style, an application that shows you some details about your device. Our goal is to modify the “Copy” button for the “Device ID” and have it share this ID instead:

DexPatcher Before Patch

  • First, let’s download the APK we’re going to modify: Get ID.
  • Decompile the application.
  • Create the signing key that we’ll later use to sign the APK.

We can also do it all via the shell, using the helper scripts:

$ cd dexpatcher  # Go to our working directory. $ curl -O https://f-droid.org/repo/makeinfo.com.getid_1.apk  # Download the APK. $ dxp-setup-for-apk makeinfo.com.getid_1.apk  # Unpack and decompile the APK. $ cd makeinfo.com.getid_1  # Go to the newly created directory where everything is unpacked/decompiled to. $ dxp-create-keystore  # Create the APK signing key. Press  6 times (or fill out the info), then "yes". 

You’ll notice a few different directories in there:

  • decode: you’ll find the resources and Smali here, as decoded by apktool.
  • src: Empty directory. This is where we’ll place our patch files.
  • src-cfr: this is where cfr decompiled the app (along with errors). A good to place to look in to decide on what to change (you might also need resources and their IDs from the decode directory above, but not for this particular example).
  • src-cfr-nodecode: same as above, but containing only empty stubs (no code, just skeletons). You can use these files as a basis for your patch as we’ll see in a bit.

As we’ve mentioned before, we want to change the Device ID “Copy” button to share the ID text instead. If we look around the source code, we’ll notice that the Device ID Copy button (device_copy) onClick event is handled in by anonymous class in src-cfr/makeinfo/com/getid/MainActivity.java. While we could mod it here, it’s usually better to find an alternate way to do it as anonymous classes have numeric names (MainClassName$SomeNumber, e.g. MainActivity$3) which might change unpredictably between versions.

Instead, we will register our own class for the event by modifying the MainActivity class. First, let’s copy the “skeleton” version from src-cfr-nocode/makeinfo/com/getid/MainActivity.java to src/makeinfo/com/getid/MainActivity.java (remember that src is where our patch will live). (You can also copy the version with the full code if you prefer, this is purely a matter of taste.)

We can now edit it as follows:

  • Add the necessary import for the DexPatcher annotation:
import lanchon.dexpatcher.annotation.*; 
  • Add a tag to indicate we’re editing the class. We also set the default action for members of the patch class to IGNORE, which means that the members are there to be referenced by our code during Java compilation, but will be ignored by DexPatcher.
@DexEdit(defaultAction = DexAction.IGNORE) public class MainActivity // The reference to ActionBarActivity will be satisfied by symbols // extracted from the app when we build the patch. extends ActionBarActivity { 
  • Additionally, add empty bodies to the constructor and onCreate method, as well as all other methods we plan to use (remember that they’ll be ignored when our patch is actually applied — we’re just adding them so we can refer to them here if we need to). You can also just add the native keyword instead.
  • We can already build the patch at this point, if you’re curious:
    $ dxp-make  # Output: `patched.apk`.

    Pretty simple, right? Let’s keep going, though — we’re still not done yet.

  • Let’s edit onCreate now to set out own OnClickListener so that we can share the device ID instead of copying it to the clipboard:
    // Rename the target method so that we can still call it (the original) // if needed. @DexEdit(target = "onCreate") protected void source_onCreate(Bundle var1) {} // Add our new custom method. @Override @DexAdd protected void onCreate(Bundle var1){     // Call the original method:     source_onCreate(var1);      // Replace the text and handler:     device_copy.setText("Share");     device_copy.setOnClickListener(new DeviceCopyOnClick()); }  // Note that we don't use an anonymous class to avoid nameclashing with // MainActivity$1, which already exists. // We also could've defined a nested MainActivity.Patch class and used // an anonymous class in MainActivity.Patch.onCreate(), and then called // MainActivity.Patch.onCreate() from MainActivity.onCreate(). @DexAdd class DeviceCopyOnClick implements View.OnClickListener {     @Override     public void onClick(View object) {         if (MainActivity.this.val) {             Intent intent = new Intent(Intent.ACTION_SEND);             intent.setType("text/plain");             intent.putExtra(Intent.EXTRA_SUBJECT, "Device ID");             intent.putExtra(Intent.EXTRA_TEXT, device.getText().toString());             startActivity(Intent.createChooser(intent, "Share Device ID"));         } else {             Toast.makeText(MainActivity.this.getApplicationContext(), "Nothing to Share", 0).show();         }     } }
  • Looks like we’re done now! The full patch should look like this. We can now build the patched APK and install it:
    $ dxp-make $ adb install patched.apk
  • Let’s have a look at the result:

DexPatcher After Patch

(Thanks to Lanchon for helping out with the sample code!)

How DexPatcher Differs From Xposed

Xposed is immensely popular, and for a good reason — it makes building, sharing and installing mods much simpler for developers and users alike. There are a few differences between DexPatcher and Xposed that may make some prefer one over the other:

  1. Xposed does its magic by hooking methods at runtime and allowing developers to do something before, after or instead any method. DexPatcher, on the other hand, modifies everything ahead of runtime and produces a standalone, modified APK — running code before, after or instead of methods is still possible, and you actually have some extra freedom.
  2. Producing a standalone APK means it doesn’t depend on any external framework. This also means root is not required for modifying user apps.
  3. Since you’re created a new APK with DexPatcher, it’ll be signed differently. This means users can’t receive official updates from the original author, and may cause some issues with apps like Google Apps if the signatures are checked.
  4. Both modules’ and DexPatcher patches’ source code can be easily distributed and modified. They also share many similarities if you get a bit familiar with each.

Get It Now

We’ve talked enough about DexPatcher. It’s your turn to give it a shot now, so head over to the DexPatcher Forum Thread to get started straight away!

The post DexPatcher: Patch Android APKs Using Java appeared first on xda-developers.

 

You are receiving this email because you subscribed to this feed at feedmyinbox.com

If you no longer wish to receive these emails, you can unsubscribe from this feed, or manage all your subscriptions

Would the LG G4 Fare Well With The Snapdragon 808?

We do it all day. Let us teach you what we've learned. Learn how the experts market their startups. Grab the free ebook.
From our sponsors
 

 

xda-developers
Android and Windows Phone Development Community

Would the LG G4 Fare Well With The Snapdragon 808?
3/31/2015 3:00:32 AM

Screen Shot 2015-03-30 at 8.04.06 PM

The LG G4 has a lot to prove, given that last year's LG G3 was among the best smartphones of 2014. The Global Mobile Awards given out during the time of MWC 2015 named it the Smartphone of The Year (SOTY?) alongside the iPhone 6, and at the time of its release it packed the very best in Android specifications, from the powerful Snapdragon 801 to the class-leading 1440p display. The camera, battery life and feature set were also deemed excellent, and it went on to gain the love of many Android fans.

The new G4 is still shrouded in mystery, but given we are approaching the release period of last year's model, it is expected to see leaks beginning to pop. Not too long ago we had an LG G4 Note leak that was not quite what it seem. . . READ ON »

The post Would the LG G4 Fare Well With The Snapdragon 808? appeared first on xda-developers.

 

You are receiving this email because you subscribed to this feed at feedmyinbox.com

If you no longer wish to receive these emails, you can unsubscribe from this feed, or manage all your subscriptions

View All Your Email Accounts At Once

We do it all day. Let us teach you what we've learned. Learn how the experts market their startups. Grab the free ebook.
From our sponsors
 

 

xda-developers
Android and Windows Phone Development Community

View All Your Email Accounts At Once
3/30/2015 2:20:09 PM

Gmail-banner

As of today, you can now select the “All Accounts” option in the Gmail app allowing you to view all your mail at once, regardless of which of your emails it was sent to including Yahoo, Outlook and other IMAP and POP accounts. All these accounts will also be placed in to threaded conversations.

The post View All Your Email Accounts At Once appeared first on xda-developers.

 

You are receiving this email because you subscribed to this feed at feedmyinbox.com

If you no longer wish to receive these emails, you can unsubscribe from this feed, or manage all your subscriptions

CyanogenMod 12.1 for Android One

We do it all day. Let us teach you what we've learned. Learn how the experts market their startups. Grab the free ebook.
From our sponsors
 

 

xda-developers
Android and Windows Phone Development Community

CyanogenMod 12.1 for Android One
3/30/2015 3:20:22 PM

logo_Cyanogenmod

Android One devices once again got a pretty stable release of Android 5.1. XDA Recognized Developer varun.chitre15 managed to build a CyanogenMod 12.1 for Spice Dream Uno, Micromax Canvas A1 and Karbonn Sparkle V. Head over to this thread to download the unified ROM.

The post CyanogenMod 12.1 for Android One appeared first on xda-developers.

 

You are receiving this email because you subscribed to this feed at feedmyinbox.com

If you no longer wish to receive these emails, you can unsubscribe from this feed, or manage all your subscriptions

OnePlus Power Bank Available Tomorrow

We do it all day. Let us teach you what we've learned. Learn how the experts market their startups. Grab the free ebook.
From our sponsors
 

 

xda-developers
Android and Windows Phone Development Community

OnePlus Power Bank Available Tomorrow
3/30/2015 9:50:09 PM

Screenshot 2015-03-30 at 20.04.01

As of tomorrow the $14.99 10,000 mAh power bank from One Plus will be available to customers in the US again. We can only hope the device will be available regularly from now on so customers will not have to put up with the hassle seen when ordering the One Plus One.

The post OnePlus Power Bank Available Tomorrow appeared first on xda-developers.

 

You are receiving this email because you subscribed to this feed at feedmyinbox.com

If you no longer wish to receive these emails, you can unsubscribe from this feed, or manage all your subscriptions