Alien Pastures

My thoughts on Slackware, life and everything

Tag: android

Using your Slackware to control your Android

December 16, 2017 / / 9 Comments

Linux and Android

No worries, even though this article is a side-step into the Android ecosystem, it is still on-topic for Slackware users.
I recently bought a Huawei Watch 2, when it was in a sale on Amazon. It’s the 4G version and long ago I had made a deal with myself that if a smartwatch with GPS and room for a SIM card would go below 300 euros, I was going to buy it. And so it happened, and the watch is a lot of fun. It’s incredibly light-weight and fits comfortably. Despite grumpy reviews it is a solid design and does not feel like cheap junk at all. I still need to find a provider who will allow me to use a second SIM card for my mobile subscription, so for the moment this watch is SIM-less. It talks to my phone over Wi-Fi and Bluetooth so nothing’s lost and I have full connectivity on the watch. The idea is to have a SIM in the watch so I can go outdoors for a long run without having to take my phone with me.

An Android Wear watch will pair with only one single phone. It’s quite picky about its friends. Therefore, if you switch phones and want to pair the watch to your new phone, it will wipe and reset itself to factory defaults. That was not what I wanted when I traded my four years old HTC One M8 for a HTC 10 phone. Yes, that too was a bargain sale – I got it for 272 euros which is roughly 65% of the regular price around here.

So I went searching for ways around my dilemma, and as it turns out: it is quite easy to de-couple an Android watch from its pal the phone, and let it pair with a new phone, while keeping its current settings and content. I am going to document that process here, because much of it is generic enough that you can use it to manage the internals of any Android device, like your phone.

The singularly important tool for interacting with Android devices is the Android Debug Bridge, or “adb” for short. It’s a program or rather a suite of tools that run on Linux, Windows and OS/X and allow you to execute commands remotely on the Android device. Commonly the bridge is used over a USB connection between Computer and Android device, but in this article I will show you that you can just as easily use a Wireless connection.

Installing Android Debug Bridge

First, let’s setup the Linux computer. In our case, that will of course be a Slackware computer, right? 🙂

ADB is a small part of the “Android SDK Platform-Tools” and in the past, this meant you had to install the complete SDK in order to gain access to adb and fastboot. Recently, Google has started making adb and friends available as a separate, much smaller (around 5 MB) ZIP download. The URL is static but the content will be refreshed from time to time.

  • Download the ZIP containing the platform-tools for Linux:
    wget https://dl.google.com/android/repository/platform-tools-latest-linux.zip
  • Extract the ZIP file to /usr/local (you need to be root):
    unzip -d /usr/local platform-tools-latest-linux.zip
    That leads to a directory /usr/local/platform-tools/ with a lot of stuff in it.
  • Create two wrapper scripts for the ‘adb’ and ‘fastboot’ binaries inside the extracted directory. This way, typing “adb” or “fastboot” will work in any directory:
    cat << EOT > /usr/local/bin/adb
    #!/bin/bash
    /usr/local/platform-tools/adb “$@”
    EOT
    chmod 755 /usr/local/bin/adbcat << EOT > /usr/local/bin/fastboot
    #!/bin/bash
    /usr/local/platform-tools/fastboot “$@”
    EOT
    chmod 755 /usr/local/bin/fastboot
  • Download and install a UDEV rules file which identifies most if not all known Android devices and makes udev create device-files for them when the Android connects (strictly speaking, his is only relevant for remote debugging over USB… if you connect over wireless then device-files are not used). The file is community-maintained and part of a git repository for Ubuntu. After installing the UDEV rules, you need to reload udevd’s cached rules:
    wget -O /etc/udev/rules.d/51-android.rules https://raw.githubusercontent.com/NicolasBernaerts/ubuntu-scripts/master/android/51-android.rules
    chmod 644 /etc/udev/rules.d/51-android.rules
    /etc/rc.d/rc.udev reload

You’re all set now to connect to your Android device and interact with it. Thanks to the UDEV rules you’ve installed, you won’t have to be root to use ‘adb‘ and ‘fastboot‘ as long as your user account is a member of the “plugdev” group.

Tip: if you have a USB stick with the Slackware Live Edition, you can repeat the above with one change: instead of installing the debugger tools to /usr/local , the wrapper scripts to /usr/local/bin and the UDEV rules to /etc/udev/rules.d/ you (i.e. with “/” as the root) you install the lot to the /rootcopy/ directory of the USB stick, keeping the same directory structure and thus ending with /rootcopy/usr/local/bin/ and /rootcopy/etc/udev/rules.d/ . That will make your Slackware Live a powerful tool to manage Android devices.

Enable remote adb debugging

Android devices do not allow remote debugging by default and it is not immediately visible how to enable this capability. You will have to enable developer options on your Android. This takes the form of a secret ritual… and enables several new menus and options in your Settings.
First, generic Android instructions:

  • Open the “Settings” on your Android.
  • Scroll down to “About phone” (or “About Tablet”)
  • Find the entry which shows the “Build number”.
  • Repeatedly, tap the “Build number” line. After a couple of taps, a popup message tells you that you are an “X amount” of clicks away from becoming a Developer. As you keep tapping the number “X” will decrease to zero which completes the process.

Android Wear instructions:

  • Swipe down from the top of the screen.
  • Tap the “Settings” icon (gear icon).
  • Scroll down and tap “System”.
  • Scroll down and tap “About”.
  • Then scroll down and tap “Build Number” repeatedly.
  • Keep tapping until you get the message “You’re now a developer”.
  • Swipe to the right twice.
  • Scroll down and you’ll see new “Developer Options”.

In the new Developer Options menu you will find “ADB debugging” which you have to enable. For the Android Wear device, it makes sense to also enable “Debug over Wi-Fi” since at least my watch does not have a micro-USB connector.

If you look at the screenshot you’ll notice that the watch’s IP address is shown in the “Debug over Wi-Fi” section. We will need that IP address soon.

Connect to Android using adb

Connecting to a device which is connected through USB is simple. You request an overview of detected devices and if your device (phone or tablet) is detected, it will be listed and you can control it remotely:

adb devices

With a smartwatch, you first need to connect to its IP addres over the port number shown in the screenshot above:

adb connect 192.168.1.100:5555

You do not need to be root to do this.
Any of the above two commands will start the adb daemon if it is not yet running. In case of connecting to a smartwatch, you will have to accept the incoming connection on the watch-side.

You can now start sending commands to be executed on the Android device. For phones, this is usually part of the rooting process followed by installing a custom ROM. That is beyond the scope of this article.

Pair your watch with a new phone

Now that the pre-requisites have been taken care of, let’s go through the steps to pair the Android Wear watch with a new phone. You do not need to be root to do this.

  • Disable Bluetooth on your old (if you have it still) and new phone.
  • Open an adb shell – basically a remote shell on the watch. You’ll notice the prompt (sawshark:/ $), sawshark is the Android codename for my Huawei Watch 2 Sport: 
    adb shell
sawshark:/ $
  • Execute the command that instructs Package Manager to clear stored data & cache (“pm clear”) of the Google Play Services (“com.google.android.gms”) and reboot the watch: 
    pm clear com.google.android.gms && reboot

    This clears the pairing information including the keys to communicate securely with the paired phone, but does not trigger a factory reset which happens if you un-pair the phone via the watch settings menu.

  • Make sure you have installed the Android Wear app on your new phone but do not enable Bluetooth on the phone yet.
  • From the computer, connect to your watch again over Wi-Fi (accept the incoming connection request on your watch) using the “adb connect” command shown earlier. Start a new “adb shell”.
  • At the remote prompt enter the command to make the watch visible for Bluetooth discovery by telling Activity Manager to start an Activity specified by the intent “android.bluetooth.adapter.action.REQUEST_DISCOVERABLE” (and make sure you accept the ‘OK’ prompt on your watch): 
    am start -a android.bluetooth.adapter.action.REQUEST_DISCOVERABLE
  • Now is the time to start Android Wear on your new phone, allow the app to turn on Bluetooth and start scanning for a Android Wear watch to pair with. When the phone finds your watch, an accept request will show on both. Once you have accepted both prompts, new pairing keys will be generated and stored in the watch’s Google Play Services app. You can synchronize the watch data to your phone and manage it from there.

Good luck! Eric

KDE SC 4.12.4 for Slackware 14.1 and -current

April 2, 2014 / / 23 Comments

Yesterday, I uploaded the packages for the new KDE Software Compilation 4.12.4 which brings us updates to the Applications and Development Platform. The Plasma Workspaces are following a separate version numbering scheme – the new workspaces package version is 4.11.8.

The Slackware-current tree has not seen exciting updates other than security fixes and because of that, again I have built my packages for KDE  4.12.4, on Slackware 14.1 for maximum compatibility.

The packages work fine on slackware-current too – of course. When that changes, I will stop using Slackware 14.1 as the build platform.

What’s new in my KDE 4.12.4 packages?

One of the packages has been renamed. The old “kdnssd” package is now called “zeroconf-ioslave”. The README which accompanies my packages has been updated with a “removepkg kdnssd” command.

The kmahjongg package now has the main program script included and you’ll find it in the KDE menu. Kmahjongg will not work out of the box, but you only have to add the “python-twisted” and “zope.interface” packages from my regular repository to make it work. I do not include these add-ons in the ‘ktown’ repository because I do not want to force Patrick’s hand if he does not want them to be part of Slackware in future.

I also updated the kdeconnect-kde package with a git development snapshot. In my previous blog article I wrote how this interesting little program interacts with the kdeconnect-android app. Don’t forget to add the new “KDE Connect” widget to your system tray if you want to try it out.

kdeconnect-applet

How to upgrade to KDE 4.12.4 ?

You will find all the installation/upgrade instructions that you need in the accompanying README file. That README also contains basic information for KDE recompilation using the provided SlackBuild script.

You are strongly encouraged to read and follow these installation/upgrade instructions!

Where to find packages for KDE 4.12.4 ?

Download locations are listed below (you will find the sources in ./source/4.12.4/ and packages in /current/4.12.4/ subdirectories). Using a mirror is preferred because you get more bandwidth from a mirror and it’s friendlier to the owners of the master server!

Have fun! Eric

KDE 4.12.3 for Slackware-current (and 14.1) plus some goodies

March 4, 2014 / / 67 Comments

Sticking nicely to the well-known KDE Release Schedule, here are packages for the latest and greatest KDE Software Compilation.

The new release 4.12.3 is a further step towards stabilizing the 4.12 platform and comes with updates to Plasma Workspaces, which brings that to version 4.11.7. Incidentally I also updated the Plasma Workspaces (aka kde-workplace)  in the KDE package set which I maintain for Slackware 14.1 (the KDE SC 4.11.5 release will keep getting long-term updates to kde-workspace until this summer)

Principally, I am targeting Slackware-current with my bleeding-edge packages for KDE. However – as was the case with the previous KDE release, there is not all that much divergence between the stable release (Slackware 14.1) and the development tree (Slackware-current). That is why I built my packages for KDE  4.12.3, on Slackware 14.1 for maximum compatibility. They work fine on both platforms.

What’s new in my KDE 4.12.3 packages?

Apart from all-new versions for the core applications, I also updated the oxygen-gtk2 and plasma-nm (and libnm-qt, libmm-qt) packages. I was unable to compile the latest oxygen-gtk3 release because Slackware’s GTK+-3 package is too old.

There is one interesting addition! There is a new package called kdeconnect-kde. Together with the kdeconnect-android app for your smartphone or tablet (no iPhone, surely you don’t own one??) it “fuses” your KDE desktop with your mobile device.

kdeconnect-settings

Prominent features of KDE Connect are: battery status display, clipboard share, notifications sync, multimedia remote control, and all of that over secured network connections. Don’t forget to add the new “KDE Connect” widget to your system tray.

kdeconnect-applet

How to upgrade to KDE 4.12.3 ?

You will find all the installation/upgrade instructions that you need in the accompanying README file. That README also contains basic information for KDE recompilation using the provided SlackBuild script.

You are strongly advised to read and follow these installation/upgrade instructions!

Where to find packages for KDE 4.12.3 ?

Download locations are listed below (you will find the sources in ./source/4.12.3/ and packages in /current/4.12.3/ subdirectories). Using a mirror is preferred because you get more bandwidth from a mirror and it’s friendlier to the owners of the master server!

Have fun! Eric

Re-encoding video for Android

June 4, 2010 / / 10 Comments

So I bought myself a nice Android phone in april. It’s a HTC Desire, a real “tweakers’ phone”. It runs Android 2.1 – and before the end of the year, HTC should have an update to Android 2.2 available.

It is an impressive piece of work, and when I compare it to the iPhone or Windows Mobile based phones some of my friends/collegues carry with them, it clearly gives me a lot of freedom – I do not have any desire to “root” or “jailbreak” my phone in order to make it do what I want. I dream of putting Slackware on it, sometimes, but then I usually wake up fast… It’s a real Linux phone (with a SSH and a VNC client installed from the Android Market!), and the HTC Sense interface makes it just perfect and enjoyable as it is.

It goes without saying that I took a flat-fee Internet subscription; this kind of phone is not fully functional unless it is always online. I have been running a bandwidth metering app which told me that I transfered 440 MB in my first month. That would result in a pretty heavy bill if I did not have unlimited traffic.

I may write some more about my experiences with the Desire in future posts (so may exciting things to tell!), but for this one I want to talk about video playback on Android. Android has decent multimedia support out of the box, and audio as well as video players can make use of the standard codec libraries that the Android platform offers.

The “native format” I think you may call it that, for the Android seems to be H.264 video and AAC audio in a MP4 container. There are some limitations however, as people found out when trying unsuccessfully to play MP4  video files on their Android device that would not have had playback issues on a normal PC or mediabox.

Android only supports the H.264 baseline profile, meaning that some of the fancy encoding tricks that give you great video quality at lower bitrates (but require more processing power on playback) can not be used for videos you want to play on your Android device.

And rest assured, you do want to watch videos on the 800 x 480 pixel WVGA screen of the Desire! The AMOLED display has fantastic vibrant colours.

So, in order to create a video file that fits the display dimensions perfectly (without the scaling/resizing which would result in an ugly picture) and contains fully compatible MP4 video, I once again turned to my faithful companion… ffmpeg.

Here is a ffmpeg command line for you. This will take a video file (any supported format will work as input) and produce an Android-compliant MP4 file with WVGA dimensions (800 by 480 pixels). The input file will be transcoded in a two-pass process in order to achieve the best possible results. The transcoding will take a long time, so find something else to do in the meantime.

$ ffmpeg -i [inputfile] -threads 0 -vcodec libx264 \
    -vpre slow_firstpass -vpre baseline -b 480k -r 13 \
    -acodec aac -ab 128k -sameq \
    -pass 1 -f rawvideo -an -y /dev/null && \
    ffmpeg -i [inputfile] -threads 0 -vcodec libx264 \
    -vpre slow -vpre baseline -b 480k -r 13 \
    -acodec aac -ab 128k -ac 2 -sameq -pass 2 [outputfile].mp4

If you are on Slackware, then you get lucky. My ffmpeg packages (the variant that supports AAC audio encoding) are right here: http://slackware.org.uk/people/alien/restricted_slackbuilds/ffmpeg/

Have fun experimenting!

Eric

© 2024 Alien Pastures

Theme by Anders Noren — Up ↑