Kirsle.net logo Kirsle.net

Tagged as: Android

Progress Report: Degoogling
January 16, 2020 (updated January 16, 2020) by Noah

A couple of years ago I started the progress of slowly de-googling my life: lessening my reliance on Google services, moving my data to my own servers and limiting what data Google can collect about me going forward as well as deleting the data they already have.

In this blog post I'll talk about the Google services I used to use and the solutions I found for replacing them. The full list of Google services I used to use and have found alternatives for include:

  • Gmail: hosting my @kirsle.net email addresses elsewhere.
  • Contacts & Calendar: Nextcloud provides my cross-device sync for these.
  • Drive: Nextcloud holds my files in the "cloud" (my home PC available on the go).
  • Photos: I moved all mine to my Nextcloud.
  • Search: DuckDuckGo.

Also check out some of my personal notes I've been taking as I went:

Read more...

Tags: 2 comments | Permalink
Android 6.0 "Battery Optimization"
January 13, 2016 by Noah

PSA: The "battery optimization" feature in Android 6.0 Marshmallow may be causing your Gmail to not notify you of e-mails until it's way too late and other apps to not notify you about anything ever.

I first caught on to this when I stumbled upon a Reddit thread on /r/Android. Essentially, Android 6.0 added a feature called Doze which puts apps to sleep while the phone is locked/not in use, giving them only brief windows of opportunity to check for any new notifications before being put back to sleep. The frequency between these wake opportunities depends on how long the phone has been locked. It sounds like a good idea in theory, but the execution was done very poorly.

That thread was specifically about apps like Gmail and Inbox. Users were seeing issues where Gmail wouldn't notify them about new e-mails until several hours after the e-mails came in. This is because the Gmail app was getting "dozed" and was unable to check for any new messages (or receive push notifications, or whatever it does). The work-around is to disable the "battery optimization" for the Gmail app.

To do so:

  1. Go to your Settings and then Battery
  2. In the menu on the right, go to Battery Optimization
  3. It lists the non-optimized apps and those that can't be optimized. In the drop-down at the top, pick All Apps
  4. Pick Gmail and any other app you care about and pick "Don't optimize"

Doze makes it sound like not optimizing apps will hurt your battery life. This may be true for poorly written apps, but it's pretty safe to allow Gmail to not be put to sleep. Before Android 6.0, Doze wasn't even a feature anyway and there weren't a lot of complaints about battery life. Personally, I just disabled battery optimization for a small handful of apps that I care more about, including Gmail and Hangouts.

In addition to Gmail, a few other apps I found to be completely broken when they're being "optimized":

  1. Google Opinion Rewards: Get Google Play credit for answering surveys. I noticed I wasn't getting any surveys offered for several weeks, and figured the Doze feature was to blame. I disabled it on the Google Opinion Rewards last night, and got a survey this morning.

    My theory is that this app only receives surveys if there is one available at the time the app asks for it. Since the app was checking very infrequently, it was missing all the surveys.

  2. Tasker: I have a Tasker task set up to automatically connect to my VPN when my phone joins certain WiFi networks. I was noticing that it was failing to do this the majority of the time. I'd have to open Tasker and manually play the Connect VPN task and then it would sorta work, but sometimes it would fail to run the Disconnect VPN task when I left the WiFi network.

    Disabling battery optimization for Tasker fixed this problem.

  3. Tumblr: I was getting no notifications at all from this app, ever. Disabling battery optimization fixed this problem.

  4. Reddit Sync Pro: I was getting no notifications of new messages on this app until I manually opened it. Again, disabling the optimization helped.

So if you have any apps that have been oddly quiet for the past several weeks or months and you're running Android 6.0, check if the "battery optimization" feature is to blame.

Tags: 2 comments | Permalink
Google knows when you wake up?
September 26, 2015 by Noah

Something pretty odd that's happened to me on more than a couple of occasions:

I'll wake up in the morning, and then a couple minutes later people start sending me messages on Google Hangouts, so my phone's making a bunch of noise. If it's early enough in the morning, some of those messages will even say things like, "you're up early."

The thing is though, I didn't even touch my phone yet. I didn't even look at my phone.

Messages like this don't tend to wake me up, but instead I don't start getting messages until just after I'm awake.

Read more...

Tags: 6 comments | Permalink
Android can apparently delete your Camera folder without warning
August 11, 2014 by Noah

So I took a few pics with my Nexus 5 this morning, and when viewing them in the Gallery app they appeared to have not saved correctly (there was a solid dark grey placeholder image for each one I took). If I opened the Camera app and swiped over to see them, there they were. But the Camera app also popped up a toast saying "Insert an SD card to save photos."

The Nexus 5 has no SD card.

And then I probably shouldn't have rebooted my phone (the Camera was being an idiot, so I thought rebooting would fix it), cuz when the phone came back up, the Camera folder was entirely deleted. Like, it didn't show up in the Gallery, and swiping in the Camera app did nothing. /mnt/sdcard/DCIM/Camera didn't exist anymore. Take a new picture, and the Camera folder was remade but only had the one new picture in it.

So, Life Pro Tip: Android can do this sometimes. If you get those kind of symptoms, hopefully try making a backup of the Camera folder (using like Astro or Root Browser), before rebooting the phone. You'll probably still lose the newly taken/corrupted pictures but at least Android shouldn't delete all your other camera pictures.

I think the Camera app was still able to see the pictures even though they weren't saved because they were kept in some sort of temporary in-memory cache of the Camera app. Probably the best way to save them would've been to take screenshots of them from within the Camera app.

All the other folders that had pictures in them were left alone, i.e. pictures saved through Snapchat and other photo albums.

Update:

I used a recovery program to restore all the deleted photos/videos on my phone. Site I used. Some of the pictures were corrupted but I was able to get all the ones I cared about back. :) Most of the deleted files were Snapchats that I already had non-deleted copies of.

Also, the selfies that I took this morning that "caused" this whole entire mess were recovered as well, so that's double-good-news. :P One of the pics that literally broke my camera:

Pic that literally broke my camera

Tags: 0 comments | Permalink
Exploring Grindr's Photo Cache
April 4, 2014 (updated June 13, 2022) by Noah
UPDATE (June 12 2022): I wrote this blog post originally in 2014 and it's highly likely that Grindr's data folder on Android doesn't look anything like this anymore. I haven't rooted my Android phones in a long time and haven't run Grindr in several years either. I sometimes get emails from people asking for help getting into their Grindr cache -- I can't help you, and don't ask me about this. This blog post is very outdated, Grindr has gone thru several complete re-designs in the last 8 years and they've probably changed everything about their data folder layout.

What you can do if you want to look into this yourself is: root your Android phone, look in your /data/data folder for Grindr's app data, copy it out to your PC and go thru it yourself. The file command on a macOS or Linux terminal can tell what type of file something is regardless of its extension (in this post, many JPEG photos were named with ".1" file extensions instead of .jpeg and Linux easily ferreted this out).

Also note that rooting your Android phone may require a factory reset of the phone, so if it's your existing Grindr cache you want to get into, you may be out of luck. Google Pixel phones for example officially support unlocking the bootloader (necessary for flashing custom ROMs and root), but this action forces a factory reset for privacy (e.g. a thief stole your phone and wants to root it, which would let them bypass your lock screen, Google wants the phone to mandatorily reset to factory defaults before it can be rooted). Some phones with shadier root exploits may not need the factory reset. You're on your own either way. Don't ask me for support in rooting your phone or helping you hack Grindr.

A long time ago, the Grindr for Android app used to store its photo cache on your SD card, but lately they hid them away in the app's private space to make them slightly more difficult to get to. I decided to go exploring using Root Browser and see what I could find out.

When I say "photo cache" I mean the place where Grindr downloads pictures locally so that it doesn't need to keep redownloading everyone's pictures all the time and consuming a lot of unnecessary bandwidth. Grindr caches both profile pictures and pictures received over chat messages. They both go into the same place. So if you have access to that place, you can get high resolution copies of all pictures received over chat and have them on your PC. :)

First of all, you'll need a rooted Android device for this, because the Android OS normally doesn't allow apps to get into each other's private data folders. The Root Browser app is a file browser that's root-aware (so it will prompt for root permission when you attempt to open a folder that ordinarily you can't open without root).

So, without further ado, Grindr's photo cache is located at /data/data/com.grindrapp.android/cache/picasso-cache/. This folder may contain a lot of files, mine had 3,458 and so Root Browser took a while to load that folder. You can copy it somewhere under /mnt/sdcard and then get to your files from a PC that way. Make sure the files are no longer owned by "root" when put in the SD card part, or you may run into issues when accessing them from your PC.

Most of the files in this folder have hexadecimal names that appear to be hashes of some sort, and the names usually come in pairs, one with a ".0" file extension and the other with a ".1", for example one I found on my phone was 4e21d675447678d0493bc8cb41a56e8d.0.

The ".0" file is a plain text file, and most of the ".1" files are the JPEG images. I use Linux, and my file browser automatically identified the types of all the files and showed thumbnail images for all the ".1" files. So, most of the time if you rename one of the ".1" files to have a ".jpg" extension you can see the images under Windows.

Some of the .1 files aren't images though. Some are more text files, and I peeked inside one to see what it was:

$ cat c1749deee81d4fece16d836e177c5852.1
[{"messageId":16970,"title":"Calling All DJs & Bartenders","body":"Are you one of the sexiest DJs or bartenders and able to work a paid event on the afternoon of April 27th in Palm Springs? If so, send us your information and a link to your website to palmsprings@grindr.com or simply tap 'More' to email us directly. ","actionTitle":"More", "dismissTitle":null, "expirationDate":1396853940000, "url":"mailto:palmsprings@grindr.com"}]

These appear to be the broadcasted pop-up messages shown in the app sometimes.

Now, the other interesting files are the ones with the ".0" extensions. These appear to be debug information, and they're basically the full HTTP request dump used to download the ".1" file. Here's what the one looked like for my profile picture (in case the Grindr CDN link stops working and you're curious, it's this picture):

$ cat 4e21d675447678d0493bc8cb41a56e8d.0
http://cdns.grindr.com:80/images/profile/1024x1024/d8dfd4eb2abd9c4d29653587cc87912b393bac97
GET
0
HTTP/1.1 200 OK
14
Accept-Ranges: bytes
Content-Length: 72057
Content-Type: image/jpg
Date: Fri, 04 Apr 2014 20:09:05 GMT
Etag: "98af07f8697f854734874296a90c640f"
Last-Modified: Sat, 01 Mar 2014 22:05:22 GMT
Server: ECS (lax/2851)
x-amz-id-2: [REDACTED]
x-amz-request-id: [REDACTED]
X-Android-Received-Millis: 1396642144430
X-Android-Response-Source: CONDITIONAL_CACHE 200
X-Android-Selected-Transport: http/1.1
X-Android-Sent-Millis: 1396642144347
X-Cache: HIT
I edited-out the "x-amz" headers because I'm not sure how secret those are supposed to be.

When browsing through my cache folder I also saw some pictures that weren't profile pics, but were sent over chat messages. These always seem to be the full resolution of the original pic sent, i.e. not thumbnails or anything. The ".0" file looks the same as for a profile picture, except the URL downloaded begins with "http://cdns.grindr.com:80/grindr/chat/" and the server headers respond with a "Content-Type: binary/octet-stream" (which causes a web browser to download the picture to disk instead of displaying it in the browser).

Some of the ".1" files are actually empty (0 bytes), and their .0 files indicate that these are the ad banners (requesting a URL from googleads.g.doubleclick.net). So it looks like whatever system in Grindr is responsible for downloading pictures also sorta deals with downloading ad banners, except it doesn't actually save the banner into the cache folder.

The last somewhat not-very-interesting file in the cache folder is called "journal", and it's a text file. By reading the first couple lines, it appears to be part of libcore.io.DiskLruCache, a bit of Java code that provides a rotating offline cache. This probably means that, if Grindr's cache folder fills up, it will automatically remove old files to make room for new ones, so it can keep its overall disk usage under control automatically. The journal file appears to list the hash names of all the other files in the folder, along with words like "CLEAN", "DIRTY", and "REMOVE".

Tags: 26 comments | Permalink
Android 4.0 in VirtualBox
July 11, 2012 (updated October 28, 2021) by Noah
Update (Oct 2021): while this blog post is obviously VERY old now, describing a version of Android from almost a decade ago, the basic steps still apply; android-x86.org still produces Android x86 images for modern versions of Android and they still install the same.

Sometimes they include Gapps out of the box, sometimes not, google around if they don't and you need them. I haven't played with Android-x86 in some years now, the last image I did install (around 2019) had Gapps and I used this VM to manage my Google WiFi routers because my primary Android phone was de-googled and could not use the Google WiFi app. Your mileage may vary.

This information is a little hard to find on the Internet. This is how to install Android 4.0 (Ice Cream Sandwich) in VirtualBox, in a "do it yourself" way (installing from an ISO image). There are some people who have made pre-installed VirtualBox images, but one problem you may run into going that route is that the Android serial number will match everybody else who's using the same image as you, since Android generates this number on its first boot.

Android ICS Screenshot
Screenshot of my Android VM. Click for bigger version.

First of All

(Update 9/3/13)

Apparently, the official Release version of Android 4.0 from android-x86.org should work completely out-of-the-box in VirtualBox: android-4.0-r1. I have an older development release linked later in this post that was built specifically for VirtualBox, which is what this post was originally written about. The Release version of Android 4.0 also contains Google Play and the other Google apps out of the box, so you can skip the part about installing the Google apps later. Thanks @DrDeve for pointing this out!

(Update 8/30/13)

This blog post is about a very particular build of Android 4.0 that is linked to later in this post. The instructions that follow are known to work when installing from that ISO image. There does exist Android 4.3 ISOs from android-x86.org and when I tested them, a lot of stuff seemed to just work out of the box in VirtualBox, but this blog post isn't about Android 4.3.

Also, if you're using a different Android 4.0 ISO you found somewhere else, there's no guarantees it will work very well for you. Networking and audio are some of the biggest problems I've seen in Android virtualization. So, before you ask me for help with installing or getting the networking to work (hint: networking should just work with no extra fuss), make sure you're actually using the ISO image linked later in this blog and not some other random one. The one I have was designed specifically for VirtualBox and it works.

Getting an Android ISO

Update (9/3/13): The final 4.0 release by Android-x86 is available from android-x86.org, and it should work completely out-of-the-box in VirtualBox and includes Google Play and the other Google apps. You should probably download it from there instead of the older development version I link to below.

The folks at Android-x86 have been making x86 builds of the Android OS for quite a while now, and none of this would be possible without them. They have ISO images for various versions of Android available, but most of them don't work very well in VirtualBox. For example, their "eeepc" image for Android 4.0 has issues with the audio drivers and the network (it has no Ethernet support built in, etc.)

So this means using one of the Android-x86 images from there won't get you too far because audio and networking won't work. Fortunately, somebody has put together an ISO image that's been custom tailored to VirtualBox. I don't remember where I found this ISO image; if it's yours, leave me a comment and I'll edit this post. ;) I found the ISO here: android-x86 VirtualBox/VMWare support (thanks @jakimfett!)

I have a copy of this ISO hosted here: android-x86-vm-20120130.iso (244MB). This ISO works much better.

Create a Virtual Machine

In VirtualBox, create a new machine for Android.
  • Machine Name: "Android ICS" (you can name it anything you want)
  • Machine Type: "Linux 2.6"
  • Memory: I gave my VM 1024MB of memory.
  • Hard Disk: I created a new 16GB VDI image that dynamically expands.
All the default settings worked fine for me. Here's what the defaults were on my system:
  • Networking:
    • Type: NAT
    • Adaptor: "Intel Pro/1000 MT Desktop (82540EM)"
  • Audio: Intel AC'97
  • Storage Layout:
    • IDE Controller:
      • CD Device
    • SATA Controller:
      • Hard Disk
Update: In the comments, @Ni mentions this:
Make sure you add the SATA Controller if it does not appear, when you setup the virtual box and then add the ISO image and virtual disk image to this.

If you try and add the ISO image and virtual disk image to the IDE Controller this will not work at.

This information maybe useful to someone making this mistake.

It worked for me as listed above (IDE CD drive, SATA hard disk), but this is something to keep in mind if you have any issues booting the CD or installing it to disk.

Installation

Make sure the VM boots from the ISO image.
  1. On the boot screen, select "Installation - Install Android-x86 to harddisk"
  2. Choose "Create/Modify Partitions". This takes you into cfdisk.
    1. Choose "[New]"
    2. Choose "[Primary]"
    3. Press enter to accept the default partition size (mine was 17174.38)
    4. Choose "[Bootable]"
    5. Choose "[Write]"
    6. Type "yes" to confirm writing.
    7. Choose "[Quit]"
  3. Choose to install on the sda1 device (Linux VBOX HARDDISK)
  4. Choose to format the drive "ext3"
  5. Pick "Yes" to confirm formatting.
  6. Pick "Yes" when it asks to install the GRUB bootloader.
  7. Pick "Yes" when it asks to mount /system as read-write (this will be important later to install the Google apps).
  8. Create a fake SD card when it prompts. I made mine 2047MB (the maximum allowed).
  9. Choose "<Reboot>"
Make sure you detach the ISO image from the virtual machine so that it will boot into the installed OS. If you see the "Installation" option again, it means you're booting from the ISO still!

Note About Internet Access in Android

(Update: 9/3/2013): @DrDeve commented about the network settings for VirtualBox/Android:
Internet not working is often because the kernel has no driver for your NIC and / or you are in bridged mode

The AMD-PCnet is the standard for virtual drivers for VB and VMware - including the heavy iron VmWare ESX -- no matter what you have installed switch VB settings to the PCnet driver and use NAT -- IT WILL JUST WORK IF YOU DO! Native drivers often dont start until you open VB settings box - quirky -- use the de-facto standard PCNET NIC driver.

(Update: 8/30/2013) This is a common question people have, is how does the Android VM's connection to the Internet work?

I'd refer you to the VirtualBox documentation about networking, but briefly: configure your guest OS's network to use NAT mode. This is the simplest way to do it.

What happens in NAT mode is, Android will boot up, see an imaginary router handing out IP addresses, and get one. And, it doesn't matter what your real life network layout looks like (whether your physical computer is connected to Ethernet, Wifi, a 4G LTE dongle, dial-up modem, VPN), the Android virtual machine will always think it's connected to Ethernet. So, questions of "how do I connect to my Wifi?" don't make any sense when you understand how VirtualBox (and most other virtualization systems) work. If your host computer has an Internet connection, the virtual machine should have it as well, automatically.

This may be a bit confusing for Android users though because Android typically doesn't use Ethernet. The lock screen in the Android VM will say "No Internet connection", and in your settings, Wifi will probably be turned off and resist turning on. Completely ignore both of these things. The VM is using Ethernet for its connection, so just try opening the web browser and point to kirsle.net or something and see if it loads.

Tips for Running Android

You'll want to disable mouse integration to be able to interact with the GUI at all. This can be done from choosing the "Machine" menu in the VM window and clicking "Disable Mouse Integration" -- or pressing HostKey+I.

The Escape key on your keyboard corresponds to the Back key in Android. The context menu key on your keyboard corresponds to the Menu button in Android (the context menu key is usually next to the right Windows key).

To power off the VM, press HostKey+H. This will cause Android to pop up the shutdown dialog that you'd expect on a real phone. You can also use the "Machine->Send Shutdown Signal" to do the same.

Update (9/3/2013): @DrDeve mentions how to get out of the lock screen when Android's Powersave kicks in:

OK, one more thing I forgot -- Powersave

For some darn reason you cant bring a VB ICS 4.0.4 build out of powersave (hybernation for my Windows friends) by clicking on the video screen.

So if your VM goes into lockscreen while you are playing a game or something, after stopping for about 2 min (time to lock is configuratble in Settigns)

You will need to press on the right menu key several times, once only shows a lockscreen "ping"

the menu key is the key between the right hand alt and Ctrl keys on most modern keyboards

have fun

The Doctor

Install the Google Apps

NOTE: You can skip this step if your Android ISO already included the Google apps out of the box. (Updated 9/3/13)

You may notice that this Android VM doesn't include the Android Market, GMail, or Google Maps. These are some of the Google Apps and due to some licensing restrictions Android-x86 doesn't include them "out of the box".

On a real Android device that's been rooted and flashed with a custom ROM, you'd install the Google apps by flashing them in recovery mode. But you can't get into recovery mode on VirtualBox. Thus, the method for installing the Google Apps is kinda sketchy, but it works (and if you know of a better way, feel free to tell me).

You'll need a file with a name like "gapps-ics-20120304-signed.zip". These are the Google apps (the date part might be different). You can Google them, but I have a copy of them here to download too.

You don't really need the entire Google Apps file, actually. Just the "system" folder inside the zip file. Create a new tar file of the "system" folder so that it will be easy to get it into your Android device. I have a prepared "system.tar.gz" for you if you just want to use mine.

The steps to install the Google Apps are as follows:
  1. Download system.tar.gz to your Android VM somehow. I used the Web Browser app and downloaded it there. You could probably also use the Email app, or if you're really Android savvy, push it with the Android Debugger.
    • If Android tells you that there is no SD card so it can't download the Google Apps, that's because you skipped that step while first installing your Android system. The very last step of the installer asks if you'd like to create a virtual SD card partition, and you should've had it do that. If you didn't, the only easy solution I know of is to reinstall the OS.
  2. Open the "Terminal Emulator" app in Android.
  3. Enter these commands (note: don't type the $ or # symbols at the beginning of these lines. These symbols indicate the prompt.)
    $ cd /sdcard/Download
    $ tar -xzvf system.tar.gz
    $ su
    # cd /sdcard/Download
    # cp -rf system/* /system/
    Pay special attention to the cp -rf command. Make sure the slashes and *'s are in the right places.
  4. Reboot the phone.
You should now see the Market app, GMail and the others in your app menu.

Note: in my experience, the Market app will be somewhat unstable. When you start the app, it will Force Quit after 10 or 15 seconds. However, if you're fast enough you should be able to quickly search for a specific app you'd like and begin the download process before Market crashes, and the app will continue to download and install regardless.

I imagine that the unorthodox way of installing the Google Apps might be partly to blame for the Market being unstable. The other Google apps seem to work fine though.

Custom Screen Resolutions

This is a tip I discovered somewhere a while back for getting custom resolutions to work in your Android VM (for example, to mimic the screen dimensions of the Galaxy Nexus phone, or just to run the VM at a higher resolution like 1024x768). I've found that you can use just about any arbitrary resolution you want, but when the resolution isn't a standard 4:3 one (like 1024x768), the VM seems to get somewhat laggy.

The general steps are as follows. Substitute 1024x768 with whatever resolution you want. You can add multiple video modes by changing "CustomVideoMode1" to be "CustomVideoMode2", etc.

  1. In your Terminal or Command Prompt window on the host system, run this command:
    VBoxManage setextradata "Android ICS" "CustomVideoMode1" "1024x768x32"
    Substitute "Android ICS" with the name of your VM (but keep the quotes).
  2. Start your Android VM, and when you see the bootloader screen:
    1. Press the "e" key to edit the boot arguments
    2. Press "e" again to edit the kernel boot line
    3. Add UVESA_MODE=1024x768 to the end of the boot arguments (make sure to hit Space first), and press Enter.
    4. Press "b" to boot.
There should theoretically be a way to edit the GRUB config file and add more boot options that have the custom resolutions already configured, but I'll leave that as an exercise for the reader. :)

Update (9/3/2013): @DrDeve mentions in the comments:

If you install GRUB bootloader you can hit e to edit like you say, or a, then press space and type vga=ask then press enter.

a long list of VESA modes (and the color bits from 8-32) will be displayed. Not all will ork, so selecting one here, resetting the VM if it doesnt work BEFORE editing the config files may save you from bricking your new toy!

Each entry is a thre char hex value, follwed by the resolution, like 1024x768x32, etc.

Once you find a mode that works, THEN modify the config using the hex value that worked using the methods above.

You can als edit the GRUB menu.lst to add the value from the sceen above

- convert the hex value that worked to decimal (i.e. 360 becomes 864, etc).
- open terminal
- su
- cd /mnt/grub
- vi menu.lst
- add vga=864 to the end of the line that startes with &quot;kernel&quot;, or if one is there, modify it
- save the file by entering :wq

if you havent used vi before you might need a guide open beside you look here http://www.cs.colostate.edu/helpdocs/vi.html

No Warranty

Android is primarily an ARM architecture operating system and the x86 version isn't supported by Google. While a lot of apps will work in Android-x86, some may crash in weird ways. If you're an Android developer though, this can be pretty useful because Android-x86 will run a lot faster on your hardware than the standard emulator from the SDK does, so you can test your apps much more rapidly (the Android-x86 site has some documentation on how to connect ADB to your virtual machine).

Your mileage may vary.

Updates

To answer common questions that come up in the comments...
  • Adobe Flash, Netflix, others... -- these apps won't work in Android-x86, because they aren't pure Java. They include C code that's compiled for the ARM processor found in most Android devices. They won't run on x86 processors.
  • Apps that rotate your screen... -- apps that force the orientation into portrait mode (thus turning your screen sideways) can be dealt with by changing your VM's screen resolution to be taller than it is wide (i.e. 800x1280). The app will recognize the portrait resolution and not rotate. However, your VM may be laggy when it's not in a standard 4:3 resolution. Alternatively, find an app that forces/locks your orientation to one direction or another -- however, some apps misbehave when forced to use the wrong resolution and may not be usable.
  • Don't expect a lot of apps to work -- for various reasons, apps that work on real Android devices may not function properly on Android-x86.
  • Text messaging and phone calls won't work -- Your virtual machine is not a phone. It doesn't have a cellular connection to AT&T or Verizon or anybody. The standard texting apps like Messaging and Handcent SMS are useless on an Android VM (this also goes for most Android tablets that don't have cell connections). If you want to text from your VM, you might try using the Tablet Talk app, connect it with your actual cell phone, and text through that app. If you want to make phone calls, you might have luck with a Voice over IP app -- however, I can't guarantee your microphone and such will work with the VM, as I haven't tested it.
I'll update the list above as more common questions come in from the comments below.
Tags: 300 comments | Permalink
Android - MMS Without Data
September 20, 2011 (updated January 23, 2023) by Noah
UPDATE (2017/02/07): because some people can't read, I thought I'd reiterate the key points here at the top of the post:
  • MMS picture messaging simply requires mobile data to be enabled (how do you think all those JPEG bits are getting transferred? They won't fit in the 160 character SMS limit!)
  • The steps on this post end up with mobile data enabled so that MMS works, but it blocks mobile data for Internet use so the other apps can't use it.

Any further comments being like "hurr durr you get MMS to work without data by turning on data" will be redirected to /dev/null. And anyway, this blog post was written when Android 2.3 was current and the steps probably don't even line up 1:1 any more.


UPDATE (2023/01/22): for more clarification, in recent years I've learned a hella lot more about cellular APNs especially since I started tinkering with my Linux phone. The cliffnotes are:
  • Plain text SMS messages get to ride for free. Your phone is making frequent pings to the tower (standard voice signal support) and there was some unused header space on those pings that SMS can slot right onto. That's why it has a 160 character limit: that was the size of the free space on those standard pings.
  • MMS messages are data, and go over the Edge, 3G, 4G, LTE, 5G, etc. data channels.
  • This blog post was about: can I disable mobile data for Internet so that apps don't use my data; but still have MMS working on my phone, which turning mobile data off would also block.
  • An APN can be configured for MMS delivery, for internet data, both, or neither. This post sets the APN for MMS only.

This post was written in the Android 2 days, and I don't know how you do this on modern Android today. Hopefully the above gives you some useful information, and let me know in the comments what the instructions would be today. On to the original post:


Today I finally decided to break up with T-Mobile and take my number and Nexus One phone to AT&T, as a prepaid phone (tl;dr - I'm tired of cell phone ISPs locking people in to contracts and then they can't do anything about it when the ISP changes their plans around).

My Nexus One was originally for T-Mobile's network, so it doesn't work with the 3G on AT&T's... but that's fine because my AT&T plan doesn't include data. But, my phone can still use AT&T's Edge network.

I don't want any random background apps using the Edge network and costing me usage fees when I'm out and about. But, if I disable Mobile Data altogether, picture messaging (MMS) stops working too. So after a lot of searching around I seem to have found a way to disable the mobile network for all apps, but still allow MMS to be sent/received using it.

On my Nexus One, from the home screen:

  1. Push the menu button and pick Settings
  2. Pick "Wireless & networks"
  3. Pick "Mobile networks"
  4. Make sure "Data enabled" is checked (MMS won't work either if you disable it here!)
  5. Go to "Access Point Names"
    • On my phone, the only APN here was named "ATT (wap.cingular)"
  6. Scroll down to the "APN type" setting.
    • On my phone, the original value for this setting was "default,supl,mms"
  7. Change its value to be only "mms".
  8. Push the menu button and pick "Save."
After this, I tested it. I was able to send and receive MMS messages (which turned on the Edge network notification), but apps like Facebook, Google+, and the mobile web browser all complained that I didn't have an Internet connection.

YMMV.

Tags: 32 comments | Permalink
Azulian Tag
November 29, 2010 (updated February 10, 2018) by Noah
Several years ago I used to make short RPG games using RPG Maker 2003, and among the many little games I made three of them that followed a story I was writing about my Azulians (seen here battling some other creatures I made up).

I've sufficiently lost all those games and all the files that went with them at some point since then, and now all I have left are the front-facing sprites for all the Azulians:

RPG Maker Sprites

A recurring element in the games, though, was a mini-game called "Azulian Tag", which is sorta the opposite of regular tag: the player who is "it" is hunted down by all the other players. In the games, there would be blue Azulians that travel the same speed as the player (and thus are easy to run from as long as you keep on moving), red ones that move a little bit faster than the player, and white ones that move even faster. The game would start you out surrounded by about 6 blue Azulians, then 4 red ones further out and 2 white ones much further away, to give you time to run. The goal of the game was just to survive as long as possible.

Anyway, I decided recently that this mini-game might be a good idea to turn into a game on its own, for Android. I discovered PhoneGap, a toolkit for using web technologies to create mobile apps for iPhone and Android among other devices, and therefore decided that HTML (5) and JavaScript should be sufficient for creating such a game. In addition to just running away from the other Azulians, some new "powerups" could be added in, like being able to teleport the player to a random point on the map to buy back a few seconds of time before the other Azulians discover where you've teleported to. I'm working on some sprites now; I've already revamped the blue Azulian sprites from the RPG Maker 16x16 size to a higher quality 32x32 size:

Azulian Tag Sprite

Tags: 1 comment | Permalink
Android Mini PC
October 12, 2010 by Noah
The device of my dreams: a no strings attached, open Android-powered device, which is like a smartphone (touch screen etc.), but which is not a phone, but can get a data plan from any cell carrier in the same way that laptops can use 3G cards and get internet anywhere from a cell phone carrier.

It would basically be a miniature PC that resembles an Android phone, but which isn't a phone, but which you can just install Skype on if you really need to make a phone call, since it could still get cellular data service.

And, being like a miniature PC, it would be as open to operating systems as a real PC; it would be just as easy to install and reinstall Android firmwares (or any compatible OS) to it as it would reinstalling your operating system on your laptop.

I imagine Dell would be a good manufacturer for such a device; they would market it just like they market netbooks, as being just a mini PC that happens to run Android (preferably the stock vanilla Android as Google intended it, but being open you could flash any version of Android you want).

If such a device existed I would buy it as soon as it came out. I'm quite sick of the way phone carriers abuse the Android OS and wish there could just be a seriously open device.

Tags: 3 comments | Permalink
Standing on the Shoulders of Android
July 20, 2010 by Noah
I saw on Digg today that Google discontinued sales of their Nexus One phone, following "disappointing sales."

What it really means from what I've read is that Google is just not selling the phone themselves directly but it can still be obtained via other means (developers can still buy them and they're still being sold in other countries), but that Google still intends to support the phone for the foreseeable future -- it will still be the first in line to get Android updates, for example.

I have a Nexus One and I like it and this news is a bit worrisome to me, but not in the way you might expect. Rather, because the Nexus One is one of the few Android phones that is truly open.

Apparently, the very first Android phone (the G1), the first Droid, and the Nexus One are pretty much the only Android phones that ship with the stock, vanilla, Android firmware. All the other HTC phones out there for example run the "HTC Sense" UI on top of Android, and the Motorola phones run the "Motoblur" UI; some people don't like these add-ons on top of Android and would rather run Android the way Google intended, using the stock vanilla release of the ROM. Or, some people just like to hack their phones and have root access on them.

The Nexus One phone made it really easy to unlock your bootloader and install custom/unsigned Android ROMs onto the phone if you wanted to (it would even provide a nice screen warning you that you're about to void your warranty). The Nexus One allows you to install whatever you want on it, and both Google and the phone itself fully supports this. But, other phones, notably the Motorola phones that come with an eFuse that will practically "brick" your phone if you try to modify its firmware, aren't so open.

There seems to be a trend in Android phones in which companies are trying to play Apple; Apple's iPhone devices are super locked down, and Apple tries to patch all the security holes to stop people from jailbreaking their devices - with each firmware release Apple tries to make it harder and harder to hack the iPhones. In Apple's ideal world, their hardware would be completely 100% impenetrable from hackers and nobody could modify their devices. It seems Android vendors want to copy this business model, which I for one do not like.

It seems Android vendors are "standing on the shoulders of giants," they look at Android and all they see is a free open source Linux-based mobile operating system, and they wanna just take all that hard work, add a few things to make their devices a major pain in the ass to hack (in their ideal world, absolutely impossible to hack) and then jerk their customers around in exactly the same way that Apple does. Is this really what Android was supposed to be all about? Just giving greedy megacorporations the cheap tools they need to strongarm part of the cell phone monopoly in their favor?

Hopefully the Nexus One won't be the last developer phone that can be bought by non-developers. I got mine specifically because it ran the stock unmodified Android firmware and because it was completely open to customization. As I ranted about before, I don't like how Apple is able to just slow down your old phones and force you to upgrade; at least I have the comfort of knowing I can easily flash any Android ROM onto my Nexus One and nobody can force me to upgrade by slowing my phone down or doing anything else malicious to it.

God help us if this is the future and we're stuck with many Apple-like companies all forcing us to use their locked-down devices that we're not allowed to touch at all for fear of permanently bricking our devices.

Tags: 1 comment | Permalink