But you’ll probably need a work-around for Android Issue 3708. In this document I describe what I had to do to get it working on my platform. My assumption is you’ve already been Googling around, and so have a little background on this, but are still scratching your head as to why it’s not working. Hopefully, you won’t be in that position after reading this!

Hold a PARTIAL_WAKE_LOCK

Some relic platforms of the past might have skated by holding just a PARTIAL_WAKE_LOCK. For me this was necessary, but not sufficient. Even while holding the lock, my service ceased to receive notifications via onSensorChanged() nor onAccuracyChanged().

Re-register Your Listeners When The Screen Goes Off

Some then propose to take action when the screen turns off. In this post on StackOverflow, for example, the author proposes un-registering and re-registering to receive sensor events at that time.

Use a Delayed Thread, for the Above

The above two techniques are ultimately what I’ve used to solve the problem, except I had to make one additional modification. When the BroadcastReceiver receives an ACTION_SCREEN_OFF Intent, I queue a thread to run 500ms in the future, instead of running immediately. This ensures that most other activities surrounding the screen off will have completed. So at that time, 500ms later, we un-register and re-register our service as a sensor event listener.

This is how I’ve implemented the BroadcastReceiver:

    public BroadcastReceiver mReceiver = new BroadcastReceiver() {
        @Override
        public void onReceive(Context context, Intent intent) {
            Log.i(TAG, "onReceive("+intent+")");

            if (!intent.getAction().equals(Intent.ACTION_SCREEN_OFF)) {
                return;
            }

            Runnable runnable = new Runnable() {
                public void run() {
                    Log.i(TAG, "Runnable executing.");
                    unregisterListener();
                    registerListener();
                }
            };

            new Handler().postDelayed(runnable, SCREEN_OFF_RECEIVER_DELAY);
        }
    };

You may have to play with the value of SCREEN_OFF_RECEIVER_DELAY — for me, 500 (milliseconds) was the minimal value that would get it working.

See the Code In An Example App

I’ve posted an example app which includes the above code. It shows a foreground service holding a PARTIAL_WAKE_LOCK, doing the re-registration business mentioned above. The result is a service which continues to receive sensor events even after the screen goes off (for whatever reason.)

https://github.com/jamesonwilliams/AndroidPersistentSensors

Well, it worked for me at least. Does it work for you? (Please comment below.)

References

• http://mylifewithandroid.blogspot.com/2010/04/monitoring-sensors-in-background.html
• http://code.google.com/p/android/issues/detail?id=3708
• http://stackoverflow.com/a/2167311/695787

To start, create a directory like ~/gcc-4.7, and export it’s absolute path into an environment variable.

Note: this isn’t necessary, but it cleans up our configuration options. Depending on your use case, you might just choose to install to the /usr/local prefix, or even something more serious like /usr.

mkdir ~/gcc-4.7
export PROJECT_DIR=$(cd ~/gcc-4.7 && pwd && cd - &>/dev/null)

Get the Source Packages

Firstly, you’ll want to download all of the necessary packages. I created a directory for these in $PROJECT_DIR/sources:

mkdir $PROJECT_DIR/sources && cd !$

1. PPL latest (0.12):

   wget http://bugseng.com/products/ppl/download/ftp/releases/LATEST/ppl-0.12.tar.gz

2. CLooG 0.16.1:

   wget http://www.bastoul.net/cloog/pages/download/count.php3?url=./cloog-0.16.1.tar.gz

3. MPC latest (0.9):

   wget http://www.multiprecision.org/mpc/download/mpc-0.9.tar.gz

4. GMP latest (5.0.4):

   wget ftp://ftp.gmplib.org/pub/gmp-5.0.4/gmp-5.0.4.tar.bz2

5. MPFR latest (3.1.0):

   wget http://www.mpfr.org/mpfr-current/mpfr-3.1.0.tar.bz2

6. GCC 4.7.0:

   wget http://www.netgull.com/gcc/releases/gcc-4.7.0/gcc-4.7.0.tar.bz2

Okay, now unpack them. This should do the trick:

for file in *.tar.gz; do tar xzvf $file; done
for file in *.tar.bz2; do tar xjvf $file; done

Building the Pre-requisites

From here, you can mostly follow this documentation on building 4.7 for Mac OS X Lion. A couple of notable differences, though.

It’s good practice to build in a separate directory from the source. So I create a directory $PROJECT_DIR/build. Also at this time I create directory $PROJECT_DIR/output, which will be the install target for everything we build.

So let’s get right down to it.

Build GMP:

mkdir $PROJECT_DIR/build/gmp
cd !$
../../sources/gmp-5.0.4/configure --prefix=$PROJECT_DIR/output/
make && make install
cd -

Build MPFR:

mkdir $PROJECT_DIR/build/mpfr
cd !$
../../sources/mpfr-3.1.0/configure \
    --prefix=$PROJECT_DIR/output/  \
    --with-gmp=$PROJECT_DIR/output/
make && make install
cd -

Build MPC:

mkdir $PROJECT_DIR/build/mpc
cd !$
../../sources/mpc-0.9/configure     \
    --prefix=$PROJECT_DIR/output/   \
    --with-gmp=$PROJECT_DIR/output/ \
    --with-mpfr=$PROJECT_DIR/output/
make && make install
cd -

Build PPL:

mkdir $PROJECT_DIR/build/ppl
cd !$
../../sources/ppl-0.12/configure  \
    --prefix=$PROJECT_DIR/output/ \
    --with-gmp=$PROJECT_DIR/output/
make && make install
cd -

Build CLooG:

mkdir $PROJECT_DIR/build/cloog
cd !$
../../sources/cloog-0.16.1/configure \
    --prefix=$PROJECT_DIR/output/
    --with-gmp=$PROJECT_DIR/output/
make && make install
cd -

And that’s that!

Build GCC 4.70

Okay, so now it’s time for the main attraction, the compiler suite itself.

mkdir $PROJECT_DIR/build/gcc
cd !$
../../sources/gcc/configure          \
    --prefix=$PROJECT_DIR/output/    \
    --with-gmp=$PROJECT_DIR/output/  \
    --with-mpfr=$PROJECT_DIR/output/ \
    --with-mpc=$PROJECT_DIR/output/  \
    --program-suffix=-4.7            \
    --enable-cloog-backend=isl       \
    --with-ppl=$PROJECT_DIR/output/  \
    --with-cloog=$PROJECT_DIR/output/

export LD_LIBRARY_PATH=$PROJECT_DIR/output/lib/
make && make install
cd -

Note the LD_LIBRARY_PATH line. That’s crucial if you’re not installing to the default location, /usr/local, because your libraries won’t be in the PATH specified in the ld.so.conf files.

The --program-suffix=-4.7 flag is of course a matter of personal taste, and can be omitted if you like.

It may be possible to use a value for --enable-cloog-backend other than isl, but that seemed to work.

Also, there are of course hundreds of other reasonable GCC configurations possible. Your mileage may vary, but this is pretty vanilla, and it produces a working toolchain. (Which is a nice quality to it.)

Thanks for reading!

References

• Cannot compute suffix of object files : gcc 4.4.x and $gt;
• Living on the edge building gcc-4.7 on Mac OSX Lion
• LFS Chapter 6.17. GCC 4.7.0

Consider the last time you installed an app — did you look closely at the permissions? I sometimes look out of curiosity, or to make sure they are not blatantly egregious. But, even then I often assume someone else has scrutinized the application for me.

A revised system might foster a “Permission on Demand” model, as implemented in most modern Web Browsers. As non-core features are needed, the user is able to allow or disallow the permission — optionally, to always or never allow. Some more elevated permissions — those sensitive to the user’s data and identity — might always require explicit consent.

The new permissions system would extend the existing infrastructure beyond the all-declarative uses-permission element, to include a new requests-permission element. Required permissions would then only be those necessary for basic operation of the application. All other permissions would be declared with requests-permission. At install, these could be set to “Never,” “Always”, or “Ask me.” The default would be “Ask me.”

Much later, when the user has forgotten the particulars of this interaction, the application might try to request an optional permission. At this time, the user would make a decision appropriate to the context: “Not now,” “Never,” “Yes,” or “Yes, always.” In the event that the User decided to deny the permission, the application would display an error message stating that the functionality was not available — or degrade gracefully. Up until then, however, the application would have been entirely functional as expected, operating perfectly happily without the permission.

Now this all sounds like the Web. In many ways, as horrifying as Web programming and security has been throughout its lifetime, the infrastructure seems to have gained a certain degree of maturity. Here, for example, we either evangelize a mass movement to HTML5, or make a request to “forward-port” a better permissions model to Android.

So who’d like to code this up?

Anyway, here’s a blog about the Android Application Lifecycle, viewed from the eye of some simple get-started-already code.

Setup Our Test Code

mkdir LifecycleTest
cd LifecycleTest

android create project \
    --target "Google Inc.:Google APIs:10" \
    --path . \
    --package org.nosemaj.lifecycle_test \
    --activity LifecycleTest \
    --name LifecycleTest

Okay, fine. Now let’s create a simple Activity which will show us whenever a new lifecycle change occurs:

In src/org/nosemaj/lifecycle_test/LifecycleTest.java, I have:

package org.nosemaj.lifecycle_test;

import android.app.Activity;
import android.os.Bundle;
import android.util.Log;

public class LifecycleTest extends Activity {
    public static final String TAG = LifecycleTest.class.getName();

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        Log.i(TAG, "onCreate()");
    }

    @Override
    protected void onStart() {
        super.onStart();
        Log.i(TAG, "onStart()");
    }

    @Override
    protected void onRestart() {
        super.onRestart();
        Log.i(TAG, "onRestart()");
    }

    @Override
    protected void onResume() {
        super.onResume();
        Log.i(TAG, "onResume()");
    }

    @Override
    protected void onPause() {
        super.onPause();
        Log.i(TAG, "onPause()");
    }

    @Override
    protected void onStop() {
        super.onStop();
        Log.i(TAG, "onStop()");
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        Log.i(TAG, "onDestroy()");
    }
}

Boom. Wham, bam; presto.

Moving right along, then, let’s build the thing and start seeing what gets called when:

ant clean; # out of habit
ant debug
adb install bin/LifecycleTest-debug.apk

Some Common Activity Change Scenarios

Let’s consider a few scenarios we might want to test, which occur frequently to an Application in the wild:

1. The app is started from the launcher.
2. The user hits the “Back” button while in the app.
3. The user hits the “Home” key while in the app.
4. The user does nothing, and the screen goes to sleep.
5. The user wakes up the phone to resume the app.
6. The user launches a new application, whilst the one we’re testing is running.
7. The screen orientation changes

There might be some other important things, but that seems like a good start to get our feet wet.

So let’s start observing messages:

adb logcat | grep LifecycleTest

The app is started

I/ActivityManager(   61): Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=org.nosemaj.lifecycle_test/.LifecycleTest } from pid 126
I/org.nosemaj.lifecycle_test.LifecycleTest(  371): onRestart()
I/org.nosemaj.lifecycle_test.LifecycleTest(  371): onStart()
I/org.nosemaj.lifecycle_test.LifecycleTest(  371): onResume()

Look like the documentation.

The user hits the “Back” button:

I/org.nosemaj.lifecycle_test.LifecycleTest(  371): onPause()
I/org.nosemaj.lifecycle_test.LifecycleTest(  371): onStop()
I/org.nosemaj.lifecycle_test.LifecycleTest(  371): onDestroy()

The Back key destroys the app.

The user hits the “Home” key:

I/org.nosemaj.lifecycle_test.LifecycleTest(  371): onPause()
I/org.nosemaj.lifecycle_test.LifecycleTest(  371): onStop()

Aha, no onDestroy(), this time.

The screen falls asleep

I/org.nosemaj.lifecycle_test.LifecycleTest(  371): onPause()

Just only onPause() gets called this time.

The screen wakes up to the app

I/org.nosemaj.lifecycle_test.LifecycleTest(  371): onResume()

Something gets launched over this app

I/org.nosemaj.lifecycle_test.LifecycleTest(  371): onPause()
I/org.nosemaj.lifecycle_test.LifecycleTest(  371): onStop()

Screen orientation changes

I/org.nosemaj.lifecycle_test.LifecycleTest(23872): onPause()
I/org.nosemaj.lifecycle_test.LifecycleTest(23872): onStop()
I/org.nosemaj.lifecycle_test.LifecycleTest(23872): onDestroy()
I/org.nosemaj.lifecycle_test.LifecycleTest(23872): onCreate()
I/org.nosemaj.lifecycle_test.LifecycleTest(23872): onStart()
I/org.nosemaj.lifecycle_test.LifecycleTest(23872): onResume()

Wow, a slew of stuff. The application gets destroyed — only to be recreated again in new skin a moment later. Baller.

Conclusion

Well, so that’s probably enough of that for now wouldn’t you say?

Anyway, I think the point is that onPause() and onResume() are the only really reliable ones. You might save a little gas by putting a select few lines in onCreate(), but probably better to put the volatile stuff in onResume().

If you want to play around with this code, I’ve posted it to Github.

Consider that you might want to just actually use the real Twitter instead of reinventing the wheel. That said, sometimes it can be useful to get assets from Twitter.com to display in your app, as they pertain to your app.

In Android, you can launch Twitter with one line of Code:

startActivity(new Intent(Intent.ACTION_VIEW, Uri.parse("http://www.twitter.com"));

You can also share content with about just as many lines, by using an ACTION_SEND. Anyway, if you need to do something deeper, you have to leverage the Twitter API directly.

Get the Twitter4J Jar

Download this: http://twitter4j.org/en/twitter4j-android-2.2.5.zip. Extract the core jar, and put it in the libs directory of your android project.

Register Your App with Twitter

You need to do this to placate their OAuth nonsense. Visit https://dev.twitter.com/apps/new.

Add the OAuth Keys to Your App

In res/values/strings.xml, add the lines:

<string name="twitter_oauth_key">PUT YOUR CONSUMER KEY HERE</string>
<string name="twitter_oauth_secret">PUT YOUR CONSUMER SECRET HERE</string>

Note: Here we take a No-BS approach to the OAuth stuff. (In figuring out how to do this, there are a lot of posts on the internet you have to sort through that don’t.) One solution for hiding your OAuth secret is to keep it on a server and proxy your requests to Twitter through that host. Needless to say, that’s not covered here.

Get a Handle to the Twitter obejct in Java

ConfigurationBuilder cb = new ConfigurationBuilder();
String key = getApplicationContext().getString(R.string.twitter_oauth_key);
String secret = getApplicationContext().getString(R.string.twitter_oauth_secret);
cb.setOAuthConsumerKey(key);
cb.setOAuthConsumerSecret(secret);
Twitter twitter = TwitterFactory(cb.build()).getInstance();

Example Use

And that’s basically it. Now you you can get info from twitter using the Twitter object. For example, here’s how to get a list of tweets about Potatos.

List<Tweet> tweets = twitter.search(new Query("Potatos")).getTweets();

See Code in an Example App

I have created an example app that shows the above. Check it out on Github: https://github.com/jamesonwilliams/AndroidTwitterExample

References

1. Stack Overflow – Android Twitter xAuth example using twitter4j
2. Twitter4J Twitter Class Documentation
3. Twitter4J Example Code
4. Twitter Endorsed Client Libraries

• Howto write a driver for an i2c client device
• Overview of Workqueues in 2.6

Anyway, I’d never explicitly tried it before, so I was a bit unsure of how to use a workqueue for a bottom-half for my ISR. Anyway, it is really that easy. Here are the key components (this is for Android Froyo, 2.6.31 I think.)

In what follows, remember: “work” is a work_struct, and “worker_function” is a function pointer.

Setup the WorkQueue

First, include the header:

#include <linux/workqueue.h>

Somewhere near the top, declare a work_struct:

static struct work_struct work;

Somewhere in your init routine, initialize that structure:

static int __init module_init(void)
{
...
        INIT_WORK(&work, (void *)worker_function);
...
}

worker_function is a function pointer to the task to be done. It can be as simple as:

static void worker_function(void)
{
    /* Do some work! */
}

Use it in an ISR

So, nothing will ever happen unless you schedule the thing somewhere. You might probably like to use the workqueue as a bottom-half for an interrupt service routine (be sure to register that separately via request_irq()):

static irqreturn_t isr(int irq, void *data)
{
        /* schedule_work() returns 0 on failure. */
        if (0 == schedule_work(&work)) {
                return IRQ_NONE;
        }

        return IRQ_HANDLED;
}

Notes

One interesting note: in a number of places on the web, INIT_WORK is documented as taking a third argument — the (void *) argument to the function pointer (argument 2). However, this was not the case in my kernel tree. INIT_WORK for me simply took the work_struct and the worker_function.

Wait… are there bells and whistles that you’re not mentioning?

Yea, probably, sure — but this was all it took for me.

Putnam 1995

Let S be a set of real numbers such that S is closed under multiplication (that is, if a and b are in S, then so is ab). Let T and U be disjoint subsets of S whose union is S. Given that the product of any three (not necessarily distinct) elements of T is in T and that the product of any three elements of U is in U, show that at least one of the two subsets T, U is closed under multiplication.

Proof (by contradiction).
Suppose neither U nor T is closed under multiplication.

Then there exist u, w ∈ U s.t. uw ∉ U. So uw ∈ T.

Similarly, there exist s, t s.t. st ∉ T. So st ∈ U.

So the product uw(st) ∈ U, and st(uw) ∈ T, which has that U∩T ≠ ∅. This is a contradiction of the assumption that U, T are disjoint.

Therefore, at least one of U, T is closed under multiplication.

Extension

Note that the problem statement can be generalized from “S, a set of real numbers,” to G, any Abelian group. In particular, the mechanics of my solution are general enough to show the following result:

Let G be an Abelian group and let A, B be two disjoint subsets of G s.t. A∩B = ∅, and A∪B = G. Given that the product of any three elements in A is in A, and that the product of any three elements in B is in B, show that at least one of A, B is a subgroup of G.

Well, yes, that is a more general proposition as it is not limited to the real numbers and it’s usual “multiplication,” but mostly, it’s just a hell of a lot snootier. The word “Abelian” just means that multiplication is commutative. It sounds a lot more sophisticated, though, doesn’t it? O, that Algebra!

Example with G ={ i^k | 0 < k ≤ 4 }

Is that true, though? Let’s try it for the group G = { i, -1, -i, 1 } (where i is the imaginary number defined by i² = -1. Pardon the typeface.)

Let A = { i, -1 }, and let B = { -i, 1 }.

(-1)i = -i ∈ B, so A is not closed.

(-i)(1) = -i ∈ B, and
(-i)(-i) = 1 ∈ B, and yes, too,
(1)(1) ∈ B, so B is closed.

Seems to work out in this example, anyway.

Assuming that you have a fully functional wireless setup, and that you have NetworkManager 0.7+, you can also use the GUI interface to configure your wireless. This method has two benefits.

1. You can maintain roaming capability to other networks.
2. It’s less complicated to setup

Lehigh Wireless with NetworkManager

Click on the NetworkManager applet icon on your taskbar. Locate lu, and click it. For “Wireless Security,” choose Dynamic WEP (802.1x). This will create several new fields in the dialog box. For Authentication, select Protected EAP (PEAP). This, too, will add a few fields to the dialog box. Change PEAP Version to Version 0. Type in Lehigh user ID and login password in the fields labeled “User Name” and “Password.” At this point, the dialog box should be filled in like this:

Click “Connect,” and then “Ignore” the Certificate Authority dialog, and you should be on your way.

However, say you have a few different machines on a local network that you switch between freely, and have trouble remembering where you are. After accidentally installing a test-release version of Rhythmbox to my server and then spending about ten minutes back tracing, I decided it was time to do something. I could not easily tell which system I was on, and this would eventually lead to much more serious mistakes on my end. (I like to issue rm -rf /* on my laptop all the time, obviously.)

So, I set up color prompts on my server and laptop to help give me a visual cue as to where I am at a given time. The following line in .bashrc makes the host name appear teal, and keeps everything else without color:

export PS1='\u@\[\033[01;34m\]\h\[\033[00m\]:\w\$ '

And you thought CD-ROMs and traditional disk drives were bad enough! It gets worse. I usually never use a printer for economic, environmental, and philosophical reasons. Paper and ink cost money, and printers are big and ugly. On the environmental side, clearly burning through reams of paper is a bad call, as is the entire messy world of ink / toner. Why you wouldn’t just (with the least sophistication) send a PDF is nearly beyond me. Printers are at a level of technology below electromechanical computing, and are contrary to our primary endeavors to increase speed and minimize power (in all walks of life.)

Anyway, sometimes someone asks you for a hard copy of something. This happened to me, and so I had to setup a printer. Printing is free for students at Lehigh, and there is a printer in nearly every building, so at least my economic complaint gets pushed back a few levels to the Bursar, who gets lots of my money, albeit not sacred pocket money.

So, steps to setup a printer at Lehigh with Linux:

1. Go to lehigh.edu/printers and proceed with the steps to “install” a printer like you would if you were running Mac OS X.
2. Save the install.applescript.
3. Make note of the hostname of the printer you’re trying to install. You can get this by running

   cat install.applescript  | grep DNS= | sed 's/DNS=//'

4. Once you have cupsd installed and running, go to localhost:631, the CUPS configuration interface.
5. Go to Administration > Add Printer. Everything from here on is fairly intuitive. Just make sure you select “Internet Printing Protocol” from the drop down “Device” list, and when it asks you for the device URI, enter http://the-hostname-you-got-from-above.

That’s about it. Happy printing.