Android Studio 2.0 brings faster emulation and a Cloud Test Lab

April 13, 2016 in Android by Adrian Marius

android-logoAndroid Studio 2.0 introduces a faster emulator, new Instant Run, app indexing, and Cloud Test Lab features, and an improved GPU Developer debugger.


Android Studio 2.0’s new “instant run” function

by admin

Smaller Serialized Data (Android Performance Patterns Season 4 ep15)

December 1, 2015 in Android, Programming, Tips & Tricks by admin

android-logoA really nice video about Array of Structs and Struct of Arrays and how they can help reducing the size of serialized data.





Android 6.0 Marshmallow coming to devices soon

September 30, 2015 in Android, News by Adrian Marius

android-logoStarting next week, Android 6.0 Marshmallow will begin rolling out to supported Nexus devices around the world, including Nexus 5, Nexus 6, Nexus 7 (2013), Nexus 9, Nexus Player, and Android One. At the same time, we’ll be pushing the Android 6.0 source to the Android Open Source Project (AOSP), which marks the official beginning of public availability.

Today Google also introduced two great new Nexus devices that will be among the first to run the Android 6.0 Marshmallow platform. These devices let your apps use the latest platform features and take advantage of the latest hardware optimizations from our partners. Let’s take a look at how to make sure your apps look great on these new devices.

Introducing Nexus 5X and Nexus 6P

Nexus 5X

Nexus 6P

Read More on Android Developers blog

by admin

Chrome custom tabs smooth the transition between apps and the web

September 2, 2015 in Android, Tips & Tricks by admin

android-logovia Andoid Developers Blog:

Originally posted on the Chromium blog

Posted by Yusuf Ozuysal, Chief Tab Customizer

Android app developers face a difficult tradeoff when it comes to showing web content in their Android app. Opening links in the browser is familiar for users and easy to implement, but results in a heavy-weight transition between the app and the web. You can get more granular control by building a custom browsing experience on top of Android’s WebView, but at the cost of more technical complexity and an unfamiliar browsing experience for users. A new feature in the most recent version of Chrome called custom tabs addresses this tradeoff by allowing an app to customize how Chrome looks and feels, making the transition from app to web content fast and seamless.

Chrome custom tabs allow an app to provide a fast, integrated, and familiar web experience for users. Custom tabs are optimized to load faster than WebViews and traditional methods of launching Chrome. As shown above, apps can pre-load pages in the background so they appear to load nearly instantly when the user navigates to them. Apps can also customize the look and feel of Chrome to match their app by changing the toolbar color, adjusting the transition animations, and even adding custom actions to the toolbar so users can perform app-specific actions directly from the custom tab.

For more information follow this link to reach the original article.

by admin

Double Layout Taxation [Android Performance Patterns Season 3 ep8] (100 Days of Google Dev)

September 1, 2015 in Android, Tips & Tricks by admin

android-logoLayouts are at the core of how you create a modern beautiful android application for your users. But, if you’re not careful, your amazing layouts can create a monster performance drain.

Read the rest of this entry →

by admin

Native Android style in Qt 5.4

December 6, 2014 in C++, News, Programming, Qt by admin


As you might have heard, the upcoming Qt 5.4 release delivers a new Android style. This blog post explains what it means in practice for different types of Qt applications.

Qt Widgets

Earlier it has been possible to get native looks for Qt Widgets applications on Android with the help of Ministro, a system wide Qt libraries installer/provider for Android. In Qt 5.4, selected parts of Ministro source code have been incorporated into the Android platform plugin of Qt. This makes it possible for Qt applications to look native without Ministro, even though applications wishing to use services provided by Ministro will continue to do so. In other words, Qt Widgets applications will look native regardless of the deployment method; system wide or bundled Qt libraries. Read the rest of this entry →

by admin

Mile High Milestone: Tegra K1 “Denver” Will Be First 64-bit ARM Processor for Android

August 12, 2014 in Android, Hardware, News by admin


Our 32-bit Tegra K1 mobile processor has been racking up praise for bringing amazing performance and true console-quality graphics to the mobile space.

It “handily beats every other ARM SoC” in GPU performance benchmarks, according to Anandtech. And “the GPU performance is what stands out with the Tegra K1, nothing else on the market today is really able to get even close,” according to PC Perspective. Read the rest of this entry →

by admin

Anatomy of a Qt 5 for Android application

July 25, 2013 in Android, Qt, Tutorial by admin


There is a nice article by  on the digia qt blog explaining the anatomy of a Qt5 Android application.

Some of the areas discussed are a general overview of major parts composing a Qt5 Android application, a description of the Android application launcher and some insights about how QtCreator sets up the application and also some information about the Qt part of the entire puzzle.

Also, the entire startup of the application is described quite in detail and also the various deployment methods which can be used.

For more information and the entire article, please follow this link.

by admin

CyanogenMod 10.1.1 Released – fixes for vulnerabilities that can bypass check for a digital signature

July 12, 2013 in Android, Linux, News, ROM by admin

cyanogen-modGiven all the Android security topics in the news, we thought it prudent to issue a follow-up to the 10.1.0 general release, incorporating patches for various vulnerabilities that have since been identified.

t the time of this post, CyanogenMod 10.1.1 releases are building and mirroring to our download portal. The CM 10.1.1 build is purely a security bug-fix release on top of the previous 10.1.0.x code-base. While it does not carry any new features, it does address the following:

  • Bug 8219321 aka “MasterKey” exploit (also patched in CM 7 and CM 9 source)
  • CVE-2013-2094 (Linux kernel exploit)
  • CVE-2013-2596 (Qualcomm-specific exploit)
  • CVE-2013-2597 (Qualcomm-specific exploit)
  • General device bug-fixes

With the security nature of this release, all users on CM 10.1.0.x are encouraged to update once their respective build is available


Source: here.

by admin

Using Google’s repo tool with in own projects on BitBucket

April 12, 2013 in Code Snippets, Source Code, Tips & Tricks, Tutorial by admin

Using Google’s repo tool with in own projects on BitBucket

There are couple of ways to manage projects which are split in multiple repositories, of which the two most known are probably git submodule, git subtree, each with it’s own list of pros and cons. One such tool is Google’s Repo wich was created to manage the large Android project in a way which would allow easy replacement of modules, easy addition of new modules, access control, and so on. Some of the things which repo allows are checking out multiple projects from a manifest file, updating them, branching, sending changes from multiple different projects as a single changeset.

A more detailed description of the this command and various other information related to using repo with the Android project can be found here.

Let’s consider a project composed of two repositories, test/a and test/b stored on bitbucket. Once created, their URL will be something like:[an user name]/test-a.git[an user name]/test-b.git

where the ‘/’ in the project’s name was replaced with ‘-‘.

In order to be able to use Repo, you’ll need to download it from, copy it to a suitable location and make it executable or from command line:

curl[the last version] > repo
chmod a+x repo

Repo’s information about a project is stored in a manifest file, default.xml by default if no other name is specified. The file structure is rather simple. Bellow is a sample file for a hypotethical project hosted ob BitBucket []:

<?xml version="1.0" encoding="UTF-8"?>
     <remote name="bitbucket" fetch=".."/>
     <default revision="refs/heads/master" remote="bitbucket" sync-j="4"/>
     <project name="test-a" remote="bitbucket" path="a>
     <project name="test-b" remote="bitbucket" path="b"/>

As you can see, first at least one remote needs to be defined, which will be used to fetch the projects. The name should be something meaningful for you, while fetch should contain the URL to the repository from where the projects will be fetched. The reason why we specified “..” will be explained bellow.
Then we need to add a default revision definition for the remotes we defined, and then follow the list of projects. The defaults are useful since in case no revision is defined for a project, the default one will be considered.

In the project definition the path specifies the path where the given project will be cloned and will be automatically created if does not exists. The project name is the path and the name of the project, without the .git part, which will be appended automatically. The full URL of the project’s repository will be {the url provided to remote fetch}/{projec name}.

Once this file is created, we need to store it on bitbucket in a repository, for example test/repo, the repository URL being like:[an user name]/test-repo.git

This being complete, the configuration part is done. Time to clone the project. For this, we need to create a folder, and inside that folder we’ll need to initialize repo by running this command:

repo init -u[an user name]/test-repo.git

This will download the manifest from the specified URL using git and create a .repo folder inside your folder, then will clone the project you specified after the -u flag and try to find and store the manifest file (default one being default.xml).

The reason why we specified the “..” for the fetch is as because in this case the it will be considered relative to the URL we specified at the init moment. Remember that earlier I said the project’s repository will be {the url provided to remote fetch}/{projec name} ? In our case {the url provided to remote fetch} will be[an user name]/test-repo, and in order to be able to specify an another project, we need to go one folder higher, which would mean relative path “..”. When composed together with the project name, we’ll end up with something like[an user name]/test-repo/../test-a.git which is same as[an user name]/test-a.git, the right path for our test/a project.

Once this is complete, we can download the projects by running

repo sync

which will clone all the configured projects. From here you can use the usual git commands to commit & push stuff in various projects or use the repo commands for the repo’s functionality.

Note: while git allows you to clone a bitbucket repository with ssh://git@…., it won’t work with repo. If you specify the repository for the manifest file, the repo won’t be able to find te repos of the configured projects.

More information about Repo’s commands can be found here

Source here.

Skip to toolbar