I am wondering if there is anyone interested in bringing transparent "SD-card" encryption to the Galaxy Nexus. On Android 4 there's already encryption for the data partition, also the Galaxy Nexus is using MTP for mounting the "SD-Card" on Windows. So using an encrypted "SD-card" on Windows or somewhere else shouldn't be a problem, as transparent encryption shouldn't affect MTP? So this would lead to the following ideas / requirements:
1) We need an option to disable mounting of the internal "SD-card" when an USB connection is established or else everyone can simply read the content, as the encryption is transparent.
2) Encrypt the "SD-Card" in a transparent way, mount it on boot.There are already implementations of transparent encryption, e.g. LUKS Manager. Use the data partition (encrypted by Android's built in encryption) to store a mount script that contains the password to mount the encrypted "SD-card"
3) Optional: Split the "SD-card" in two partitions, leave one unencrypted so we still have a partition we can use to store backups done during recovery etc.
Anyone interested in doing this?
This ain't development. :'(
Sent from my Galaxy Nexus using Tapatalk 2
if u use a secure lockscreen, sequence, pin or password..and ur device is locked, the content of the sdcard doesn not appear when u attach it to the computer, unless u unlock ur device
andQlimax said:
if u use a secure lockscreen, sequence, pin or password..and ur device is locked, the content of the sdcard doesn not appear when u attach it to the computer, unless u unlock ur device
Click to expand...
Click to collapse
Thanks, good information Still would be nice to be able to explicitely prevent the mounting in general like it was possible on Android 2.x. Anyway, one problem solved
Hello Experts,
I have an AT&T Samsung Galaxy SIII I-747. It was rooted with custom ROM Slim BEAN. After Incorporation of COmpany's Policy, I'd to Encrypt my phone to use Company's emails. There were multiple updates available from Slim bean but I could not install them till iN Decrypt my phone.
The decrypt option was disabled by device administration policy and inspite of removing the email account, it did not enabled the decrypt option in the Security Settings. After reading many blogs, I got to know that formating the device was the only option.
I recovered my phone with CMW recovery mode, and as per instructions, formatted the /system and /cache folders. I was unable to format the /data folder as it was encrypted and it did not allow me to mount.
I am stuck in a situation where whenever i re-start my phone, it just comes to main screen of SAMSUNG and hangs there as the system folder is formated.
I am unable to mount /data folder as it is encrypted. My Phone is no more than a paper weight now
Please help me with your expertised suggestions.
I am wanting to get a clear understanding of the structure of the Android phone - hardware, firmware and software - in particular, relating to the Samsung Galaxy S4 mini, Canadian edition SGH-I257M.
I have been a computer bum since the mid-60s. I have extensive experience with machine and assembly languages, microcomputers and microcontrollers, programming "to the metal" [as we used to say], as well as C and high level languages, and a little UNIX knowledge via QNX from the century gone by. But i have been retired from all that for 15+ years and am entirely new to smartphones and Android.
So i have some questions.
But first, i have read and read and read. Too much hi-tech info the "get it" all at once. In particular i have found these threads specific to the SGH-I257M ...
Galaxy S4 Mini Archive
http://www.s4miniarchive.com/2013/12/How-to-unroot-and-unbrick-Samsung-Galaxy-S4-Mini-SGH-I257M.html
Root new S4 mini model SGH-I257M
http://forum.xda-developers.com/showthread.php?t=2470173
STOCK and ROOTED SGH-I257M
http://forum.xda-developers.com/showthread.php?t=2520299
and several others on rooting various specific-only versions of the S4 mini, CyanogenMod, flashing firmwares, etc. But no complete, tested process for rooting this specific model, or for installing CyanogenMod on it, etc.
And a little history ...
Back in the mid 60s a visiting professor at the University gave a talk entitled "Hardware, Software and Underwear". The title was of course, intentionally provocative. It was a bit mysterious to us at the time, but the idea was to encode low level software in hardware to make it run faster, among other reasons. The term underwear did not stick. Instead we have firmware, and in particular on microcomputers, the BIOS - Basic Input Output System.
Question #1: with regard to Android, my guess is the the BIOS is the interface between the physical hardware and the Linux Kernel. Is this concept of the system structure correct? ...
hardware <-> BIOS <-> Linux Kernel <-> Android System
Question #2: I am not clear on the various categories of memory. The S4 mini has a SIM card, either 8 or 16 gb memory [mine has 16], and may optionally have up to an additional 64 gb memory via a microSD card installed by the owner. Is the BIOS on a separate chip like in microcomputers? Any other memory types? [I have a feeling that i am missing something].
Question #3: Which physical memory contains each of the BIOS, the Linux Kernel and the Android system?
Question #4: I am thinking that CyanogenMod is a replacement for what i have labelled Android System in my simple structure diagram in question #1 above. Is this correct?
Question #5: The idea of rooting the phone is clear to me. I know what is the root directory on a computer hard drive and that the rooting process gives the user access to both that directory and permissions to do anything [delete, rename, replace, install, uninstall, whatever]. And that doing this voids the warranty.
When spring/summer comes along [and they will, even in this cold and frozen Canada!] i expect to be off on my motorcycle [vintage IronHead] for extended periods. I will want to do whatever to extend the battery life of my phone. So i am anticipating rooting the phone by then and perhaps installing CyanogenMod. I have not yet seen a clear process for rooting for the Canadian S4 mini SGH-I257M including making appropriate backups of the system software, or for installing CyanogenMod, but i am looking. Any pointers to this i would appreciate.
Question #5: Any books on this topic of Android system structure, especially wrt Samsung smart phones? I know, books are so last century; so maybe a website, forum thread, or whatever.
TIA! More ?s later.
Mick
OK, i got some answers on another forum, and these answers have been very helpful. So as i understand things now, ...
The BootLoader is in a rewriteable ROM, an actual physical chip
The 1.5 gb RAM is what i have been missing. This is where currently running programs are stored, temporarily, until both they are no longer running and the system needs the RAM to run another process
The 16 gb storage is equivalent to the hard drive on a PC. All software - Android system and apps - are stored here, and are loaded into the RAM when they need to run. The storage is divided into partitions.
I can see what programs are currently in RAM by Settings | more | app manager | running
I can see what programs are in storage by Settings | more | storage
As mentioned, the common use of the word ROM does not refer to an actual physical ROM chip or to software that might be loaded into one. Rather is is a generally accepted but misused term for replacing the whole [or perhaps part of the] operating system.
So now i have two more questions/thoughts ...
What about these partitions? Are these really partitions like on a PC hard drive? or are these really sub-directories of the root? There would be certain partitions, standard with the Android setup, each with a specific purpose. It would be helpful to know at least a few of these.
In my running apps list i see S Voice. Hhmmmm, i thought i deleted this app. I know i did. I do not need it to be in there, taking up space and CPU cycles. I expect that it is OK to Stop it, and that it will re-start itself next time i power off/up. I'll have to go down that list and see what else i can "put a stop to".
TIA. More ?s later.
Mick
Got some more info from the other forum, including this excellent link to an explanation of the partitions, so things are moving along ....
http://www.addictivetips.com/mobile/android-partitions-explained-boot-system-recovery-data-cache-misc/
Looks like the "partitions" are "directories", using the old MS-DOS and UNIX terminology. So once rooted, ...
cd / goes the the root directory, or
cd /recovery goes to the recovery directory
and ...
ls
would list the contents of whatever is the current directory.
Mick
Hello,
I'm having trouble with my Galaxy Nexus (GSM). It randomly reboots at least once a day, but more importantly lags for more than 10sec within any app and even on the homescreen (not all the time, but also not app-specific).
I'm currently running:
AOKP jb-mr2 (JB 4.3) with
lean kernel 8.3 (JB 4.3)
- /data and /cache are mounted with the discard option and TRIM is performed regularly (though manually, no cronjob)
- there's more than 4 GB free space
As suggested here (german forum - 'HAL 9000' in that thread is me btw) I tried looking for bad blocks in the logs, but didn't find any signs using logcat (searching for 'I/O' or 'error' or 'panic'). There is no proc/last_kmsg on my device that could give me information about the reboots, unfortunately.
I'm fairly sure, that there is a HW failure on my device, but I want to have proof before buying another phone. I also don't want to do a hard reset with the need to reconfigure everything only to find out, that I indeed had a HW failure and all my reconfiguring was in vain. I already tried doing a NANDROID backup via CWM and immediately restoring it (in order to have the eMMC map out bad blocks when rewriting the memory), but that didn't have any effect.
So, I need suggestions on how to prove or disprove a HW failure on my device without losing all my data, i.e. without a hard reset.
Greets
Atreus
OK, this thread is going to be a work in progress, intended to serve as a reference for the work I've been doing on LVM partition remapping.
My work was done initially on a Find 7, but this should eventually be usable on many other devices (I have the Find 5 and N1 in mind for when I return from vacation). Also, this would not have been possible without the work Steven676 did years ago on the Nexus S, which has been used by all AOSP-derivative projects to support the Samsung Aries (Galaxy S) family for quite some time now.
The current state of things is that the patches are solid and work very well for the system side of things, but there is still a bit of work needed on the recovery side of things. This is due to TWRP having an architectural limitation I need to work on - Whether a device uses emulated storage or not is set at compile time, which is a problem if your design requires automatic detection of configuration at run time.
One of the key design goals here was to support both normal and LVM configurations automatically with a single build that detects which configuration is present on a device at run time.
A second key design goal was that the underlying partition table of the device is not touched in any way. Touching the partition table of a mobile device in the field is a fundamentally dangerous operation, as many partitions contain data that is device-unique or will render a device unbootable if altered. Recovery methods that involve DDing partition images to nonstandard partitions is asking for trouble due to typos... There's no protection against a user typoing the name of a critical partition.
Initially, I'm going to dump the contents of an email I wrote to someone giving them documentation on how to integrate LVM into their project. Over time I'll clean up and reorganize this post, including adding some more links. Also, since this email was written, I've added a LOT of comments to each patch explaining what is going on.
For additional documentation, especially a more user-oriented view of things (such as how to set this up if you want to use it with Omni nightlies) - see the Omni nightlies thread on XDA.
So here goes:
How it's implemented - the complete patch set is at:
https://gerrit.omnirom.org/#/q/topic:find7_lvm - Expect this to periodically change as work on this feature continues (Note: All patches required to support nightly builds of Omni have been merged. At this point, all remaining work that I expect is on polishing up TWRP.)
With the rest of this post, I'll talk about each individual patch and what it does.
https://gerrit.omnirom.org/#/c/9273/ - This is a patch against frameworks/base which adds an alternative to storage_list.xml called storage_list_lvm.xml - The frameworks will choose storage_list_lvm.xml instead of storage_list.xml if the property ro.lvm_storage is set to 1 - The device init scripts will set this property if they detect an LVM configuration.
https://gerrit.omnirom.org/#/c/9207/ - This is an Omni-specific patch. Omni builds for both the Find 7 and OnePlus One (also known as find7op) and both share a common device tree. The LVM patches do not apply to the find7op, so we move init.recovery.rc out of the msm8974-common tree - You likely don't have to worry about this unless you also have a -common tree for find7 and find7op
https://gerrit.omnirom.org/#/c/9276/ - Normal Android kernel ramdisks do not include busybox or any form of shell, making it impossible to run shell scripts without /system mounted. Since we need to run a shell script prior to mounting partitions, we need to add busybox to the ramdisk. This patch does that. For legal reasons you may wish to replace busybox with system/core/toolbox and system/core/sh - I have not tried doing so. If you choose to stay with busybox, you will have to provide the busybox source code in order to comply with the GPL.
https://gerrit.omnirom.org/#/c/9205/ - This adds the LVM binary and LVM configuration file to the ramdisks of both normal boot and recovery. This patch does not actually begin doing anything with the binaries, I separated it out from the other patches as a way to keep things organized so I could start working with the binaries when I began this project. The original source code and documentation for the binary is at https://github.com/steven676/android-lvm-mod
One change I made in lvm.conf that differs from the Samsung aries family (galaxysmtd, fascinatemtd, captivatemtd, etc.) is that I changed the filter line to only allow the userdata and sdcard partitions. This prevents LVM's vgscan from accidentally determining another partition is a physical volume, and also prevents users from accidentally running pvcreate on a critical partition.
https://gerrit.omnirom.org/#/c/9206/ - This is where all of the "heavy lifting" is done. I'm going to work on adding more comments to the init scripts and shell scripts to document them tonight and tomorrow, but I'll try to explain things here.
Android's init system is a bit limited in that it's very difficult to have conditional behavior defined in init.rc - which appears to be why Qualcomm loves to use shell scripts called from init. Similarly, much of the LVM magic happens in three shell scripts (which execute at three different phases within the boot sequence).
In the early-init phase, the two "wait" blocks ensure that the underlying block devices are ready before vgscan/vgchange are called. This will probably slow down booting by a few fractions of a second unfortunately.
vgscan will scan the volumes defined in lvm.conf (in this case, only the userdata and sdcard partitions) for LVM physical volumes. If LVM physical volumes are detected and form a proper volume group, vgscan will create appropriate device nodes. With the configuration I'm using, the device node will be /dev/lvpool/userdata - which consists of a single logical volume that merges the sdcard and physical userdata physical volumes (partitions). The configuration of lvm.conf prevents LVM commands (especially pvcreate) from altering partitions we don't want to alter. If someone accidentally tries to, for example, run pvcreate on the system partition, it will give an error indicating that the partition was not part of the filter.
vgchange will activate the physical volumes detected by vgscan
lvm_init.sh will check to see if /dev/lvpool/userdata exists, and copy fstab.qcom.lvm to fstab.qcom, init.fs.rc.lvm to init.fs.rc, and twrp.fstab.lvm to twrp.fstab if it does. If it does not, it selects fstab.qcom.std, etc.
In the "on init" section, the init script exports all environment variables from init.fs.rc, and creates all storage-related directories and symlinks needed for both configurations (except for when they conflict). lvm_symlinks.sh will create directories/symlinks that must be configuration-specific. Just like lvm_init.sh - it decides what to do based on whether /dev/lvpool/userdata exists
In the "on fs" section - we do an SELinux restorecon on /dev/mapper/lvpool-userdata (/dev/lvpool/userdata would probably work here too). If it doesn't exist, this will fail gracefully without causing any issues.
In "on early-boot" - lvm_setprop.sh uses /system/bin/setprop to set ro.lvm_storage to 0 or 1 depending on the detected configuration. The property service is not available until early-boot - so this cannot be in lvm_init.sh or lvm_symlinks.sh This propery is used by the frameworks/base patch above to determine which storage_list to choose.
At the end of the init.qcom.rc, the fuse daemon for emulated storage is added for all configurations. (I could not figure out a good way to make this conditional based on whether LVM was present or not). In a non-LVM configuration, it runs but is harmless - it maps /data/media (which is empty) to /mnt/shell/emulated (which nothing is looking at due to the environment variables and symlinks set in the "on init" section )
You will probably notice that Omni's standard storage configuration is fairly different from ColorOS - this is due to the way KitKat storage works, but it allowed us to get away without using Oppo's ext4 permissions hacks in our kernel (by remapping permissions instead, in a manner similar to how the emulated storage system works) The way we handle our /sdcard partition does interoperate without issues with the ColorOS approach.
https://gerrit.omnirom.org/#/c/9279/ is a patch specifically for TWRP. TWRP currently determines whether to use emulated storage (/sdcard on /data/media) at build time instead of at run time. Until I have time to fix this, the patch here operates as a workaround. It is similar to the behavior of the fuse sdcard daemon in the previous patch - it maps /data/media to /sdcard whether the configuration is actually emulated storage or not. If the device is not using emulated storage (LVM), mapping of /data/media to /sdcard is still mostly harmless. However it does result in undesirable changes to TWRP's user interface. DO NOT USE THIS APPROACH IN PRODUCTION RELEASES. It's a horrible hack. You'll need to figure out how to properly do /data/media handling depending on whether LVM is present or not based on how your own recovery architecture works.
https://gerrit.omnirom.org/#/c/9281/ adds "raw" sdcard and userdata partition entries to the partition table for the LVM configuration. This allows a user to return their device to a standard configuration by formatting the underlying sdcard and userdata partitions directly, instead of the removelvm ZIP at the beginning of this email. - To be abandoned, this patch was squashed into 9206
FAQ
Q: Coldbird already had repartitioning support. Why did you create this different approach?
A: Even before he started work, I strongly recommended that he not touch the partition table of the device. It's a really bad idea and is fundamentally dangerous. It's pure luck that someone hasn't hardbricked yet. (A number of people have come close.) If you read through his thread and the ColorOS 2.0.2 thread, you'll see that the repartitioning approach fails frequently, and in multiple ways. (Missing partition contents, partition table ending early, etc. The latter is really scary, one person had the process fail at mmcblk0p19 - what if someone else's partition table write operation aborted even earlier?.) Also, nearly everyone that has implemented support for that approach has needed a separate build to support it. (Oppo is the first to manage autodetection.) I also provided him all of the reference information from Steven676's work.
LVM is far safer. The underlying partition table is not touched in any way. Instead, LVM remaps sectors on the fly so that two partitions that are not adjacent to each other on the physical storage appear as a single contiguous partition to the filesystem drivers. Linux has supported LVM for on the order of a decade, if not more. I've been using LVM on my file server since 2006. (Yes, the system is 8 years old and still working other than needing a new power supply after a thunderstorm. Nothing to do with LVM. ) In addition, the lvm.conf configuration used here provides protection against accidental typos causing damage. Undoing the changes is as simple as doing a wipe of /data and /sdcard from any standard recovery and can be done in seconds, not of running a special batch file that runs a bunch of fastboot commands and takes 4-5 minutes. Similarly, the LVM setup process currently described in the Omni thread involves flashing a single ZIP from recovery that takes only 10-15 seconds, and most of that process is flashing an LVM-aware recovery. (The only limitation currently is that the ZIP must be on external storage - USB OTG or MicroSD)
To put it simply, it Just Works. No need to back up a pile of partitions other than /data and /sdcard because those partitions are never touched or altered.
Q: I have a device with a ridiculously oversized /system partition, can I get some of that back for /data?
A: Yes, you can. Add the physical /system partition to the lvm.conf filters and add it to the lvpool when creating it, then create a smaller /system LV out of this big pool. (see updater.sh in device/samsung/aries-common/ of any AOSP-derivative for hints here.) Be careful though - leave enough spare space for growth (new Android versions, etc.) While it should be possible to use some of the LVM tools along with ext4 resize tools to reorganize the LVs without wiping, this is very difficult and you'll probably have to make users wipe /data if you want to alter /system.
*reserved 2*
Nice work, I hope all the patches can be widely used on some other devices and other roms.
systop said:
Nice work, I hope all the patches can be widely used on some other devices and other roms.
Click to expand...
Click to collapse
Yup. I know Andre from PA was working on it last week but I haven't heard from him lately.
My priority when I return from vacation will be fixing up the TWRP side of things. It's working for now, but the user interface on non-LVM configs is a little funky thanks to RECOVERY_SDCARD_ON_DATA being compile time. This has never been a problem before since a single TWRP binary never had to support two different configurations before. I plan on either doing a property-based approach or fstab-based like CWM. (It should be possible for someone to make a CWM build that automatically detects configuration without any modifications to CWM, based on reading the code - but I haven't tried it myself.)
Once TWRP is in better shape, I plan on doing the Find 5 and N1. These will have the challenge of not having a MicroSD slot, so I may have to change TWRP so that it use /tmp instead of /sdcard when doing "adb sideload", or at least gives the user that option.
Good stuff :good: I don't really need it as of yet, but when my new device is provided (warranty) I will surely give this a try.
I hope ayysir will merge the LVM support very soon ^^
Find 7u PA 4.6 beta 1
Awesome work mate. I have avoided other methods because I'm always the guy that will have a device fail at very bad timing; like during boatloader or SBL stage.
I'm really glad you have continued to work on this. I have hit thanks a few times but would also like to thank you here
tork987 said:
I hope ayysir will merge the LVM support very soon ^^
Find 7u PA 4.6 beta 1
Click to expand...
Click to collapse
He had issues with merging support, hopefully now that I've added more documentation he can try again.
how are the *.std files created?
atm this is tough for me to port from omni to cm base which AOSPA Oppo trees
ayysir said:
how are the *.std files created?
atm this is tough for me to port from omni to cm base which AOSPA Oppo trees
Click to expand...
Click to collapse
the std files are also part of the device tree
https://github.com/omnirom/android_device_oppo_find7/tree/android-4.4/configs
ayysir said:
how are the *.std files created?
atm this is tough for me to port from omni to cm base which AOSPA Oppo trees
Click to expand...
Click to collapse
For the fstabs - they are simply moves/renames of the fstab files and other storage-related items from the standard Oppo configuration (they should appear as renames/moves in the Gerrit commit...)
For the init.fs.rc file - all of the "export <blah>_STORAGE" lines from init.qcom.rc/init.find7.rc are cut out of the RC file and put into .std
Obviously, the .lvm versions of the files are the ones where the fstab has been altered to support a single data partition with emulated storage.
Amazing work and amazing posts. Thanks a lot for your sharing. ?
I've got a question related to your configuration (/data and /sdcard merged) : are the LV hot-resizables?
Wendigogo said:
Amazing work and amazing posts. Thanks a lot for your sharing. ?
I've got a question related to your configuration (/data and /sdcard merged) : are the LV hot-resizables?
Click to expand...
Click to collapse
In theory, you could probably use some of the ext4 resizing tools to do something like this, but I haven't looked into it as there isn't much point in the current config (since the LVM userdata volume is allocated to use all space on the volume group).
Something like that might be more useful if someone ever uses LVM to regain some of the wasted /system partition space on certain excessively bloated devices (like some GS4 units).
Entropy512 said:
In theory, you could probably use some of the ext4 resizing tools to do something like this, but I haven't looked into it as there isn't much point in the current config (since the LVM userdata volume is allocated to use all space on the volume group).
Something like that might be more useful if someone ever uses LVM to regain some of the wasted /system partition space on certain excessively bloated devices (like some GS4 units).
Click to expand...
Click to collapse
Thanks for your answer.
Seems I misunderstood the way it's implemented here. All space is allocated to /data? So there's no more internal sdcard right?
But in that case an external sdcard is mandatory. How is it managed when there's no sdcard?
Enjoy!
Wendigogo said:
Thanks for your answer.
Seems I misunderstood the way it's implemented here. All space is allocated to /data? So there's no more internal sdcard right?
But in that case an external sdcard is mandatory. How is it managed when there's no sdcard?
Enjoy!
Click to expand...
Click to collapse
Android has supported emulated storage (where /data/media is mapped to /sdcard with a special FUSE daemon that makes /sdcard have DOS-like permissions despite an underlying ext4 partition) since ICS. It's pretty much the standard in all new devices - the Find 7 is to my knowledge the only device launched in 2014 not to use emulated storage. Most devices in 2013 also did - Oppos were again the rare exception.
As I understand it - for some reason Chinese users prefer the legacy pre-ICS partitioning scheme. My guess is due to UMS vs. MTP - MTP is required for access to emulated storage, UMS can't be used, but a lot of older desktop OSes have issues with MTP. So Oppo finds themselves in conflict between their home market (China) and expanding in the West. That said, the Find 7 was kind of a screwup in achieving this goal, since the internal sdcard partition was ext4 which meant UMS was a no-go for it.
Entropy512 said:
Android has supported emulated storage (where /data/media is mapped to /sdcard with a special FUSE daemon that makes /sdcard have DOS-like permissions despite an underlying ext4 partition) since ICS. It's pretty much the standard in all new devices - the Find 7 is to my knowledge the only device launched in 2014 not to use emulated storage. Most devices in 2013 also did - Oppos were again the rare exception.
As I understand it - for some reason Chinese users prefer the legacy pre-ICS partitioning scheme. My guess is due to UMS vs. MTP - MTP is required for access to emulated storage, UMS can't be used, but a lot of older desktop OSes have issues with MTP. So Oppo finds themselves in conflict between their home market (China) and expanding in the West. That said, the Find 7 was kind of a screwup in achieving this goal, since the internal sdcard partition was ext4 which meant UMS was a no-go for it.
Click to expand...
Click to collapse
I've got it now. Thanks for your explanations
I saw that Oppo phones didn't follow Android guidelines (yet?) by not using the emulated_storage mounting method but I didn't know why.
And your right, mtp doesn't work in Windows XP (or is hard to make working) and there's a lot of Asian people still using it. Obvious once you said it...
And that's also why only external sdcard is accessible in UMS mode in recovery.
Thanks again for your enlightenment. ?
Reading some of the comments on G+ it looks like Oppo might be using this solution for their KitKat release. I would be so pleased if they did.
Sent from my X9076 using Tapatalk
kishd said:
Reading some of the comments on G+ it looks like Oppo might be using this solution for their KitKat release. I would be so pleased if they did.
Sent from my X9076 using Tapatalk
Click to expand...
Click to collapse
You could be pleased...
Wendigogo said:
You could be pleased...
Click to expand...
Click to collapse
Had some problems with camera focus on earlier versions of omnirom for find 7. Now those have been addressed. I installed Omni and am on the nightlies with lvm. My find 7 and find 7a will not see another rom again.