[Kitkat][Nightlies] CM11 Android 4.4 for the Defy(+)

[Don DD]

Guys, i want ask your opinion.
... i want switch to sdboot. On sdcard make system.img, which will be used for system partition.
Data/Cache will be still on defy internal nand.
Defy internal system partition will have only things which needed for boot: Kernel, ramdisk, recovery.
This also avoid random bricks.

Advantages:
1. Faster boot and work android, because defy nand very slow.
2. We can not care about size of android and zip.
3. We can use odex builds, which also faster. Also Android L art will faster on odex builds.

Disadvantages:
1. Need space on sdcard ~500-600mb
2. Very slow sdcards can be not good for android.
3. If change sdcard and not copy system.img, only recovery will work

Quite OK for me. Looking forward to it.

 

[Fight4Music]

OK, let´s do it :good:

+1

 

[9Lukas5]

@Quarx would it be possible then to use f2fs on the sdcard? (Or ext4, instead of an windows file system)
L

 

[okij]

+1 for system on SD card / feedback on jajb's GApps and 09-20 nightly / probable bug

On sdcard make system.img, which will be used for system partition.

+1 too!

This evening I tried jajb's GApps Minimal Edition 2014-09-18 (27 MB) together with the current 09-20 nightly and - though it installed also ran without problems - there was just 3.07 kBytes left on system partition.

Because of this, I then installed jajb's GApps Minimal X Edition 2014-09-18 which deletes some bloatware (like wallpapers) from CM11 while installing the GApps (see here under "What does the GApps Minimal X Edition remove from my system?"). Now I have 6.25 MBytes free on system partition again. :good:

So for now - if you don't stay with BaNkS's last 7-29_GApps_Minimal but decide to use jajb's GApps - and until Quarx moves system partition to SD card , I recommend to use the X Edition of jajb's GApps. Drawback is that it changes the system partition by deleting some files, so using CM updater won't work and you have to flash full CM11 nightlies when updating.

---

General feedback for 09-20 nightly: So far it's running very stable. I have the feeling that it runs a bit smoother than 09-01 or 09-02 nightly, which was also said by noideaforaname and ooo on android-hilfe.de here and here. Great work, @Quarx! :good:

---

Before we can give a general recommendation for 09-20 nightly, could green lens users try if video recording works? I got a PM by @masbitxo who wrote about a bug in 09-20 nightly (including log file):

Defy green lens updated 20 \ 09. The videorecorder crashs when recording a video you press to stop recording.

Link to log bug
https://docs.google.com/file/d/0B00F9XnJ4G3ebnVCcVdxSDJjVnM/edit?usp=docslist_api

On GitHub I read that @Quarx reverted to old camera libs in 09-20 nightly, which today was reverted again and then the revert was reverted again. There also was a commit Revert "Update camera libs, cleanup", so maybe this will fix the bug that masbitxo wrote of again in 09-21 nightly. :fingers-crossed:

---------- Post added at 10:19 PM ---------- Previous post was at 10:17 PM ----------

How about doing nandroid backup in that case? Can TWRP handle this?

This is a good question! @Quarx: How about this?

 

[sevenrock]

On GitHub I read that @Quarx reverted to old camera libs in 09-20 nightly, which today was reverted again and then the revert was reverted again. There also was a commit Revert "Update camera libs, cleanup", so maybe this will fix the bug that masbitxo wrote of again in 09-21 nightly. :fingers-crossed:

They look like Moto G-related commits due to "msm8226" being part of the path name.

 

[okij]

They look like Moto G-related commits due to "msm8226" being part of the path name.

Thanks for this hint.

It's funny though that those commits made it into the changelog for cm-11-20140920-NIGHTLY-mb526.zip:

vendor/motorola

• 5045901 Update camera libs, cleanup
  ...
• 69896f1 Revert "Revert to old camera libs"
• a5e099e Revert to old camera libs

 

[lolasher]

How will mounting via usb will work with system on sdcard?

 

[Coodarah]

SD Card system: In this case forget about TWRP for backup/restore. - Why?

@Quarx
You will shoot me for sure after this ...

(wishlist)
For not being an expert at all, I asked myself, if the following would be feasable:
(This is very drafty brain storming.)

If you come as far as going for a system image (or even a system partition with ext4 or the like) on the sd card, then consider to do it in an all-purpose generic multi-boot style and do it also for (the) data images (please see "Structure" below for the idea behind this).

In the boot up sequence there should be a mechanism reading out the active-flagged system partition and the active-flagged data partition and uses this (see *.conf-files).

If you plan it the "right" way, you even could use it for other devices/ROMs (Falcon/W7 anyone?).
This would be one step further than ordinary JAMBO (just another multi-boot), right?
And no Recovery Backup/Restore would be needed.

I see at least one draw back in it:
You have to buy sd cards more often due to wear off for the data partitions sitting on it.
This could be avoided, if the active-flagged data image is dd'ed/copied to an internal data partition.
(The old active data partition has to be backed up to sd card before, sure.)

In a second step for the GUI lovers (BTW: Where is our "genius app designer" Blechd0se?):
Code a little app ("VirtualDroid") to choose a combination of 1 system-image (partition) and 1 data-image (partition), sitting on the sd card.
This app could maintain some user-editable meta data fields (date time, rom/kernel version, short description, free text notes etc.) for each image in a simple database. - Each record represents one image.
(You could "teleporting" the images from one device to another one etc.)

This would work similar to a VirtualBox "machine" where you can easily add/remove (system) hard disks and/or (data) hard disks in any combination to.

(Quarx is going virtual ...)

_____
Structure (draft):

Folder/file structure on the sd card for a multi-boot rom might be something like this:
(maybe let the datas be locked up = cryptfs, if possible)

sdcard/
... planet_quarx/
...... systems/
......... .system.img.conf
......... (=> this text file contains at least last active image number as property, i.e
......... last_used_sys_img_no=001)

......... system.img.000
......... system.img.001
......... ...
......... system.img.<nnn>

...... datas/

......... .data.img.conf
......... (=> this text file contains at least last active image number as property, i.e.
......... last_used_data_img_no=002)

......... data.img.000
......... data.img.001
......... ...
......... data.img.<nnn>

_____
No warranties from the dev:
Responsibility of combinations of working system/data pairs would be up to the user, don't worry

_____

How about doing nandroid backup in that case? Can TWRP handle this?

This is a good question! @Quarx: How about this?

 

[AnTerNoZ]

@Quarx May it's better if we doesn't use an image, better to create a new partition on sdcard with ext4 filesystem?

 

[DroidBot]

Guys, i want ask your opinion.
Our system partition is small and i want switch to sdboot. On sdcard make system.img, which will be used for system partition. Data/Cache will be still on defy internal nand.
Defy internal system partition will have only things which needed for boot: Kernel, ramdisk, recovery. This also avoid random bricks.
All process will be automatic (If enough space on sdcard).
Advantages of it:
1. Faster boot and work android, because defy nand very slow.
2. We can not care about size of android and zip.
3. We can use odex builds, which also faster. Also Android L art will faster on odex builds.

:good: .. we will accept whatever you tell #mastermind @Quarx .... Yeah, please go for it.
:good::good::good:

 

[DiegoxG]

Of course yes, I want this device to keep going [emoji1] and I think we all have at least a 4gb sdcard

 

[domokos]

Sdcard system move considerations

Need space on sdcard ~500-600mb
Very slow sdcards can be not good for android.
If change sdcard and not copy system.img, only recovery will work

I do not like the idea of putting a system.img on a vfat partition on an sdcard. This has the following disadvantages:

1. Speed of overstacking FS-es: we have 2 fs layers stacked - every read would go through both vfat and extn/f2fs code - this means double buffering in the same buffer space - buffer concurrency for the _same_ data.

2. Putting the system.img onto the vfat vould make mass storage mounting of sdcard impossible as /sdcard will not be umountable with a file on
it loop mounted as /system_2
I'd recommend creating a real partition on the sdcard and use one of these partitions to hold the second system.

3. Overall speed. I made a little test:

Read from sdcard:
[email protected]:/mnt/sdcard $ dd if=cm-11-20140827-NIGHTLY-mb526.zip of=/dev/null
337176+1 records in
337176+1 records out
172634343 bytes transferred in 24.197 secs (7134534 bytes/sec)

Read from internal nand:
[email protected]:/data # dd if=test.img of=/dev/null
200000+0 records in
200000+0 records out
102400000 bytes transferred in 8.205 secs (12480195 bytes/sec)

The speed ratio is: 7134534/12480195 = 0.57166847

So reading from the sdcard is 1-0.57166847 ~ 43% slower.

I used a class 10 sdcard in the above test and I read somewhere (https://forums.motorola.com/posts/858a961797) that the Defy can use sdcard speed advantage up to class 6 or so.

I remember having partitioned my sdcard earlier to run multiple systems in parallel with multiboot. It was fine with one exception: it was very slow.

 

[mahadikrs]

Need space on sdcard ~500-600mb
Very slow sdcards can be not good for android.
If change sdcard and not copy system.img, only recovery will work

You said "Very slow sdcards can be not good for android", I want to know if a class 4 can be termed as slow for the above purpose i.e SDBOOT. I have a Class 4 - 32GB SD card in my DEFY+ with a ext3 partition for instaling apps on sd card using Link2sd.

Pls advice.

P.S : Find image of the card for reference.

 

[bone101]

If we can have a test system.img or else on sdcard without loosing bootable system on nand i would test it anyway

MB526 DFP.231 Stock Rom

 

[r3flux]

Guys, i want ask your opinion.
Our system partition is small and i want switch to sdboot. On sdcard make system.img, which will be used for system partition. Data/Cache will be still on defy internal nand.
Defy internal system partition will have only things which needed for boot: Kernel, ramdisk, recovery. This also avoid random bricks.
All process will be automatic (If enough space on sdcard).
Advantages of it:
1. Faster boot and work android, because defy nand very slow.
2. We can not care about size of android and zip.
3. We can use odex builds, which also faster. Also Android L art will faster on odex builds.

Splendid! Simple solution yet so profound.

 

[topmax]

OK, lets go for SD Boot, 32GB class 10?

 

[leandeganis]

I do not like the idea of putting a system.img on a vfat partition on an sdcard. This has the following disadvantages:

1. Speed of overstacking FS-es: we have 2 fs layers stacked - every read would go through both vfat and extn/f2fs code - this means double buffering in the same buffer space - buffer concurrency for the _same_ data.

2. Putting the system.img onto the vfat vould make mass storage mounting of sdcard impossible as /sdcard will not be umountable with a file on
it loop mounted as /system_2
I'd recommend creating a real partition on the sdcard and use one of these partitions to hold the second system.

3. Overall speed. I made a little test:

Read from sdcard:
[email protected]:/mnt/sdcard $ dd if=cm-11-20140827-NIGHTLY-mb526.zip of=/dev/null
337176+1 records in
337176+1 records out
172634343 bytes transferred in 24.197 secs (7134534 bytes/sec)

Read from internal nand:
[email protected]:/data # dd if=test.img of=/dev/null
200000+0 records in
200000+0 records out
102400000 bytes transferred in 8.205 secs (12480195 bytes/sec)

The speed ratio is: 7134534/12480195 = 0.57166847

So reading from the sdcard is 1-0.57166847 ~ 43% slower.

I used a class 10 sdcard in the above test and I read somewhere (https://forums.motorola.com/posts/858a961797) that the Defy can use sdcard speed advantage up to class 6 or so.

I remember having partitioned my sdcard earlier to run multiple systems in parallel with multiboot. It was fine with one exception: it was very slow.

True. Internal memory faster than sd card here too, as it should be.

 

[okij]

Bug in 09-20 and 09-21 nightly: Video recording crashes on green lens Defys

@masbitxo's bug report for 09-20 nightly that I got via PM, including log file:

Defy green lens updated 20 \ 09. The videorecorder crashs when recording a video you press to stop recording.

Link to log bug
https://docs.google.com/file/d/0B00F9XnJ4G3ebnVCcVdxSDJjVnM/edit?usp=docslist_api

was confirmed by @JimboN via PM, also including log file:

I tested video recording on my green lens defy as requested and can confirm the bug.

1. Opened camera app > switched to video > recorded a 10 second clip > pressed button to stop recording > video was saved as it should be.
2. Pressed record button to start recording again > recorded a 10 second clip > pressed button to stop recording > app crashed (closed).
3. Re-opened camera app > recorded a 10 second clip > pressed button to stop recording > video was saved as it should be.
4. Pressed record button to start recording again > recorded a 10 second clip > pressed button to stop recording > app crashed (closed).

Log file here: https://drive.google.com/file/d/0B_kYbfxFcv83ZVJSdkZscHV3ZUE/edit?usp=sharing

Details: Moto Defy - green lens - 2014-09-20 clean install with Banks 7-29 Minimal Gapps

Today masbitxo wrote via PM that this bug still persits in 09-21 nightly:

The bug in the videorecorder persists in the ROM 09 \ 21. To display the bug have to record more than one video. The first recorded correctly. After the bug occurs an empty file is created.

So there something got broken between 09-01 (09-02, 09-08?) nightly and 09-20 nightly. It doesn't affect red lens Defy's, since I can't reproduce it on my Defy+.
@Quarx: It would be great if you could fix this bug again soon, because besides this, 09-20 nightly is really running great, but we can't recommend it to green lens users yet. :fingers-crossed:

---

About the System-on-SD idea:
@Quarx: For me it would be important that it's compatible to Link2SD which uses the second paritition on SD card. So if the system isn't put in a file on SD card (as you wrote) but in another partition (as @AnTerNoZ suggested), it should be second or third partition.

Also, it would be great if the system partition on nand still would be bootable, as @bone101 suggested, so that we still have a working system even when something on the SD card goes wrong or we could even have a double-boot-option.

 

[domokos]

Storage issues

About the System-on-SD idea:

@Quarx: For me it would be important that it's compatible to Link2SD which uses the second paritition on SD card. So if the system isn't put in a file on SD card (as you wrote) but in another partition (as @AnTerNoZ suggested), it should be second or third partition.

Also, it would be great if the system partition on nand still would be bootable, as @bone101 suggested, so that we still have a working system even when something on the SD card goes wrong or we could even have a double-boot-option.

The best would be to hack the bootloader and then repartition the nand, make system bigger then extend data/cache partitions to the sdcard with lvm as needed.

Dreams I guess...

 

[frozenwaverider]

The best would be to hack the bootloader and then repartition the nand, make system bigger then extend data/cache partitions to the sdcard with lvm as needed.

Dreams I guess...

Hmmm, dreams of hacking it maybe
I wonder if Motorola would relent and unlock it if everyone here emailed them to do so?
They will probably want some $ for it though...

Sent from my N5