Android: Custom Rom – Installing Google Play only (Customize GApps)

Due to license restrictions, Google’s proprietary applications (Play, Talk, YouTube, etc.) don’t come pre-installed with Android custom roms.

That leaves you with two options:

  1. Being happy you got rid of all the bloatware, effectively achieving a “google-free” android.
  2. Google-ify your custom rom by installing the complete “google stack” (GApps) separately.

But what if you prefer the google-free alternative but you purchased apps on Google Play before and want to keep using them?

Or maybe you just realized after hours of searching that a lot of apps cannot be found on other app stores?

You have no choice but to reinstall Google Play. However, using the GApps package as is, results in a bunch of apps and frameworks you don’t need, if you only want to have Play.

So the least thing you can do is to only install the apps/services you really need, avoiding the bloatware mentioned before.

To achieve this, you have to “customize” your GApps package.

This post shows how.

[EDIT 2015-02-08: Paranoid Android offers GApps in different packages sizes (Stock, Full, Mini, Micro, Nano, Pico). Using those might be easier than stripping them yourself. See [GAPPS][4.4.x] OFFICIAL Up-to-Date PA-GOOGLE APPS (All ROM’s) and [GAPPS][5.0.x][BETA] OFFICIAL Up-to-Date PA-GOOGLE APPS (All ROM’s). If those work for you please leave a comment, I’m very interested in any experience.]

[EDIT 2016-05-23: The Open GApps Project now conveniently offers different variants (“aroma” to “pico”) for different android versions (4.4 to 6.0) and different platforms (ARM, x86 and 64 Bits each).  You might want to give “pico” a try and skip the steps stated bellow 🙂 ]

Stripping Gapps

  1. Download the GApps bundle for your Android version
  2. Open the zip file (e.g. with 7-zip)
  3. Go to the system\app\ folder
  4. Delete all apks you don’t want.
    If you want Google Play only, you must keep the following ones:
    GmsCore.apk (Google Play Services)
    Phonesky.apk (Google Play Store)
    If you don’t keep all four of them, Play is not gonna work properly.
  5. Flash the zip file to your device (as described here, for example).
  6. Reboot
  7. Use Google Play

Further actions

If you’re a bit paranoid, I suggest using LBE Security Master to revoke permissions from Google Services Framework.

If you’re even more paranoid, don’t forget to delete your Google account from your device each type you’re done with Play 🙂

Additional packages worth mentioning

Before stripping GApps, you might consider using another nice feature (introduced with Android 4.1 I think) – offline voice typing. It provides robust voice recognition that doesn’t phone home and works without network connection.

To use it, just leave the VoiceSearchStub.apk within the system\app\ folder of GApps before you flash it.

Update (2013/04/29): This seems to work at first (you can download the offline dictionaries and tab the microphone button) but then the actual voice recognition doesn’t work. Epic Fail!

It’s much more easy to just install the Google Search App via Google Play (once you have got it installed as described above). It includes the option for downloading offline dictionaries and using the voice recognition.

And again, if you’re a bit paranoid, better stop the App from phoning home –  using for example LBE Security Master. 😉

Raspberry Pi: What to do if SD card doesn’t work

Before buying a SD card to run a Rapsberry Pi Distro, you should check first, if this particular card is reported to work on RPi.

There still is some risk that the card won’t work anyway, especially when buying cards > 32 GB and SDXC cards (which are not supported officially).

So, if you buy for example a SanDisk Ultra SDXC 64GB and install XBian 1.0 Alpha 5, RPi won’t do a thing after being powered on – despite the card being reported to work.

When a SD card doesn’t work in RPi, your first try should always be to install Raspbian “wheezy” (the distro recommended by the Raspberry Pi Foundation). If this works, you should be able to get other distros to work, too.

In this particular case, the following steps made XBian running on the SanDisk Ultra:

  • Install XBian on a SD card that works with RPi,
  • update firmware,
  • create an image of the SD card
  • and copy the image to the original SD card.
  • Finally, you should expand the root partition to be able to use the full size of the SD card.

Firmware update

  1. Install XBian on a SD card that works with RPi, insert the card and power on the RPi.
  2. SSH to RPi and execute the following commands
  3. sudo apt-get update
  4. sudo apt-get install git-core
  5. sudo wget -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update
  6. sudo rpi-update
  7. Switch the device off
    sudo poweroff

Copy SD

After the RPi has shut down, remove the card and create a backup of the SD card file with your PC, as described here.

Then copy the backup to the other SD card (the one that didn’t work before), like any other RPi image.

Expand root partition

Insert the card in the RPi, power on and SSH to the RPi.

Then choose Settings | System | Resize SD and confirm.

And that’s it!

Alternative solution

A good alternative is to stick to Rasbian and manually install the XBMC package.

Hibernate: Write SQL to a specific logfile (without additional framework)

This post will show a simple setup logging Hibernate’s SQL statements to a single file, including all the parameters, using only log4j and (of course) Hibernate.

SQL in Hibernate

For the purpose of seeing the magic behind a object-relational mapper (e.g. for debugging), it’s always useful to have a look at the actual SQL queries that are created.

Especially, if you are working (or have to work) with something as useful as Hibernate’s Criteria API.

In Hibernate, the simplest way is to set the parameter hibernate.show_sql to true and Hibernate will log all SQL statements to system out.

Straight after setting this option, two things come to mind:

  • Even small applications can generate tons of SQL statements on your log and
  • the SQL statements contain only question marks instead of the actual paramaters, which leaves them only partly useful.

I can’t count the number of SystemOut.log files I saw that were so flooded with Hibernate’s SQL drivel that the important log statements were nowhere to be found.

Using additional Frameworks

In order to solve these issues, the best approaches might be to intercept the SQL statements on JDBC level and then logging them. This can be achieved using a framework like p6spy or log4jdbc. Those frameworks will log the complete SQL statements including the actual parameter values instead of question marks to a file.

However, those frameworks require a lot of effort on configuration. In some cases they can’t be used at all, e.g. in enterprise software – log4jdbc doesn’t even support maven (as of log4jdbc 4.1.2).

Using only Hibernate (and log4j)

A by far simpler alternative is to swiftly set up your logging framework (which should already be part of your application) to log the SQL statements, the values of the parameters and the values returned by the database to a separate file.

A configuration for log4j might look as follows:

log4j.rootLogger=INFO, File, Console, File, File, Console, FileSql, FileSql

log4j.appender.Console.layout.ConversionPattern=%d{ISO8601} %-5p %c{1} %l - %m%n

log4j.appender.File.layout.ConversionPattern=%d{ISO8601} %-5p %c{1} %l - %m%n

log4j.appender.FileSql.layout.ConversionPattern=%d{ISO8601} %-5p %c{1} - %m%

This results in all SQL statements being logged to myApplication_sql.log whereas all other application-related messages (including warnings issued by Hibernate) are written to myApplication.log.

The important part is the additivity parameter, which avoids the log messages being propagated to the parent logger. That is, the SQL statements will not flood your system out.

This solution has only one drawback compared to the additional frameworks solution: It still contains the question marks. However, the org.hibernate.type logger writes additional log statements that contain the values.

Note: Setting the logger org.hibernate.SQL to DEBUG seems to be equivalent to setting the parameter hibernate.show_sql to true.

In addition I’d always recommend to set the hibernate.format_sql parameter to true in order to make the SQL statements easier to read.

The result might look something like this

2013-04-16 21:18:47,684 DEBUG SQL -
    select as id0_1_
        app table0_
2013-04-16 21:18:47,684 TRACE BasicBinder - binding parameter [1] as [BIGINT] - 95
2013-04-16 21:18:47,684 TRACE BasicExtractor - Found [1] as column [id0_1_]


To conclude, using log4j can be set up in no time and contains all the necessary information for debugging (including the values returned by the database), whereas a dedicated JDBC logging framework requires more configuration effort but puts out the SQL statements more neatly.


Once more, I found most of the information aggregate in this article on stackoverflow: here and there. Thanks guys!