yashsingh1/xdaforums huggingface dataset:
[Nexus 7 Android Development] vorcers:
Now it works again at my nexus with 1.55... I can't really understand this. This reminds me more of the mount-tests after the release of Android 4.2. I don't want to get trolled by SuperSU anymore.... goodbye SuperSU.

[MENTION=3567557]glimmling[/MENTION]

I don't think so. You need to wait 3 seconds till you can press a button. And you can preserve your desicion only for 10 minutes. (if it is not permanent) Well, you have to test it yourself.....
[Nexus 7 Android Development] adxgrave:
Tried it before but got some serious bug if using adb shell and terminal, some command like busybox mount just echoed back. It doesn't run it. The same goes to terminal app and some app that i use to run script like $cripter failed to execute the script.
[Nexus 7 Android Development] vorcers:
It is right, that su echo it back. But it runs the command. At least on my nexus. (See screenshot in the attachments, I begin the test at the middle ; sorry for the bad quality. My .PNG gets converted to .jpg and I don't know why))

I also use "SManager" too run my Oneclickmount script. This works really good with the new superuser. Maybe it was an old version and the bug is fixed now?
[Nexus 7 Android Development] adxgrave:
I've check github, someone solved the echo bug only recently. Maybe while I'm testing it the command did run and it echo too. Not very sure now because of that echo weirdness. I'm using superSU v1.51 now on my own kernel but almost the same as yours with mkasick patch, nfs and cifs build-in and init.d. My nfs is mounted at boot by init.d script. That has settled it. I saw that you've successfully test this with superSU v1.55? It works again like superSU v1.45?

Edit: test with v1.55, nope not working. An empty mount in /data/media/0/mountpoint even from adb shell. With chainfire's su it's like there is no root user only each app can be root in their own world. It made the very patch that we applied back to square one.
[Nexus 7 Android Development] ThurstonX:
I've definitely got CIFS working with SuperSU 1.55, with vorcers' v6 kernel, and JWR66Y. I use /mounts as the base mount dir (created in adb shell and set to 777, owned by root:root ; I suppose creating it in ESFileExplorer or whatever may work, but I used adb shell). I use Mount Manager, set it to use /mounts as the Base Mount Point, and have all seven options under "Mounts" and "Modules" in the settings checked. Works like a charm, and just like 1.45. I've got a shortcut to /mounts on the main screen, and of course it's visible in ESFileExplorer. There's a very slight delay when I first open the /mounts folder, but I assume that's root permissions being granted. I do set SuperSU's default action to "Grant", but that shouldn't matter, just makes it easier.

The problem I had with SuperSU 1.51 was that /mounts was destroyed when (re)booting, and of course empty folders after manually creating it and letting Mount Manager do its thing.

My CIFS shares (on two NASes) just use guest, and I specify ro.

HTH.
[Nexus 7 Android Development] ThurstonX:
Well, this is a real LMAO moment. After booting the N7 this morning, my CIFS folders were empty, and Mount Manager gave the "can't chmod /mounts..." error when attempting to mount them manually. I reverted to 1.45 and of course all is fine.

Then, for a lark, I upgraded to SuperSU 1.60. Of course, CIFS mounts are there and populated. LMAO. As a final test, I powered down, then powered on. CIFS still populated... for the moment.
[Nexus 7 Android Development] vorcers:
I tested today SuperSU 1.65... and its seems to work. ThurstonX also said this with 1.60....

[MENTION=4925283]ThurstonX[/MENTION]

Can you tell if SuperSU >= 1.60 is working for you? Are your cifs shares still visible?
[Nexus 7 Android Development] ThurstonX:
1.60 mostly worked, though there were a couple of instances when the CIFS shares were empty. A reboot fixed it. But then I upgraded to 1.65, and it's been rock solid ever since. And today I upgraded from v.6 of your kernel to the v.7 all-inclusive package, as I want to try USB audio with a DAC I'm expecting this week. Previously I was not using the separate modules zip. The first thing I did after flashing v.7 was to check the CIFS shares. All present and accounted for :)
[Nexus 7 Android Development] ThurstonX:
USB Audio and external DAC

vorcers, or anyone who can answer,

should a USB DAC (HiFimeDIY Sabre U2 Asynchronous) be recognized and usable with V7 of your kernel, or do I need to do something else? Here's what I've tried and learned so far:

Used USB Audio Tester (from Play Store) to see if the DAC is recognized. It is.

Used USB Audio Recorder Pro to test playback. I works, albeit, it has its own driver. I'm pretty sure one does not need a usb-audio-enabled kernel for UARP to work.

All the player apps I tried would not route audio to the DAC. It was either speaker or headphone. I tried attaching the DAC to the OTG cable and then booting the N7; tried booting and then attaching, and then rebooting with OTG+DAC still attached. No joy. Is there a specific player or players that work with USB DACs, and some that don't? I only have free players (AIMP, Folder Player, VLC, VPlayer; well, I have DeadBeef Pro).

I'd prefer to stick with your kernel, as I can run the latest iteration of the stock 4.3 ROM, but I'm wondering if the USB ROM with Timur's kernel would work better or more easily. Sadly, there's no more development going on there.

One other question: does your V7 kernel allow for charging the N7 will using the DAC or anything else connected to the OTG cable? I'm thinking of getting an OTG 'Y' cable, but want to be sure.

Thanks!
[Nexus 7 Android Development] vorcers:
I don't really know how this usb-sound-thing works, I can't test it. I just included the kernel modules. Maybe I didn't included enough. If someone can tell me, which files to patch, I could do that. It is possible, that the usb-sound doesn't work without patching the rom.

My kernel doesn't support otg+charging. I didn't included any patches.

I looked into the USB-Rom for the Nexus 7 and couldn't find any sources. I hate this. No one provides any sources for what they created. Timur didn't provided any sources. But since he modified the kernel sources, I think he needs too... (GPL?)

If I have had the sources of timurs kernel I maybe can include it or develop it further, but without...
[Nexus 7 Android Development] ThurstonX:
I had a feeling that was the case. Appreciate you looking into it.
[Nexus 7 Android Development] sgt. meow:
Mehrvarz's 4.2 repo is available on Github. Check this: https://github.com/mehrvarz

USB DAC is really hard to get it right on 4.3.
[Nexus 7 Android Development] vorcers:
[MENTION=4394172]sgt. meow[/MENTION]

Thanks for the source. I will try to integrate this when Android 4.4 is out.

I will supply the changes of timur to the cyanogenmod kernel tomorrow. (https://github.com/mehrvarz/android_kernel_asus_grouper/commits/cm-10.1)
[Nexus 7 Android Development] ThurstonX:
Sorry for the noob question, vorcers, but does this mean your 4.4 kernel will support USB audio and OTG charging? Hope so, as I'm not in love with USB ROM. I'm sure it's great for fixed installations, but I really prefer the stock ROM experience with your kernel. Much easier to get CIFS working. I'm greedy, and am looking for the best of both worlds :D

Appreciate all your hard work!
[Nexus 7 Android Development] vorcers:
I attached the diff's of timur's patches to the kernel from GitHub. (If someone is intrested in...)

[MENTION=4925283]ThurstonX[/MENTION]

Maybe. I can test the usb-sound because I found an usb-"soundcard". If the soundcard works with usb-rom I can also test it with the modifications on the kernel.

But I CAN'T Test the Host-Charging with OTG. I have no such cable...

I also don't know yet how this usb-otg-with-charging works. It can damage your nexus 7. I think I will also supply an kernel-version without the usb-otg-with-charging modifications.
[Nexus 7 Android Development] vorcers:
I created an test-kernel for the usb-sound things. It also includes the usb-host-patches. (Set as an NON fixed installation)

It didn't worked for me - I got at the probe an "failed with error -5" at dmesg at the sound-card-probe.... If I connected it at boot. If I connect it at runtime, it prints "##### sound/usb/card.c snd_usb_audio_probe done OK" at dmesg, but I can't hear any sound. Maybe my device isn't supported. (I didn't tested timur's original kernel)

The patch I attached in my last post is very easy to include in the current kernel. There was only one reject.
[Nexus 7 Android Development] ThurstonX:
Quick work, thanks! I'll try to test it today. I'll need to backup my USB ROM install and restore my stock 4.3 + your V7 kernel first.

I'm not sure if this is correct, but reading about Timur's kernel vs. USB ROM, there seem to be some differences, esp. in how devices react when attached. See the "Using an USB DAC" section of the kernel page. That differs from USB ROM's hot-plugging capability, at least that's how I read it.

Which DAC/USB soundcard do you have? You could try the trial version of USB Audio Recorder PRO, though maybe that's not a valid test for this situation.

Anyway, I'll try to test today and post results.
[Nexus 7 Android Development] ThurstonX:
Stupid question: do I need to wipe /system before flashing your kernels, or is that function built into the script?

~~~~~~~~~~~~~~

LOL. Told you it was stoopid. <HEAVY sarcasm>It's always a good idea to wipe the ROM before installing a new kernel, right?!</HEAVY sarcasm>

Multi-tasking is draggin' me down ;)
[Nexus 7 Android Development] ThurstonX:
Installed it. I first connected my DAC and a USB stick via an unpowered 4-port hub after booting the N7. I grep'd dmesg for 'usb' and did not see the error you mention. But sound did not go out to the DAC.

I then unmounted, unplugged the OTG Y-cable (was not using power, just wanted to test the cable), used a simple, single-ended OTG cable, and only plugged the DAC into it. Actually, I use a USB isolator before the DAC, but it just takes and passes power to the DAC. Then I rebooted. The USB isolator gets power, and the optical out (dual-use port with a standard 3.5mm jack) glows red. I checked the full dmesg log this time, and, like you, I get the "failed with error -5". And as before, sound only goes to the speakers.

Lastly, I unplugged the OTG, waited, then plugged it back in. I grep'd dmesg for 'usb' again, and the DAC was recognized, and no error message. But no sound to the DAC, either.

In all cases my HiFimeDIY DAC is detected and listed in dmesg.

So, this behavior is about what I experienced with V7 of the kernel. If there are any specific tests you want me to run, let me know.
[Nexus 7 Android Development] vorcers:
<Rejected>

I don't know if the source I used are applyable for the stock rom - it is possible that this source is only usable on the usb-rom. But I couldn't find any other kernel-sources from timur at github....

My Card is an "SB X-Fi Surround 5.1" from Creative and is recognized by Usb Audio Tester.

Edit: Did you mean V8.1 instead of V7?

I don't even have an Idea how this usb-sound-thing works...
[Nexus 7 Android Development] ThurstonX:
Well, I wouldn't waste too much more time with it, unless you're really set on making it work. If so, I'll keep testing :)

I read in another thread that no dev had gotten USB Audio to work on 4.3, and he was searching all over for a kernel that supports it. Not sure if that's true or not. I asked about it in faux123's kernel thread, but have not heard if it's working in his latest. I might try it. Gotta get back to a couple PC upgrades :)

Oh, at the end I meant that my testing of V8.1 pretty much mirrored my experience when using V7 of your kernel. But I guess you knew that USB audio wasn't really functional under V7. Sorry for the confusion.
[Nexus 7 Android Development] sgt. meow:
Some really nice people are trying to get the 4.3 source code for USB DAC and stuff from Timur's newer kernel (which he never released ??)
[Nexus 7 Android Development] ThurstonX:
Hurray for really nice people! :)

Hope they include OTG + Charging :D (said the greedy bastard).
[Nexus 7 Android Development] SlavPala4a:
Yes! Timurs' rom development should be continued somehow...

Please
[Nexus 7 Android Development] vorcers:
? Is it an fact that he created it for 4.3 ?

Anyway, it could be possible, that this "hard" usb-sound modification is just not possible with 4.3 anymore. Because of that, we never seen an release.

For all these people who still wants to use it - with my kernel (and any other kernel which include the usb-modules) it is possible to access the usb-dac through apps which support this. Google has an api for that. For example "Usb Audio Tester" uses this API. (https://play.google.com/store/apps/details?id=de.sobe.usbaudio&hl=de)

Anyway, I think Android 4.4 will be the last Android for the Nexus 7 (Because they already kicked out the Galaxy nexus ; The Nexus 7 has been released in july 2012. 18 months later (january 2014?) support will be dropped. The next Android could be released in may/june/july 2014).

With this "fact", KitKat will be the last stock android release for my kernel. I will switch to cyanogenmod 11 as soon as an snapshot gets released for the nexus 7. I maybe release some cifs/nfs modules for the cm11 kernel (Because they doesn't support cifs out-of-the-box). The empty-directory patch is integrated in cm in dalavik.

Off-Topic:

I tried Android 4.4 today... (Paranoid Android AOSP build with gapps)

I think, it is an fact, that google will release an launcher to the play store these days. Because the new Gapps from the Nexus 5 also include "Google Home" the String is "com.google.android.launcher". The AOSP Launcher isn't updated anymore.. The google search is very deep integrated in this launcher. For example, on Android 4.3 you could disable the google app - and the launcher still worked. Now it doesn't work anymore...

It's hard for me to say, but Google really destroys AOSP. Also see this article: http://www.wired.co.uk/news/archive/2013-10/21/googles-iron-grip-on-android

I think, Google wants too include the user more with the google-services. I am concerned about the future of (AOSP) Android........
[Nexus 7 Android Development] ThurstonX:
Fascinating article. Thanks a lot for the link. I learned a lot, both the history and the possible future. Google certainly is one clever company. If it weren't a business thing, I'd call them hypocritical for starting the AOSP (if I read it correctly), then throwing it under the bus. A pity, to be sure, but predictably understandable.
[Nexus 7 Android Development] vorcers:
Android 4.4 Kernel Config File

Just for the reference, here again the config file from the factory images for Android 4.4 Grouper.

Just for your info: It is possible, that I can't do any development in the future for the Nexus 7, because I completly f*** up my tablet. It is completly dead. Not even the APX Mode is working anymore.

And even if it would work, I don't know which kernel sources I should use for Kitkat - on https://android.googlesource.com/kernel/tegra/+refs I can't find a 3.1 kernel for Kitkat. Can someone tell me the Kernel-Version with appandix for 4.4 on the Nexus 7?

Edit: It seems, that they used at Kitkat the same Kernel as in Jelly bean, they changed only one kernel Option:

--- stock-wifi-4.3 2013-07-25 12:30:59.144037951 +0200
+++ stock-config_grouper_android_4.4 2013-11-15 14:09:22.950746648 +0100
@@ -1222,7 +1222,7 @@ CONFIG_BCMDHD=y
CONFIG_BCMDHD_FW_PATH="/system/vendor/firmware/fw_bcmdhd.bin"
CONFIG_BCMDHD_NVRAM_PATH="/system/etc/nvram.txt"
# CONFIG_DHD_USE_STATIC_BUF is not set
-# CONFIG_DHD_USE_SCHED_SCAN is not set
+CONFIG_DHD_USE_SCHED_SCAN=y
CONFIG_DHD_ENABLE_P2P=y
# CONFIG_HOSTAP is not set
# CONFIG_IPW2100 is not set
[Nexus 7 Android Development] glimmling:
Hi vorcers,

I'm sorry with regards to your Nexus 7, but this could be a good reason to upgrade to the 2013 edition. ;)

I made the KitKat update yesterday and got bootloops with your 4.3 kernel. So I'm back to the stock kernel.

I think there will be a solution sooner or later.

Greetings!
[Nexus 7 Android Development] sgt. meow:
If you can take out the ramdisk and put the zImage in an AnyKernel ZIP. It'll work then.
[Nexus 7 Android Development] vorcers:
Ah thanks, sgt. meow, I forgot the Kitkat ramdisk!

I uploaded a new version with the Kitkat ramdisk, but still has the old v7 kernel. Maybe someone can test it?

http://www.mediafire.com/download/8dmfco4knkaaa2i/boot-grouper-vorcers-g1e8b3d8-v7_forKitKat.zip

I also created a flashable zip with the stock kernel, maybe someone can also test this, so I can link this to the first post.

http://www.mediafire.com/download/9x47xtov747b123/boot-grouper-stock-wifi-4.4.zip
[Nexus 7 Android Development] bonzer2u:
Just downloaded and will be giving them a spin shortly, thx..
[Nexus 7 Android Development] Erik38:
cifs again with kitkat

Hi All,

I have flashed this kitkat modified version boot-grouper-vorcers-g1e8b3d8-v7_forKitKat, it works fine :)
[Nexus 7 Android Development] glimmling:
Yes, it works now. But my cifs shares are write-protected now. No problems with 4.3. Do you think, this is related to cifs module, SuperSu or KitKat?

Gesendet von meinem Nexus 7 mit Tapatalk 4
[Nexus 7 Android Development] vorcers:
Would you kindly to answer me these questions to identify the problem?

Where did you mounted it? In /data/media/0 or not? Is it writeable if you mount it in /mounts ?

Can you provide me an print-out of "mount" after you mounted it?

Is the mounted share writeable via root? (on adb or per terminal)

Background: The Android-Devs changed the Permissions of /storage in Kitkat from 0500 to 0751 - I also did this change. But it shouldn't have any effects.

And it mustn't be any any fault with the kernel (or the module) they are 100% the same as in Jelly Bean!
[Nexus 7 Android Development] glimmling:
Hi. I sent you a PM.
[Nexus 7 Android Development] vorcers:
I am very happy to say, that I got my nexus 7 back and I can now test the Kernel within kitkat.

I maybe also create an kernel for the nexus 10 (If the standard-kernel doesn't support cifs....).

I also found finally time to develop an GUI for oneclickmount (but it will not use the shell script...). It will have the following features:

Mount USB

Mount User-defined entries (ex.: cifs)

Mount with debuggerd (No need for the kernel-changes anymore)

Check with the filesystems in /proc/filesystems (for cifs, nfs...)

Mount User-defined entries after boot (Maybe with delay?)

The mounting/unmounting is done via touch on the entry.

The gui will look something like this (Screenshot from my phone):
[Nexus 7 Android Development] vorcers:
I just released v8 for Android 4.4 and everything seems to work.... :victory:

Download: http://www.mediafire.com/download/48xo4axdd2dpwnh/boot-grouper-vorcers-g4776c68-v8.zip

I tested cifs-mounting in /mounts/, OI Filemanager and mxplayer where able to access the files.... I did that with SuperSU 1.80.

I used with this kernel the newer kernel sources, https://android.googlesource.com/kernel/tegra/+/android-tegra3-grouper-3.1-kitkat-mr1

I think these are the sources for KRT16O / Android 4.4.1... but it also works with KRT16S.
[Nexus 7 Android Development] glimmling:
Thank you! Your app looks very promising.

Regarding cifs I can access my files too, but I still can't write on my shares with 4.4. Can you?

There's not much information to find about cifs with kitkat. I only found this changes with remounting:

http://xdaforums.com/showpost.php?p=47796543&postcount=5766

I don't know, if it could be related to my issues with the write permissions.

Gesendet von meinem Nexus 7 mit Tapatalk 4
[Nexus 7 Android Development] vorcers:
Thank you for your answer.

Cifs is at my system also read only... interesting is, that writing on my usb-pen-drive is working....

I need to investigate in this and answer here if I found an solution....
[Nexus 7 Android Development] vorcers:
It has something to do with selinux. They activated it completely in Android 4.4

If you want to check this, just look for lines which are similar to these in dmesg after you tried to create something.

type=1400 audit(1386503529.617:112): avc: denied { associate } for pid=1597 comm="mkdir" name="a" scontext=u:object_r:unlabeled:s0 tcontext=u:object_r:unlabeled:s0 tclass=filesystem

It says, that it denies the command "mkdir a". I tried to set the contexts.... only possible with not-mounted directories. If I try to add the context to the mount command, I can't even do the mount. Mounting nfs is also affected. You can't mount nfs. (You will get lines as above in dmesg)

Well, there is an solution, but this is dirty and maybe insecure.

The solution is, to change the selinux mode from "enforcing" to "permissive".

According to this, the permissive mode will do all selinux actions, but doesn't enforce it. You can still do your actions.

What you mustn't do, is deactivate SELinux completely. This can destroy your android if you reactivate SELinux.

But with the permissive mode, this shouldn't happen. But I am not sure.

If you do it, you are responsible for any damage.

(all commands as root)

You can enter the permissive mode with:

setenforce Permissive

Enter the default mode again with:

setenforce Enforcing

The status of selinux you can get with:

getenforce

After an reboot, the permissive mode is also gone.

Maybe we are able in the future to set the permissions and leave selinux in the enforcing mode, but I don't know how....
[Nexus 7 Android Development] glimmling:
Very good researched. Your finding did the trick.

I need the write access mostly for my Titanium Backup folder on my NAS. So I only have to change my mounting task to toggle the SELinux mode, when I use Titanium Backup.

Thanks!
[Nexus 7 Android Development] vorcers:
How much differ grouper and tilapia really?

A lot, I need to say.

I want to know this so I generated a diff of the boot, recovery and system files (the diff is in the attachments :cyclops:) . I recognized that grouper has a different ramdisk as tilapia....

Sorry guys, I made this mistake. I thought both ramdisks where the same. (I did a diff some time ago, I think?)

However, from now on I supply different files for tilapia and grouper...

At the grouper's: v8 uses the tilapia ramdisk :eek: Please flash v9.

The tilapia's: You can stay at v8 if you want...

Please look into the first post for the links.
[Nexus 7 Android Development] glimmling:
Updated to 4.2.2 yesterday and got the problem with the empty folders again. Tested with SuperSu 1.80. I will try Superuser in the next days.

Gesendet von meinem Nexus 7 mit Tapatalk 4
[Nexus 7 Android Development] vorcers:
I can't really confirm this:

Fact #1: It happens on Superuser and SuperSU

Fact #2: It has nothing to do with Android itself I think. Maybe they changed the standard-umask or the standard-mount permissions...

Fact #3: It is a permission-problem (you need to set yourself the unix-permissions ; no selinux thing ; dmesg and logcat say nothing after mount)

Advice:: Please try check the Permissions of the folder you mounted. (Or where you mounted) we need the "other" permissions (or you set the correct uid... )

Mounting of cifs worked for me - it had rwxr-xr-x. - So I could read at least. Mounting USB not: I had rwx------. So only root could read. I set in the mount-options "umask=000" ; with this, I get rwxrwxrwx, so it is working again.

Or you mount in /data/media/0 and use: uid=1023,gid=1023. But this are only works on ntfs and vfat and I think cifs (the same for umask=000 if you mount outside of /data/media/0). Ext2/3/4 and nfs has its own permissions and you maybe need to set the "other" rwx flag at these manual (via "busybox chmod o+rwx -R <dir>").

In the picture you see in the attachments I mounted my stick with "busybox mount /dev/block/sda1 /data/media/0/bbb -o uid=1023,gid=1023".

And if you are unsure if it worked (for example your filemanager shows nothing....) try to look as NON ROOT in the mount-folder with an terminal or adb and try to read.

Gahh... It is really time I finish the OneClickMount-App. :rolleyes: I can build in there some check if others can read...

I hope in cyanogenmod there aren't such problems...