Network file system android

Просмотр видео на Android по сети напрямую из папки Windows через NFS

Есть Android и куча видео в папке на компьютере с Windows. Как смотреть видео не перекачивая фильмы на SD-карту? Можно подключить папку напрямую. Но в ядре нет поддержки smbfs/cifs, зато есть поддержка nfs. Установим на Windows nfs сервер и подключим в Android папку с фильмами.

Для работы нам понадобится доступ к устройству через терминал. Можно поставить терминальную программку на Android, но отсутствие физической клавиатуры портит всё удовольствие. Поэтому воспользуемся утилитой adb из комплекта Android SDK.
Я не люблю подключать устройство через USB порт если есть WiFi. Но для работы adb по WiFi нужна утилита ADB over WiFi Widget (или adbWireless). Поставьте ее из маркета.
Добавьте виджет ADB over WiFi на домашний экран, ткните его. После некоторых раздумий виджет показывает нам куда нужно подключаться. В моем случае это: 192.168.0.35:8000. Подключаемся из Windows консоли и открываем консоль андроида:

Чтобы узнать какие файловые системы поддерживает ваше ядро выполним команду:

Как видим поддержка nfs присутствует.
Теперь установим nfs сервер. Для Windows существует несколько серверов как платных, так и бесплатных. Мы будем ставить сервер Cygwin.

Установка Cygwin nfs сервера

Скачиваем программу установки. Выбираем следующие пакеты: nfs-server, sunrpc, cygrunsrv. Еще желательно поставить редактор для правки файлов из консоли, например nano.
Открываем Cygwin Bash Shell, ссылка на него есть в главном меню Windows.
Добавляем в /etc/exports строку:

Теперь можно подключаться к любой папке на диске c:.

Отключаем наследование прав доступа NT. Для этого раскомментируем строку в /etc/fstab и добавим в опции noacl:

Для вступления настроек в силу загрываем консоль Cygwin и открываем её снова. Проверяем:

Опция noacl есть — порядок.

Запускаем установку сервисов.

Скрипт будет задавать много вопросов. На все отвчаем да, кроме одного:

Можно установить сервис и под административным аккаунтом, но у меня работает и под системным.
Скрипт установил три Windows-сервиса: portmap, nfsd, mountd. Запускаем их:

Теперь на Windows работает nfs сервер.

Монтирование папок в Android

Ставим из маркета программку GScript Lite. Она умеет запускать скрипты и, к тому же, бесплатна.
Добавляем в программу два скрипта.

mount_video.sh — для подключения папки:

В моем случае ip-адрес компа 192.168.0.2, видео папка расположена в c:\downloads\video, поменяйте скрипт в соответствии с вашими настройками.

umount_video.sh — для отключения:

Можно вбить текст вручную в GScript, либо создать скрипты на компе и перенести с помощью adb.
Расскажу про второй способ. Допустим вы сохранили скрипты в папке C:\android-sdk-windows\tools, выполняем:

Источник

Android 6 Marshmallow over Network File System (NFS) on the Wandboard

This tutorial assumes you have already built and deployed Android 6.0.1 for the Wandboard on an SD-card, according to our preceeding blog post in this series. For quick reference, we are using the Android source 6.0.1 for the Wandboard from the official website. The source code is assumed to be extracted to , and our host system is Ubuntu 16.04.

Android system development on an SD-card can be quite cumbersome. Even though there is the possibility of pushing and pulling files via Android Debug Bridge (ADB) between the target device and the host computer, more often than not, you still need to replace the contents of the SD-card manually. In the following, we will show you how you can boot the Linux kernel via TFTP and the Android operating system over NFS.

Step 1: Setup tftp-server on the host

The TFTP server will supply the Linux kernel and the device tree files.

In our example, we are setting the tftp root directoy to “/srv/tftpboot”, and leave the default user as “tftp”. For reference, our configuration file looks like this:

Create the tftp root directory and start the server:

In the same manner, you can also stop and restart the tftp server. Now copy the kernel and the device tree files to the tftp root directory

Step 2: Setup nfs share on the host

We will use as the root directory for our Android share. Our configuration file looks like this:

Now create the nfs share directory, export the NFS table, and start the server:

We need to populate our nfs share with the Android operating system. There are multiple ways to achieve this. The approach chosen here is to extract the ramdisk (containing the root file system) to the nfs share, and then mount the Android system image inside of it. By the way, if you were to merely copy the contents of the root directory from the out directory, the system will not boot beyond init, because the permissions of the *.rc files are not correct yet.

If you want to unmount system_raw.img again and get a “device is busy” error, you need to stop the NFS server beforehand with:

After setting up the bootloader environment in the next step, this should already result in a semi-successful boot. Further changes needed are detailed in Step 4.

Step 3: Configure u-boot bootloader arguments to boot from tftp/nfs server

On the Wandboard, we need an SD card with a u-boot bootloader. Remember, the SPL must to be copied at 1k offset into the SD card, and the u-boot.img placed onto the first FAT32 partition.

Also copy the u-boot.img file to the first FAT32 partition (named BOOT in our example)

Startup the Wandboard with the SD-card, and in a serial console, hit enter to stop u-boot from auto-booting.

We now need to change a few u-boot environment variables. You can inspect the current variables with the “printenv” command. Note that there is already an environment variable “netboot”, along with “netargs” with the following contents:

If we run the “netboot” command, it will first set the boot arguments by running netargs. Depending on the variable “ip_dyn”, the get command for the kernel image is either set to “dhcp” or “tftp”, after which the kernel image is pulled, along with the device tree file. Finally, the zImage is booted with the bootz command. Easy, right? 🙂

As mentioned, we need to set a few environment variables to boot from our nfs server. I’ll show all the needed commands, and explain them later on:

The variable “ipaddr” sets the IP address of the target, and must be set to an IP address for the tftp command. If you don’t know which IP address to use, find out with the dhcp command:

Here, the variable “autoload” is temporarily set to no, so that dhcp does not automatically try to load a kernel image when it is called. You may wonder why even use tftp instead of the dhcp command for downloading our kernel image? The reason for this is that – at least for me – every time the dhcp command is used, the serverip variable is reset to 192.168.1.1. So by setting “ip_dyn” to to “no”, we choose the tftp command for downloading the kernel and device tree files, which seems to work better here. (It’s very well possible that dhcp would work somehow too. In either case, tftp is fine for now)

The variable “serverip” is set to our host’s IP address. It is also read by tftp, see the official U-Boot wiki section on U-Boot Environment Variables. As mentioned, “ip_dyn” is set to “no” so that tftp instead of dhcp is used. “bootfile” is the default image to load for tftp (again, check the wiki section for more information). “fdtfile” is the name of our device tree binary on the tftp server.

We are also slightly altering “netargs” to mount the root directory as read-write (rw) and by adding $ , which contains the init location, along with video arguments, etc. (This was probably just forgotten in the default settings).

Needless to say, adapt “ipaddr” and “serverip” accordingly, then save the environment.

If something went wrong, you may reset to the default values with “env default -a”. Otherwise, you can now manually boot via network by running netboot:

Furthermore, if you inspect the “bootcmd” variable – which is run by default when the device boots up – you’ll notice that among other things it will try to find and load a ramdisk and kernel image from the the first FAT partition. However, if this fails, it will resort to “run netboot” in the end. So in case you still have a zImage and uramdisk.img on the SD card, you can simply delete or rename those files, after which it will always boot from TFTP/NFS upon rebooting.

Step 4: Changes to Android to fix NFS booting

As mentioned, we should already have a somewhat successful boot. At least, we need to adapt the fstab.freescale file. When booting from SD-card, the system folder is mounted from a separate partition. However, when booting via NFS with the above setup, we already have the system folder inside our NFS root directory. So delete or comment out the line for mounting the system

Of course, this also means that we should have an SD-card with data and cache partition inserted. You may need to change the partition numbers p4 and p3 for your purpose. The above fstab file should be OK if you have set up your SD card as described in this previous post. For completeness’ sake, here is what is assumed to be on your SD card:

• 1MB offset or more before first partition.
  The u-boot SPL is placed here at an offset of 1024 bytes.
• Partition 1: BOOT, VFAT,

32MB
u-boot.img should be copied here, and will be loaded by SPL.
Partition 2: SYSTEM, EXT4,

1024MB
This holds the system partition, and is not loaded with the above fstab file.
Partition 3: CACHE, EXT4,

1024MB
Cache partition

Partition 4: DATA, EXT4, remaining size
Data partition

Now we can try to boot again. You should see a fair amount of log output, but after a short time, the system will hang with the error message

Finding out what exactly goes wrong here is kind of hard, and is a great chicken-and-egg problem if I have ever seen one. Obviously, there is something wrong with the network. However, as soon as we see the error message, it’s already too late for debugging since our system with all debugging tools is only available via network. As it turns out in the end, the error stems from the “netd” service. The corresponding source code is found inside the Android source under and .

When inspecting CommandListener.cpp, you can already see that something was patched here to read a system property “ro.nfs.mode”. This actually comes from a Freescale Android KK443 (KitKat) patch release. Setting this property does not fix our issue just yet, but certainly points us in the right direction. After a lot of trial & error, it turns out the problem lies within RouteController::Init function, specifically by calling flushRules() which will clear any present routing rules and in turn break our ethernet connection to the NFS server. We could simply modify the flushRules() function inside RouteController.cpp, but then we would need two different versions of netd – one for normal and one for NFS booting. Therefore, let us also use the “ro.nfs.mode” property to determine whether we should call flushRules(). A possible fix for RouteController.cpp could look like this (note that you also need to include cutils/properties.h)

Re-compile netd and copy the new binary to the NFS directory:

When booting via NFS we also need to add the mentioned system property in init.freescale.rc’s on boot section.

That should do it, reboot und gut 😀

(There are also some more patches in the Freescale KitKat release. This one disables clearing of the interface addresses from within framework when in NFS mode. In Android 6, you would need to add those changes to EthernetNetworkFactory.java inside frameworks/opt/net/ethernet, however it does not seem this patch is needed here. Another patch is for installd, but again, everything seems to work fine here without)

Bonus: Where does u-boot save environment variables on the SD card?

If you remember, we saved our u-boot environment variables to the SD card. But where exactly are those variables stored now? Have a look at the Wandboard config file to find out:

Search for “CONFIG_ENV” and you will find the following section:

So the environment is 8*1024 bytes = 8 KB in size. It resides in the MMC (or SD card), at an offset of 6*64*1024 bytes = 384 KB. You can double check that by saving your own variables, and then dumping the environment from the SD card with the following command:

Источник

Network file system android

ИНСТРУКЦИЯ ПО СБОРКЕ МОДУЛЕЙ NFS

Инструкция написана для ОС Ubuntu

1. Устанавливаем компилятор и необходимые библиотеки
sudo apt-get install make gcc libncurses-dev

2. Создаем папку, в которой будем работать
mkdir /home/user/build

3. Скачиваем кросс-компилятор от сюда http://dl.google.com/android/ndk/android-n. nux-x86.tar.bz2 и разархивируем в папку build

4. Смотрим, какое у нас ядро на телефоне (в настройках или командой uname -a в терминале на телефоне) и скачиваем его исходники, к примеру, от сюда ftp://ftp.kernel.org/pub/linux/kernel/

5. Разархивируем исходники в папку build и переименуем получившуюся папку в kernel для удобства

6. Копируем с телефона файл с настройками ядра /proc/config.gz на компьютер, разархивируем и копируем в

/build/kernel. Далее его необходимо переименовать в .config

7. Переходим в каталог kernel
cd /home/user/build/kernel

8. Запускаем Linux Kernel Configuration (параметр -jN задает количество N используемых ядер процессора при компиляции)
make -j2 ARCH=arm CROSS_COMPILE=/home/user/build/android-ndk-r8b/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi- menuconfig
Заходим в File systems -> Network File Systems и отмечаем NFS client support пробелом . Внутри NFS client support отмечаем все пункты кроме NFSv4.1
Далее выходим в главное меню и сохраняем настройки, выбрав Save an alternate configuration file. Выходим из конфигуратора

9.Компилируем модули
make modules -j2 ARCH=arm CROSS_COMPILE=/home/user/build/android-ndk-r8b/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-

Источник

Читайте также:  Android cube power m3