ActionBarActivityからActivityへ

互換性の問題からActivityではなくサポートライブラリに含まれるActionBarActivityを使ったほうがいいのかもしれないと使ってみましたが、あまり関係はなさそう。
旧バージョンでもv21以上のマテリアルデザインっぽい部分が再現される部分もありますが、正直微妙。
いろいろなところでも書かれているので自分メモです(笑)
MainActivity.java

import android.support.v7.app.ActionBarActivity;
→削除
import android.app.Activity;
→自動で追加させる。

public class MainActivity extends ActionBarActivity {
↓
public class MainActivity extends Activity {

styles.xml

<style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
↓
<style name="AppTheme" parent="@android:style/Theme.Holo.Light">

 build.gradle(Module: app)

compile 'com.android.support:appcompat-v7:21.0.3'
→削除

menu_XXXX.xml (minSDKの設定により未対応の属性を削除)

<item android:id="@+id/action_settings" android:title="@string/action_settings"
        android:orderInCategory="100" app:showAsAction="never" />
↓app:showAsActionを削除
<item android:id="@+id/action_settings" android:title="@string/action_settings"
        android:orderInCategory="100" />

もともとアクションバーも必要の無いアプリだったのでいっそのことサポートライブラリごと切ってしまったら軽くなるんじゃないかと思ってやってみました。

実際やってみるとapkパッケージサイズはソースコードに見合った大きさになったと思います。
実行時のメモリサイズは10M程度でしたけど、まぁ仕方の無い部分かな？

実際にapkをアップロードして気がついたのですが、サポートライブラリを含めたパッケージは全言語対応という形になっていました。おそらくサポートライブラリ内で言語毎にリソースを振り分けているものがあって、それが全言語に渡っているという事でしょうね。

こんな邪魔なライブラリがさまざまなアプリに重複してると思うと正直げんなりします。
昔Windowsのランタイムライブラリを静的にリンクさせておいたほうが実行ファイルが一つになるしバージョン管理も楽になるからと個人的に気に入っていたのですが、やはり共通部分は動的にリンクさせてそれぞれの実行ファイルで共通部分を重複して保持するのはもったいないとする流れのほうが強いのですが、実際問題としては至るところでDLLの不一致による問題が多発していた気がします。MSCのランタイムライブラリですらいまだにバージョン不一致によってよく落ちるプログラムが多いです。特にカメラデバイスに付属しているようなアプリですけど。

Androidはそれを前提に静的なリンクしか行わない方向なのかな？
実際はAndroidバージョンがどんどん上がっているのでシステム的にはそれがランタイムライブラリという部分もありますが。

既存のAndroidアプリにMaterial Themeを適用する方法
R.style