Pack/unpack factory image:

A typical Android factory package contains several image files, such as system.img, cache.img, userdata.img, boot.img, recovery.img, etc. Although all these files contains the “img” in their names, they are not all of the same format.

According to my experience, there are two file format for these files.

boot.img and recovery.img

Unpack

These files are packed to a Android boot image format, if you use file command to see their type, the command will tell you that it is a data file.

file boot.img
# boot.img: data

if you use inspect into the file’s content, you will see “ANDROID” in the very beginning.

head -n 1 recovery.img
# ANDROID!H�=�a��Y(6�����G�GB��XH�=KERNEL

How to unpack these files? If you are using Ubuntu(or other Linux distributions, I believe), there is a handy tool: abootimg, it can create or extract such kind of images for you. Simply type the following command to install:

sudo apt-get install abootimg

Now you have abootimg installed in your system, you can easily extract boot.img:

mkdir boot
cd boot
abootimg -x ../boot.img
# after the successful execution of the last command, we will have initrd.img, zImage, etc.
# inside the boot folder.

Sometimes we need to change the init ramfs(packed in initrd.img), then we need to unpack the initrd.img. First of all, we need to make sure the initrd.img(some vendor might add a wrapper header to the original image):

file initrd.img
# the output should be similar to the following line:
# initrd.img: gzip compressed data, from Unix

Now we know the initrd.img is a gzip file, we can unpack it use gunzip(gzip -d) combined with cpio:

mkdir ramdisk
cd ramdisk
# "gunzip -c ../initrd.img" means unpack to standard output
gunzip -c ../initrd.img | cpio -i

That’ all, you can dig into the ramdisk folder now^_^.

Oh, forgot to tell you, the “abootimg-unpack-initrd” along with abootimg package do the same thing for you and can save you from typing a lot of command^)^.

abootimg-unpack-initrd initrd.img
# this command will create a ramdisk folder automatically and
# unpack the image to the ramdisk folder

Pack

• initrd.img

  To reverse the unpack action, abootimg package provides another command named “abootimg-pack-initrd”, here is its usage:

  abootimg-pack-initrd [-f] [initrdimg_path] [ramdisk_folder_path]
  # -f: force write. if you would like to use this flag, make sure to place it as the first argument
  # initrdig_path: the path of the target initrd.img file
  # ramdisk_folder_path: the ramdisk folder path
  

• boot.img/recovery.img

  To generate a boot.img or recovery.img, again, we need the abootimg tool.

  # to create an image:
  abootimg --create <bootimg> [-c "param=value"] [-f <bootimg.cfg>] -k <kernel> -r <ramdisk> [-s <secondstage>]
  
  # to update an existing image:
  abootimg -u <bootimg> [-c "param=value"] [-f <bootimg.cfg>] [-k <kernel>] [-r <ramdisk>] [-s <secondstage>]
  
  # Note: the option "-r <ramdisk>", where ramdisk is initrd.img, not the ramdisk folder.
  

system.img, userdata.img, cache.img, etc.

Unpack

Distinguish from boot image, images such as system.img is called user image in Android. Early version of Android(previous to Android 2.3 Gingerbread) use yaffs2 as its filesystem, and use ext4 as it filesystem from Gingerbread(read this post to get some detail about the switch:Ext4 filesystem hits Android, no need to fear data loss).

To decide what format is your image, we can make use of the “file” command:

file system.img
# if the iamge is a yaffs2 image, the output might look like:
# system.img: VMS Alpha Exectutable

# if the image is a ext4 image, the output might be:
# system.img: data

If your image is a yaffs2 image, you can use the yaffs2utils tools to unpack or pack the image. I won’t dig into the detail of yaffs2 image because I have very limited experience on it.

Now you have a system.img that its type is “data”, how can you know whether it is a ext4 image? Android provide a tool named simg2img(which means: sparse image to image) to do the job. We can get the source code of simg2img in the AOSP(Android OpenSource Project), inside the system/extras/ext4_utils/ folder. Read this for an instruction to compile it without compiling the whole AOSP: How to pack and unpack system.img and userdata.img from an Android factory image.

Once you have simg2img installed, you can simply type this command in the terminal:

simg2img system.img system.ext4.img

If the command didn’t yield any error, congratulation! Double check with the “file” command:

file system.ext4.img
# should output something like:
# system.ext4.img: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-abf4-0000-675f-946fc0f9f25b (extents) (large files)

Mount the image using this:

sudo mount -t ext4 -o loop system.ext4.img /mnt
# make sure you have the privilege(sudo or root) to mount the image

Do whatever you want to the files under /mnt(the mount point), and all your modification will be saved when you umount the image.

Pack

When we done with the modifications, we may want to repack the system image(note I won’t touch the topic that how to create a yaffs2 image here). In that case, we need another tools: make_ext4fs and mkuserimg.sh, the source code of these tools also in system/extra/ext4_utils/, you can follow the instructions in How to pack and unpack system.img and userdata.img from an Android factory image to compile the make_ext4fs. The mkuserimg.sh is a wrapper program that it will call make_ext4fs eventually.

mkuserimg.sh
# Usage:
# mkuserimg.sh [-s] SRC_DIR OUTPUT_FILE EXT_VARIANT MOUNT_POINT SIZE

# Example:
sudo mkuserimg.sh -s system/ system.img ext4 /system 500m
# ths "-s" flag indicates that we want to generate a sparse image, otherwise it will gengerate
# am image that we can mount it directly without using simg2img.

# the first "system/" is the system folder(for example, the mount point of the system.ext4.img)
# the second "/system" specify the mount point inside Andriod system.
# the last argument(500m) specify the image size. when mounted in the target Android system, the
# actual partition size would be 10m(approximately) less than this size. the image size must
# conform to the partition size defined in MBR or EBR, or some image data might be overrided by
# subsequent image.

Build Android Marshmallow for Nexus 7:

any were very sad when google chose not to update Nexus 7 2012 to Android 6.0 Marshmallow. This simple guide will show you how to build Android 6.0 Marshmallow for Nexus 7 2012. And for the lazy, I also have a pre-built AOSP Marshmallow image set to download on the bottom of this page. Since Nexus 7 was originally a Google-Play-equipped device, you can legally install Google Apps on this image and enjoy a full Google Android 6.0 experience on your Nexus 7. That part, however, is up to you to do yourself. I am not offering GApps downloads here.

For fun, to make this work a few very cool hacks had to be done, read further below in the “cool hacks” section about them, if you care.

How to build (WiFi)

#get Android M AOSP into folder called M
mkdir L
mkdir M
cd M
repo init -u https://android.googlesource.com/platform/manifest -b android-6.0.0_r1
repo sync -j4
cd ..

#get latest L AOSP into folder called L
cd L
repo init -u https://android.googlesource.com/platform/manifest -b android-5.1.1_r1
repo sync -j4
cd ..

#get blobs (except widevine)
cd M
wget https://dl.google.com/dl/android/aosp/asus-grouper-lmy47v-f395a331.tgz
wget https://dl.google.com/dl/android/aosp/broadcom-grouper-lmy47v-5671ab27.tgz
wget https://dl.google.com/dl/android/aosp/elan-grouper-lmy47v-6a10e8f3.tgz
wget https://dl.google.com/dl/android/aosp/invensense-grouper-lmy47v-ccd43018.tgz
wget https://dl.google.com/dl/android/aosp/nvidia-grouper-lmy47v-c9005750.tgz
wget https://dl.google.com/dl/android/aosp/nxp-grouper-lmy47v-18820f9b.tgz
#wget https://dl.google.com/dl/android/aosp/widevine-grouper-lmy47v-e570494f.tgz
tar xvfz asus-grouper-lmy47v-f395a331.tgz
tar xvfz broadcom-grouper-lmy47v-5671ab27.tgz
tar xvfz elan-grouper-lmy47v-6a10e8f3.tgz
tar xvfz invensense-grouper-lmy47v-ccd43018.tgz
tar xvfz nvidia-grouper-lmy47v-c9005750.tgz
tar xvfz nxp-grouper-lmy47v-18820f9b.tgz
#tar xvfz widevine-grouper-lmy47v-e570494f.tgz
dd if=extract-asus-grouper.sh bs=14466 skip=1       | tar xvz
dd if=extract-broadcom-grouper.sh bs=14464 skip=1   | tar xvz
dd if=extract-elan-grouper.sh bs=14490 skip=1       | tar xvz
dd if=extract-invensense-grouper.sh bs=14456 skip=1 | tar xvz
dd if=extract-nvidia-grouper.sh bs=14460 skip=1     | tar xvz
dd if=extract-nxp-grouper.sh bs=14452 skip=1        | tar xvz
#dd if=extract-widevine-grouper.sh bs=14446 skip=1   | tar xvz
rm *grouper-lmy47v*.tgz extract-*-grouper.sh

#cool binary patch for GL blobs
echo -n dmitrygr_libldr | dd bs=1 seek=4340 conv=notrunc of=vendor/nvidia/grouper/proprietary/libEGL_tegra.so
echo -n dgv1 | dd bs=1 seek=6758 conv=notrunc of=vendor/nvidia/grouper/proprietary/libEGL_tegra.so
echo -n dmitrygr_libldr | dd bs=1 seek=3811 conv=notrunc of=vendor/nvidia/grouper/proprietary/libGLESv1_CM_tegra.so
echo -n dgv1 | dd bs=1 seek=6447 conv=notrunc of=vendor/nvidia/grouper/proprietary/libGLESv1_CM_tegra.so

#cool binary patch for GPS blob
printf "malloc\0" | dd bs=1 seek=5246 conv=notrunc of=vendor/broadcom/grouper/proprietary/glgps

#get old device sources
cp -Rvf ../L/device/asus/grouper device/asus/grouper

#apply source patch to Nfc package (sadly we must mess with platform code here)
cd packages/apps/Nfc/
git apply ../../../../packages-apps-Nfc.patch
cd ../../..

#apply source patch to vendor repo
cd vendor
git apply ../../vendor.patch
cd ..

#apply source patch to device repo
cd device/asus/grouper
git apply ../../../../device-asus-grouper.patch
cd ../../..

#get kernel
cd ..
git clone https://android.googlesource.com/kernel/tegra.git
cd tegra
git checkout remotes/origin/android-tegra3-grouper-3.1-lollipop-mr1 -b l-mr1

#apply kernel patch
git apply ../kernel.patch

#build kernel
export CROSS_COMPILE=`pwd`/../M/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8/bin/arm-eabi-
export ARCH=arm
make tegra3_android_defconfig
make -j4
cp arch/arm/boot/zImage ../M/device/asus/grouper/kernel
cd ../M

#build Android
source build/envsetup.sh
lunch aosp_grouper-userdebug
make -j4

How to build (3G)

Peform all the steps for WiFi device first (3G device build depends on it)

#get blobs (Except widevine)
wget https://dl.google.com/dl/android/aosp/asus-tilapia-lmy47v-6272610e.tgz
wget https://dl.google.com/dl/android/aosp/broadcom-tilapia-lmy47v-e9d05927.tgz
wget https://dl.google.com/dl/android/aosp/elan-tilapia-lmy47v-5f509df5.tgz
wget https://dl.google.com/dl/android/aosp/invensense-tilapia-lmy47v-066fff5f.tgz
wget https://dl.google.com/dl/android/aosp/nvidia-tilapia-lmy47v-05744cf3.tgz
wget https://dl.google.com/dl/android/aosp/nxp-tilapia-lmy47v-7a361708.tgz
#wget https://dl.google.com/dl/android/aosp/widevine-tilapia-lmy47v-2844d74a.tgz
tar xvfz asus-tilapia-lmy47v-6272610e.tgz
tar xvfz broadcom-tilapia-lmy47v-e9d05927.tgz
tar xvfz elan-tilapia-lmy47v-5f509df5.tgz
tar xvfz invensense-tilapia-lmy47v-066fff5f.tgz
tar xvfz nvidia-tilapia-lmy47v-05744cf3.tgz
tar xvfz nxp-tilapia-lmy47v-7a361708.tgz
#tar xvfz widevine-tilapia-lmy47v-2844d74a.tgz
dd if=extract-asus-tilapia.sh  bs=14466 skip=1       | tar xvz
dd if=extract-broadcom-tilapia.sh  bs=14464 skip=1   | tar xvz
dd if=extract-elan-tilapia.sh  bs=14490 skip=1       | tar xvz
dd if=extract-invensense-tilapia.sh  bs=14456 skip=1 | tar xvz
dd if=extract-nvidia-tilapia.sh  bs=14460 skip=1     | tar xvz
dd if=extract-nxp-tilapia.sh  bs=14452 skip=1        | tar xvz
#dd if=extract-widevine-tilapia.sh  bs=14446 skip=1   | tar xvz

#cool binary patch for GL blobs
echo -n dmitrygr_libldr | dd bs=1 seek=4340 conv=notrunc of=vendor/nvidia/tilapia//proprietary/libEGL_tegra.so
echo -n dgv1 | dd bs=1 seek=6758 conv=notrunc of=vendor/nvidia/tilapia//proprietary/libEGL_tegra.so
echo -n dmitrygr_libldr | dd bs=1 seek=3811 conv=notrunc of=vendor/nvidia/tilapia/proprietary/libGLESv1_CM_tegra.so
echo -n dgv1 | dd bs=1 seek=6447 conv=notrunc of=vendor/nvidia/tilapia/proprietary/libGLESv1_CM_tegra.so

#cool binary patch for GPS blob
printf "malloc\0" | dd bs=1 seek=5246 conv=notrunc of=vendor/broadcom/tilapia/proprietary/glgps

#bring in libstlport which the ril sadly needs
cp -Rvf ../L/external/stlport external/stlport

#apply source patch to device tree
cd device/asus/tilapia
git apply ../../../../device-asus-tilapia.patch
cd ../../..

#apply source patch to vendor repo
cd vendor
git apply ../../vendor.patch
cd ..

#build it
source build/envsetup.sh
lunch aosp_tilapia-userdebug
make -j4

Cool hacks (or: “what the hell is libdgv1.so and why are you binary editing files”?)

OpenGL

Nexus 7.2012’s GL libraries were made to work with Android L, and no sources are provided. Android M changed one thing around that make it not work: dlopen() is now POSIX complaint. While this may sound like a good thing, and it is, it still breaks NVIDIA’s GL libraries. Why? Well, they each insist on loading each-other using dlopen. And what do they pass to dlopen? Strings like “egl/libGLESv2_tegra.so”. Why is this a problem? Well, the POSIX spec says that if dlopen is passed a path that includes a slash, no searching is done for the requisite library besides in the current working directory. If no slash is present, a search through a system-specific library search path happens. Previously in android, the latter behaviour happened all the time, and since /system/lib was in the search path, asking dlopen to locate “egl/libGLESv2_tegra.so” would corectly find and load “/system/lib/egl/libGLESv2_tegra.so”. In M this is no longer the case, since dlopen will only search the current working directory. For most android processes, this is just “/”. This is why a simple (but dirty, wrong, and ultimately incomplete) way to solve this problem is to symlink “/egl” to “/system/lib/egl”. But this is a bad solution, since technically any app can change its working directory, and then it will no longer be able to use OpenGL. Clearly a better solution is needed.

NVIDIA’s libraries do not call dlopen directly. They call “NvOsLibraryLoad” – an NVIDIA-specific wrapper around dlopen. The implementation of this funtion resides in “libnvos.so”. This is our opportunity! Curious information: Due to peculiarities of the ELF format, when a binary baz imports function foo() from libbar.so, nowhere in baz’s ELF file does it say that foo() must from from libbar. In fact there are two separate records. One that says that libbar is “NEED”ed, and another that says that there is an import of function “foo”. What that means is that if the process were to also load libxyz, which also exported foo(), there is no way to be sure which foo() would get called. Why do we care? Well, consider our problems. We can repalce a NEED record in NVIDIA’s libraries with one referencing a library we control, like “libdgv1.so”, replace the name of the function they call to load libraries from “NvOsLibraryLoad” to something else, “like dmitrygr_libldr”, implement that function in terms of the real “NvOsLibraryLoad” in “libdgv1.so”, while fixing paths, and as long as “libdgv1.so” has a NEED record referencing libnvos.so, all will go well. This is in fact what I did. Thus the binary patches to the NVIDIA libraries are minimal (two strings each). The implementation of “libdgv1.so” I am providing under AOSP license as part of this post. I would like to once-again emphasize that just symlinking “/egl” is not a proper solution, since any app that changes its working directory (which is OK and allowed) will thus be unable to use OpenGL.

GPS

Nexus 7.2012’s GPS library was also only made for Android L, and does not work in M. Here the reason is simple. It relies on OpenSSL, which in M was replaced by BoringSSL. Fun thing is, though, they are fully compatible. So why does GPS fail? Ha! Broadcom, for some reason used an internal OpenSSL function “CRYPTO_malloc” in their GPS library. “CRYPTO_malloc” just allocates memory. This fix was easy. I binary edited the IMPORT entry in gps daemon to use “malloc” instead and life went on. It is a simple binary patch as well.

Kernel & system()

In their infinite wisdom, NVIDIA decided to directly read files in the filesystem from their kernel. This is always 100% unequivocally a bad idea, as you can read all about here: LINK. The guilty party was an ALS driver. I was not about to let this proceed. I modified the kernel driver to instead have a sysfs entry that one could write that file to (it has a single calibration value). This would be nice and easy, except this changes the behaviour of this calibration form pull (by kernel) to push (by userspace). So now I had to find who writes that file the kernel used to read, and replace that code with writing a sysfs node. This is where things took a turn for the scandalous. The only things touching this file was a binary-only executable that NVIDIA supplies, named “sensors-config”. It was a small one, and I figured i’ll just binary patch it. I disassembled it, and I was horrified. It was a spaghetti-themed nightmare, full of calls to “system()”. I decided to rewrite it. I produced a fully working replica of this binary in source, and am releasing my code under AOSP license as well. As a bonus, now I could teach this binary to write to the sysfs node of the modified drver.

Camera

Camera was not working for a long time. I spent a lot of time debugging, only to eventually find out that it does work, and it is the AOSP Camera app that does not. There goes half my night…

Work left to do

• Kernel per-uid CPU accounting needs to be done for better battery blaming. I might get it done later, but it is not urgent. I did do it for N10 and N4 – I am just being lazy now. Not having this will cause the framework to try finding it 10 times, and log the failures, then it will quiet down and life will proceed.

Ok, ok, give me the files already!

grouper(WiFi)

tilapia(3G)

Download patches if you want to make the build yourself: => [PACKAGE YOU’LL NEED (mirror)] <= If you’re not a person who wants to build android yourself from source, here is fully usable userdebug image. Tested: Sensors, NFC, WiFi, Bluetooth, Camera, GPS. Fastboot-flashable images here => [FASTBOOT IMAGES (mirror)] <= Or, if you prefer to flash from TWRP => [TWRP flashable zip (mirror)] (updated) <=

Download patches if you want to make the build yourself: => [PACKAGE YOU’LL NEED (mirror)] <= If you’re not a person who wants to build android yourself from source, here is fully usable userdebug image. Tested: Sensors, NFC, WiFi, Bluetooth, Camera, GPS. Fastboot-flashable images here => [FASTBOOT IMAGES (mirror)] <= Or, if you prefer to flash from TWRP => [TWRP flashable zip (mirror)] <=

Plase do not re-host this elsewhere and claim this as your work.

Thu, 15 Oct 2015 02:56:55 +0000

Your cool hacks inspire me a lot! Thanks for your work! Going to get my hands dirty…

Thu, 15 Oct 2015 03:58:13 +0000

Tried understanding what you did. Nope, not registering.

Tovmy eyes, that makes your work and dedication really more valuable. Thank you good sir. I’m downloading it as I write this, hiooe Drive catches up

Thu, 15 Oct 2015 10:09:36 +0000

Hi, your hard is truly inspiring. Can i ask you for a guide to Install Android 6.0 on ZUK Z1 ? i want to build custom ROM myself. Pls guide me on how to do it and what tools i need.
I have little knowledge about flashing ROMS and i know little ADB ^ Fastboot commands.
Thanks in advance.

Erik

Thu, 15 Oct 2015 13:49:07 +0000

Dmitry,

You are awesome! Working well on my N7 2012 and It’s my daily driver on my N10 now…

However, this am. I was installing GAPPS from djsubterrain which I used on my nexus 10… I get the error.. E:/Error executing updater binary in Zip ‘/sdcard/!Readytoflash/gapps-mm-fix.zip

Thu, 15 Oct 2015 16:06:37 +0000

First off, thank you for your work and dedication!

Is their a chance to get F2FS Support or does is already support F2FS?

Greetings
Marian

buzz

Thu, 15 Oct 2015 16:10:24 +0000

Has anyone found a working GAPPS package for this? can you post a link if you have. thx!

Thu, 15 Oct 2015 17:19:06 +0000

I think f2fs is not supported because i have installed it and Android says “To start android enter your password”.
I think it thinks the partition is encrypted

Thu, 15 Oct 2015 17:51:00 +0000

Awesome! I have the 3G version so I can’t test it yet but I’ll be waiting for it.

Anybody who can tell me this?: Is it faster than the OTA of 5.1 and all laggy lollipop versions?

Thu, 15 Oct 2015 18:32:49 +0000

I tried you r zip via twrp but I am stuck on bootloop.any suggestion for me

Thu, 15 Oct 2015 19:16:06 +0000

@suresh

erase data
i never promised this will work as an upgrade
only as a clean install

Thu, 15 Oct 2015 20:43:53 +0000

After formatting without f2fs, full wipe and flashing android + “working-marshmallow-gapps.zip” from XDA, it didn’t work ok.

The first time, after login i selected to restore the apps i had. It got stuck in the screen after 40 minutes.

Second time, another full wipe and flashing both files, and this time no restoring apps. The home screen started but clicking in the App drawer got stuck in a waiting logo. Settings, search and going to chrome worked.
After a reboot, it got stuck at “Optimizing app 1 of 1”

Third time: flash only android image and it works well, but after reboot and flash gapps, it gets stuck in “Optimizing app 2 of 10”

Do we have to use a special gapps?

Thanks!

Thu, 15 Oct 2015 21:09:13 +0000

Just flashed again after wipe image + gapps-mm-mini.zip.
After a lot of time (maybe 15 minutes?) it has finally worked!

Norm

Fri, 16 Oct 2015 04:05:51 +0000

Thanks for this, was disappointed when I first heard that there was to be no Android M for us.

@Sergio, good find on the GApps. I was searching forever for something that worked properly.

BTW, if you can’t rotate your screen, boot into recovery and wipe the cache.

Also, some cameras from the Play Store work, and some don’t. I found that the Moblynx cameras all seem to work, but any meant for the Nexus 7 do not.

And I suggest throwing another market store on as Google Play seems to get iffy at times. I ended up sideloading one since the default browser kept crashing when I attempted to download…

I’ll be back for any updates! Thanks again.

Fri, 16 Oct 2015 06:05:11 +0000

Very good work here. I am impressed. You are a genius.

Lynn

Fri, 16 Oct 2015 11:24:54 +0000

Will this work on the 2013 edition? If not, could you point me in that direction?

DaveH

Fri, 16 Oct 2015 15:22:35 +0000

Add a mkdir L at the top of your script please

Jon B

Fri, 16 Oct 2015 18:58:13 +0000

How is the performance of this on the N7 2012? Is it worth using, or just sticking with Lollipop?

Léon

Sat, 17 Oct 2015 01:57:19 +0000

I’ve installed it and it works great. I was wondering, any way to root it? I’ve seen that for the other nexus devices you need a different kernel, is this the same for this build?

Léon

Sat, 17 Oct 2015 02:41:01 +0000

Nevermind, I found the way to do it on XDA. Thank you so much for your efforts! It’s super smooth, love it!

Sat, 17 Oct 2015 04:17:12 +0000

You are the best.

Sat, 17 Oct 2015 06:25:27 +0000

Wow ! Thanks a Ton. let me check it out.

vCon

Sun, 18 Oct 2015 01:18:47 +0000

I am getting a Signature Mismatch on the boot.img (N7 2012 wifi). This is my first attempt at this, can you give me a hint on what I am doing wrong?

Ruedi

Sun, 18 Oct 2015 07:58:58 +0000

@Leon: What did you do? Do you mind sharing a link?

paolo

Sun, 18 Oct 2015 11:50:13 +0000

Ciao
I am user of N7 TILAPIA
I will try to use your .zip version in multirom with a sctock LL + RESURRECTION REMIX LL
What’s about the root for MM ?

paolo

Sun, 18 Oct 2015 11:56:41 +0000

What type of GAPPS have I to use for this version ??
Can you suggest to me the download link for it ?

Frank

Sun, 18 Oct 2015 13:05:11 +0000

How can I root Nexus 7 2012 grouper? Everything else runs really smooth.

Ruedi

Sun, 18 Oct 2015 17:25:20 +0000

I have just tried to install gapps according to http://www.ibtimes.co.uk/android-6-0-marshmallow-aosp-rom-available-nexus-7-2012-1524551. Gapps didn’t work for me, although I habe success with just twrp-ing the files from Dmitry without swiping the device.

What gapps is best?

paolo

Sun, 18 Oct 2015 17:35:42 +0000

Here i founded several type og GAPS for MM

let try one of these
The benzo were not running well for me on my N7 TILAPIA causing a bootloop of twrp

Frank

Sun, 18 Oct 2015 18:11:13 +0000

I used these gapps, they are working great if you reset to factory default:

After that I got the error that Google Play services are crashing. Just go to apps – permissions and give them ALL permissions. Then its working