yashsingh1/xdaforums huggingface dataset:
[Galaxy S II Original Android Development] philsilvers:
Please help, has anyone ever managed to get a working FM radio on this rom, 20170126_emu i9100 rom as per page 9, I'd love to know how, I've looked at the driver in the modules folder & seems fine, is there a later kernel with driver support ? or maybe a custom kernel that will work with this 7.1.1 rom & has support, alright I know the radio thing is outdated now but it would've been a nice touch & worth a try, any help appreciated, thanks.

------------------

Edit - I've managed to get Spirit2 and another FM radio app working, it seems when you install & first switch on it picks up some wrong data & will keep giving the incompatible kernel error, clearing cache and data cured this.

Its headphones only at mo but does work beautifully, when I've found the best auto reroute method for both headphones and rear speaker, I'll post back.

-------------------

Edit again - Seems to go back to before with the incompatible kernel error after a reboot, if I rapidly keep pressing the radio's power button 50 times, then it will connect to the driver & work perfectly and keep working all the while the phone isn't switched off then switched back on again, so I'm going to leave the FM radio for now & get on with other things.
[Galaxy S II Original Android Development] philsilvers:
Tried f2fs on data + cache on this emu rom & can't feel or see any benefit whatsoever, any thoughts from anyone on the f2fs thing ! does anyone know better ! before I switch back to ext4.
[Galaxy S II Original Android Development] ale5000:
On Windows adb never require administrative privileges.
[Galaxy S II Original Android Development] Lanchon:
my adb:

$ adb version

Android Debug Bridge version 1.0.36

Revision 302830efc153-android

has always talked to TWRP and to CM11 recovery. all versions of adb, TWRP and CM11 recovery that i can remember.

you'll have to google for a windows solution.
[Galaxy S II Original Android Development] Lanchon:
for sure? on linux, adb root and other commands (including talking to some -but not all- recoveries) requires root. not the client, but the client daemon started after kill-server.

i always thought this was very strange. looks like "fake" security, something baked in the adb client that you can easily remove from the sources, recompile, and proceed without root. if it is, it's simply the appearance of security, and a very very big mistake. if they wanted to avoid certain things from being used by noobs, they could have added '--expert-mode' or '--dangerous-mode' instead of check for root.
[Galaxy S II Original Android Development] Lanchon:
then it is your lack of "drivers", some ****ty .inf files anyway. the vendor id / product id / interface id must be changing between android and TWRP in your case. (check it out in the device manager.) you need the right drivers for whatever combo u got there.

in Ubuntu you just write some udev rules (as root) to grant access to plain users (or someone in particular) per device. unknown devices are shielded from plain users by default, which is a sane thing to do. however if you are lazy about the rules, just start the adb client daemon in root mode and it will access everything you throw at it.
[Galaxy S II Original Android Development] ale5000:
I'm not sure about Linux, but on Windows I never open the prompt with administrative privileges and I never get any error.
[Galaxy S II Original Android Development] the.gangster:
Even if I didn't check it out yet, just from looking at it, it seems that it was only modified to show the internalSD as "Non-emulated storage" instead. But couldn't see any additions for the emulated storage being a subpartition of /data.

In deed, last night I realized that both phones do change their device ID strings (vendor ID and product ID) when rebooted to recovery.

Now that I wanted to report back I see, that you assumed exactly that already. LOL. I must have overread your hint on that before.

So both phones do actually change ther identity on the bus when booting into recovery. They turn from a Samsung Galaxy S2 (vid_04E8&pid_6860) into a Google Nexus (vid_18D1&pid_4ee2).

No wonder that the installed Samsung drivers didn't manage that. It was not that obvious, as the device manager still showed it as GT-I9100...

Cool to finally have adb support towards TWRP now.
[Galaxy S II Original Android Development] Lanchon:
yes wonder! the USB stack is supposed to support interfaces and "class" drivers. for instance, windows handles basic mass storage without needing to match the vendor and device id of every existing pendrive. why does it need to match every other android device to do ADB, or any particular device to have it work with usblib as a developer, etc is a mystery. they probably cripple windows to extort hardware developers a fee for signing their "drivers" (lol). what a ****ty company and OS! i can't believe what owners of windows systems are put through and still don't switch away from it. yes, that includes you lol.
[Galaxy S II Original Android Development] Lanchon:
so yes i do have a backup windows partition around that i boot once a year or less to do some strange hardware hacking. i did order that PC with 32 bit windows 7 though, not 64. 64 bit compulsory driver signing is insulting. i consider the complete OS to be malware because of that antifeature.
[Galaxy S II Original Android Development] rINanDO:
Hi Lanchon!

Thanks for your detailed and very useful information! About sdcard-partition I chose not to delete it. I'm not sure what the plans are for cm-recovery but it uses by default the misc-partition we don't have. I planned to create a small sdcard0 of 100mb but mount it as misc in emulated storage.

I was not aware there are 8gb and 32gb versions of the s2. So meaning my new PIT only works for 16gb devices. Nice work with REPIT. I will take a look!
[Galaxy S II Original Android Development] Lanchon:
i dont know what you mean with "but mount it as misc in emulated storage". are you taking about TWRP or android? what would be the point of mounting it as misc?

i'd suggest not modifying android at all and keep it compatible with (actually keep it being) the standard non-emulated build. those that want emulated have to convert, those that don't do nothing. (the only problem with this is of course the first boot after a wipe; but see below.)

in TWRP and in android i'd suggest leaving the /sdcard partition and the external sdcard just as they are now for the various reasons i mention above. eg in TWRP as sdcard0 and sdcard1.

those that want the /sdcard partition gone can simply wipe its file system.

my recommended size for /sdcard is 8MB, the smallest size that can accommodate ext4 if needed. i see no reason for a larger partition. same with /preload.

ANDROID

if you want to modify android at all, this is what i'd suggest:

- on first boot after wipe, if the storage has been converted to emulated, then default to an emulated setting.

- the easiest way to achieve this seems to be dynamically setting the ro.vold.primary_physical property early on every boot.

- the easiest way to detect emulated conversion would be the failure to mount /sdcard. (proper conversion would then dictate that sdcard's file system should be wiped.)
[Galaxy S II Original Android Development] rINanDO:
My first idea which I am currently testing was to modify Android and creating a new i9100_emu build next to the original build. About PIT in i9100_emu => maximizing /data and minimizing sdcard0. However in CM-recovery we need a /misc-partition to make it work at all. I thought to use the unused partition sdcard0 for this to keep compatibility and therefore we don't need our custom bootloader_message module to fix it. So we have CM-recovery compatibility and the option to enable Multi-user overlay flag in this build and all benefits of emulated storage.

Since our i9100 still have issues with CM-recovery I replaced the recovery with TWRP 3.0.3 to have a matching recovery until it is fixed. In TWRP I renamed the former sdcard0-partition to /misc to match with Android to be consistent. I didn't touch /preload since I don't know its purpose. If it is a Samsung specific Stock-partition, then maybe it is a better idea to use this as /misc instead.

What do you think about this?
[Galaxy S II Original Android Development] Lanchon:
well. i'm severely misinformed. i don't know what you mean by "in CM-recovery we need a /misc-partition to make it work at all". why does CM needs a misc partition? my take is, screw CM recovery if it's defective. don't go around changing partition layouts for the sake of that ridiculous piece of bad software nobody wants. we already have a free and open recovery and it's TWRP, and nobody wants to use CM recovery.

"we don't need our custom bootloader_message module": i dont know what that is.

creating a new i9100_emu is a good thing, CM didn't want to do this.

"In TWRP I renamed the former sdcard0-partition to /misc to match with Android to be consistent. I didn't touch /preload since I don't know its purpose. If it is a Samsung specific Stock-partition, then maybe it is a better idea to use this as /misc instead."

IMHO, you should enfatically not repurpose /sdcard as /misc. /sdcard can potentially have very valuable user data and the system must NOT do anything with that partition at all, except maybe (as i recommend) mount it as an extra external SD card.

this applies to both Android and TWRP. (and in TWRP my previous very long message with recommendations apply. maybe re-read it now.)

if you have to have a /misc partition for reasons unknown to me, then definitely use HIDDEN then. (/preload could hold an alternative kernel in multiboot settings, but no personal and valuable information. and those doing multiboot are expected to know what they are doing anyway.) you can change HIDDEN's mount point but please DO NOT rename the partition label, or else you'll run into big problems when people use many tools (REPIT included).

HIDDEN will typically have an empty ext4 file system and will be resized to 8MB on most repitted phones. you can wipe its contents. if you wipe the file system itself or change its file system type, some android builds will bootloop.

EDIT:

one extra note: i guess most people will want to use REPIT to repartition, becuase it's simpler and keeps data. REPIT requires TWRP, so there's one more argument about CM rec.

CM recovery was crippled to the point that i couldn't support it. i went as far as bundling my own complete userland to replace CM recovery's, but then i found myself restricted and unable to create symlinks (to avoid "exploits" in this "free"(lol) recovery) so i just dropped support for it.
[Galaxy S II Original Android Development] Oxydeme:
Experiments with Repit last night.

Hi there,
[MENTION=4141005]Lanchon[/MENTION] I used to flash last night as usual I switch very often between OSs and as many, I used your magical tool.

As you told in op, to try to swap SD card, I tried.

So I broke the flash script of twrp cause emmc was swaped.

I decided to try flash Lineage 7.1.1 error caused by swap,

I repaired the partition thanks to twrp reformatted to ext4 cause each of others were in this format. Repited another with default settings, except for Sdcard0, (smallest).

Reflased everything to reuse the phone..

All of this to say that I kept logs.

Wanted to share it, to let you see if there is something interesting.

Ask me if needed, I'll upload it somewhere.
[Galaxy S II Original Android Development] Lanchon:
i dont mind switching to internal storage (only on first boot, that's when the flag is honored anyway) if we cant mount /sdcard. people PITted then forgot to format /preload in the CM11 days, then CM12 bootlooped on them the next year when they installed it, lol. but noone forgot to format /sdcard as it's needed for android to function.

if someone ever does, then all they have to do is fix the issue (obviously) then wipe data and reboot. the whole point is that this happens on first boot, so the phone was already wiped anyway.

about a "flag", yes... a file system on /sdcard! :) adding more configuration/setup is useless and problematic. the presence of a file system there is very natural IMHO. and REPIT can already take care of that "flag" with the proper configuration.

but... orlando wants a separate build. so he probably wont be doing any autodetection.

so no need to argue pros and cons :)
[Galaxy S II Original Android Development] Oxydeme:
[MENTION=6560258]the.gangster[/MENTION] the fact is,

The log file is too big to be attached so I'm still searching for uploading it in a proper way, any solution?
[Galaxy S II Original Android Development] Namoi:
Try Pastebin and share the link here.
[Galaxy S II Original Android Development] Oxydeme:
Max pastebin size 500kb not sure I get all in, 'll try thanks
[Galaxy S II Original Android Development] the.gangster:
Are you really sure we are still talking about the recovery.log here?

This shouldn't be that hugh...
[Galaxy S II Original Android Development] rINanDO:
Hey guys, about /misc. I dropped the idea. You are all right. Not only is it risky and confusing, but it will give also bootloops when switching between emmc/ext4 filesystem unless you format it or change fstab. I also don't want to mess with the size of /preload (HIDDEN-partition) because not all recoveries have the ability to format /preload after repartition. Like Lanchon explained forgetting or not able to format /preload, you got yourself a bootloop. By the way, the use of /misc is not introduced by CM-recovery (my bad info) but from Android-source. I already made fix for this, so we keep it that way. https://review.lineageos.org/#/c/151839/

I made the following test build for emulated storage. You can dirty flash this over prior unofficial-builds. Since the 'flag' in storage.xml is honered, everything should be unchanged.

One way I tested to switch to emulated storage is to format /data in TWRP. In this build I replaced CM-recovery with TWRP 3.0.3 with emulated storage support.

After formating /data (not wiping) and booting into Android you will see that sdcard0 and sdcard1 are still there and emulated storage is activated. I had to update fstab to get sdcard0 visible in emulated storage mode. (If you encounter permission issues in CM-filemanager, delete .android_secure folder in the root of sdcard0 and/or sdcard1 through recovery)

Download here: lineage-14.1-20170125-UNOFFICIAL-i9100_emu_twrp.zip

Check my github for more details:

https://www.github.com/rinando/android_device_samsung_i9100_emu

https://www.github.com/rinando/android_device_samsung_i9100_emu_twrp

(Optional)

I didn't had the time yet to check REPIT, so I have made a PIT for 16GB-versions (a few days ago) with the following values:

I91001GB_MAX_EMU-16GB.pit

10 FACTORYFS 344.064 - 2.097.152 1 GB (/system)

11 DATAFS 2.441.216 - 27.074.560 13,5 GB (/data)

12 UMS 29.515.776 - 204.800 100 MB (/storage/sdcard0)

13 HIDDEN 29.720.576 - 1.048.576 512 MB (/preload)

Please test the build and let me know how you think about this :)
[Galaxy S II Original Android Development] ale5000:
What is the use of /sdcard partition with emulated storage?

Can it just be formatted as FAT12 and resized to like 100KB?
[Galaxy S II Original Android Development] AchiNo:
Flashed 20170125-UNOFFICIAL-i9100_emu_twrp on top of your previous 20170119 build after I formatted system-data-androidsecure.

Waited forever for first boot, cm file manager could not access the old intSD, but build-in android storage manager could. Copied everything over to emulated, next step repit to 8mb sdcard :good:

EDIT:

repit intSD to 8mb-swap leads to corrupt SD message in OS and can't be formatted within OS (wasn't possible in cm13 either). Although can be formatted through recovery (isorec-twrp). After fixing intSD in twrp, the access of intSD within OS is possible again. Formatting within OS still not working (neither as portable, nor as internal).

EDIT2:

Multi-User working well, too.
[Galaxy S II Original Android Development] the.gangster:
Hi [MENTION=7233491]AchiNo[/MENTION]

compare to what my test on the "non-emulated" version was after manually changing to emulated (the quote above).

In most apps that I tested, the internalsd was not shown any more but the emulated was shown instead. Some like Total Commander needed clearing app-data to do that. Storage manager surely showed all (emu+sd0+sd1). In file manager the access is still possible thru e.g. /mnt/media_rw.

Maybe your results are not so far away from mine?

So i assume, having an formatted internalSD area (whether shrinked to whatever size or not) does not cause problems. I've seen all my apps using the emulated storage automatically from the beginning after switching to emulated mode. Can you confirm?

For now this should still be possible as you can read above. vFat is the default filesystem on it though.

(And keep in mind that within the running ROM you will have the emulated/0 storage linked to /sdcard.)
[Galaxy S II Original Android Development] ale5000:
[MENTION=6560258]the.gangster[/MENTION]: Just in case you haven't noticed I really mean FAT12 (FAT12: 0x01 (MBR), not FAT16: 0x04, 0x06, 0x0E (MBR)) that should allow much smaller partitions, I think it isn't default.
[Galaxy S II Original Android Development] Lanchon:
my REPIT will never support FAT12. partition alignment is 4MB in 9100. if you want 4MB instead of 8MB, pass your own parameters to REPIT. but in REPIT keyword min means 8MB for good reason.

btw i couldnt care less about 4MB, typing this is a waste of time lol :)
[Galaxy S II Original Android Development] AchiNo:
Didn‘t thought of /mnt/ as a workaround, even with root cm file manager couldn’t access intSD, always complaining about root privileges. I doesn't like /storage/uuid, though it showed up as storage in other apps like camera, es file explorer and vlc (only those not supporting external storages didn't show). But haven't encountered any other issues regarding this. Windows shows all three: emu+intSD+extSD

Exactly!

[MENTION=4141005]Lanchon[/MENTION] and [MENTION=2222292]rINanDO[/MENTION]:

If isorec-twrp users are of concern, maybe temporarily disabling isorec-support within the kernel of these test-builds could help, at least until there is a emu-friendly isorec-twrp? My isorec-twrp version is 3.0.2-1, that way I realized that it doesn't match his 3.0.3 and therefore would wipe emu storage if data is wiped.
[Galaxy S II Original Android Development] Lanchon:
naaa it's better to just provide an emu isorec twrp. going back to non-isorec will only cause a lot of confusion.

people know that recoveries are separately flashable now. orlando should not mention anything about any "embedded" twrp in his build next time around (although it's great that he does embed the right recovery) and just provide a separately flashable twrp.

EDIT:

to clarify: you wouldn't have made that mistake if orlando hadn't mentioned anything about an embedded recovery.
[Galaxy S II Original Android Development] AchiNo:
Of course keeping isorec compatibility up and providing emu-friendly isorec-twrp would be preferable. I luckily didn't had such an issue with an accidental wipe, but I can imagine this happening if to careless.

Therefore the idee of "protecting" users by disabling isorec for the time being. But I agree, this could also potentially cause confusion.

Whatever you may choose, I'm just glad to getting closer to official emu-storage thanks to you guys :good:
[Galaxy S II Original Android Development] rINanDO:
I got a new emu-build to test.

You can download it here: lineage-14.1-20170126-UNOFFICIAL-i9100_emu.zip

In this build I removed the sdcard0 mount in fstab.

I also made a seperate ISO-REC TWRP-3.0.3_EMU. Download it here:

twrp-3.0.3_EMU-0-i9100.zip

Please test and report your findings :)
[Galaxy S II Original Android Development] AchiNo:
Tested both;

After flashing new twrp and rebooting in to recovery the new version 3.0.3_EMU-0 is showing, even offers to install the recently released twrp app. Factory reset also spare /data/media :good:

New build booted aswell, intSD no where to be seen, not in storage manager or file manager (including /mnt/), Windows also only shows emu storage. So it's only available in twrp as /sdcard0/ :good:

Seems to work as intended :good:
[Galaxy S II Original Android Development] the.gangster:
[MENTION=2222292]rINanDO[/MENTION]

I only tested and looked at the TWRP and here is a little feedback from my side:

- you can't just change files within the zip without resigning it. The signature isn't valid any longer as you did that. AchiNo must have switched of signature-checking in his recovery to get it flashed.

- You also added support for backing up/restoring EFS, Recovery and Preload (which might be helpful) but you seem to have flagged the Preload with wipeduringfactoryreset, which I would not recommend at all.

- strange thing: when trying to unpack the ramdisk-recovery.cpio of the recovery within the terminal (or adb shell) the cpio threw an "segmentation fault". Don't know why. This would also make some tools like Lanchon's TWRP-patcher break.

Apart from that it really looks good already. It allows to store backups to and restore from sdcard, sdcard0 and sdcard1 (=emulated-storage, internalSD, externalSD).

And it is able to create a backup of non-emulated (internalSD) as well.

Haven't done a restore yet but a trial backup finished successfully.

And finally I wonder how the TWRP-app would react if really installed. Maybe it would suggest to install (non-emulated official) TWRP again?

These are my first impressions for now. Thank you so far.
[Galaxy S II Original Android Development] rINanDO:
Thanks [MENTION=6560258]the.gangster[/MENTION] for your feedback .

You are right. I simple replaced the recovery.img. How can I resign it?

I forgot to remove the flag. I will remove it.

I don't know what is causing this, but I'll investigate.
[Galaxy S II Original Android Development] the.gangster:
[MENTION=2222292]rINanDO[/MENTION]

if you're on Windows you could look at my signature for a convenient signing solution. In the end it's just a wrapper for signapk.jar.

(you should switch the signing keys to testkeys that are usually distributed with signapk)
[Galaxy S II Original Android Development] Lanchon:
just made a zip for you with all the needed files.

you need to use whole-zip signing. use signzip-test for that:

$ cat signzip-test
#!/bin/bash

set -e

script_dir="$(dirname "$(readlink -f "$0")")"

input_file="$1"
output_file="$2"

signapk -w "$script_dir/testkey.x509.pem" "$script_dir/testkey.pk8" "$input_file" "$output_file"
[Galaxy S II Original Android Development] Lanchon:
[MENTION=2222292]rINanDO[/MENTION]

thanks, great work!!

> It allows to store backups to and restore from sdcard, sdcard0 and sdcard1

cool !!!

> And it is able to create a backup of non-emulated (internalSD) as well.

ok!! now if you only could configure TWRP to also backup/restore the emulated SD, **AND** use the same backup ID as for internalSD, then people could use your TWRP to migrate data:

-flash your TWRP

-backup internalSD to external storage

-REPIT (wipes internalSD, resizes /data without data loss).

-restore emulated-storage from external storage

-profit!

otherwise if you can't make both partitions use the same backup ID, then people will have to rename the backup file in external storage.

otherwise if you can't make TWRP backup/restore the emulated storage (you can as [MENTION=912474]Dees_Troy[/MENTION] for help there), then a restore internalSD to emulated-storage flashable script will be needed. hope not.

ALSO

may i suggest changes to the TWRP partition names? i don't think they are very clear now. also, i think TWRP names can and should "Be Readable", no strangeCamelCase in the UI is better!

-"Emulated Storage"

-"Non-Emulated Storage"

-"microSD Card"

depending on your taste, an alternative can be:

-"Internal Emulated"

-"Internal Non-Emulated"

-"External microSD"

keep in mind that each partition *MAY* have two names in TWRP:

-the name shown in the list of backupable partitions.

-the name shown in the "backup to/restore from" storage selection menu.

thanks!