Android Bits

Activity creates Intent for Service and can insert ResultReceiver as Extra.

But what if Activity is stopped before result sent to RR?

Better to use LocalBroadcastManager

I have multiple apps using a service that is defined in a common SDK. So adding the service in each app's manifest uses the same package name.

This is fine because by default the interface to the service is not exported:

After coding up some sample implementation I realize that the instructions for Cross-client Identity are actually two slightly different flows.

Both involve the Google auth server and your two clients, the Android app and the web app. The Android app is retrieving a piece of information from Google and forwarding it to the web app.

This will cause crash on orientation change on 4.2 and lower:

getWindow().requestFeature(Window.FEATURE_NO_TITLE);

instead use

Great for semi-automated testing:

From http://developer.android.com/google/play-services/setup.html

Make a copy of the Google Play services library project.

Note: If you are using Android Studio, skip this step.

Copy the library project at /extras/google/google_play_services/libproject/google-play-services_lib/ to the location where you maintain your Android app projects.

When using GoogleApiClient for the first time you will probably see the following logcat error:

GLSActivity(1108): [apc] Status from wire: INVALID_CLIENT_ID status: null GLSUser(1108): GLS error: INVALID_CLIENT_ID [email protected] oauth2:https://www.googleapis.com/auth/plus.login

Solution

Getting started with Google+ integration:

http://square.github.io/retrofit/

Manages the HTTP client

Marshals POJOs back and forth from JSON

Pre-4.4 KitKat there is a bug in MediaCodec ACodec.cpp that causes an native assertion when there is a stream change that causes internal port reconfiguration. One such change is a resolution change ie in H.264 SPS/PPS parameters.

This means the MediaCodec object needs to undergo teardown and re-setup, ie

mCodec.stop mCodec.release mCodec = MediaCodec.createDecoderBy... mCodec.configure mCodec.start

The trigger for this is to know when a resolution change is going to happen in the stream before the ES buffer is queued to the input. Therefore, the H.264 ES data needs to pre-parsed to examine SPS/PPS to detect the resolution change.

A client retrieves a decoded output frame by calling MediaCodec.html.dequeueOutputBuffer. However, the ByteBuffer referred to may be null, empty or in a chipset-specific output format (see Andy McFadden's answer here).

So what if you need to examine the bytes of the decompressed frame, i.e. for a unit test? The answer lies in Andy McFadden's EncodecDecodeTest.java.

The frame needs to be rendered to a Surface (via MediaCodec.releaseOutputBuffer).

ndk-build -j