「 android 」一覧

Nexus5 & iPhone5s購入

ドコモのGalaxy Nexus、SC-04Dを入手してから1年半ちょっと。

GalaxyNexusはkitkatに公式に対応しないことと、使っているアプリのメモリ使用量が多くなってメモリ不足のせいか、ホーム画面に戻るときにもホームアプリがリロードするようになってきたので新しいAndroid端末を買うことにした。

基本、電話はiPhoneなのでAndroid携帯はデータ通信さえできればOK。Google純正機種ならAndroidのバージョンの追従も早いし、あと携帯では動画などの重いコンテンツを見ることは無いので最近良く出ているMVNOの格安SIMと組み合わせて使えば、月々の通信費も4000円近く抑えられそうな感じだったのでGooglePlayでNexus5をポチった。

格安SIMはネットを見てる感じだと最近の王道らしい、BIC SIM(IIJ mio)。福岡天神のビックカメラに行ってSMS対応版を普通に買えた。

Nexus5はさすがにサクサク動いて快適。LTEも使えるようになったので外でも快適になったのは嬉しいところ。

iPhone5sは、今まで使っていたのがiPhone3Gsでかれこれ4年近く使って来て本当はiPhone6まで待とうかとも思ったけれど、まぁ電池もヘタっているしiOSも5のままだし、端末代の割賦はとっくの昔に完了しているしNexus5を買ったついでにこっちも機種変するかと。

正直なところを言うとiPhone4以降、ワクワクを感じるiPhoneが出てこず来年出るであろうiPhone6なら…?という期待をしていたのだけど、なんだか今のアップルだとiPhone6も順当進化くらいになるかなと予想して今のタイミングで機種変することに。

今回もSoftbankのオンラインショップで手続き。店頭だと余計なオプションの勧誘とか説明聞いたりが面倒なので…。

スペースグレイの16GBモデルに機種変。あまり大きなデータを入れる予定も無いので。

今までiPhoneは通話メインで、ネット見たりはAndroid携帯をメインで使っていたのでiOSの操作、特にiOS7の操作感になかなか慣れなかったり。特に戻るボタンが画面の上のほうにあると、ちょっと押しにくいように感じる。Androidだと下側にあるので親指ですぐに押せるのだけど…。

スクロールのヌルヌル感や見た目のスムーズさはiPhoneのほうがきれいかなと思うけれど、普段使いになるとそれほど気にならなくなるのかも。

とりあえず年末のタイミングで携帯を2台とも機種変して気分転換、と。


FlickrのOAuthで認証サイトにリダイレクトする際にはpermsパラメータが必要

この連休にFlickrのOAuth周りを触っていてハマったこと。

FlickrでOAuthのユーザー認証をする場合、Request Tokenの取得後にFlickrの認証ページにリダイレクトするのが流れだと思うのだけど、FlickrへリダイレクトするURLにパラメータを追加でしていしないとユーザー情報を入力しても”Oops! Flickr doesn’t recognise the permission set.”というメッセージが表示され、認証エラーになってしまう。

Flickr公式のドキュメント(http://www.flickr.com/services/api/auth.oauth.html)だと、サイトに飛ばすときは

http://www.flickr.com/services/oauth/authorize?oauth_token=72157626737672178-022bbd2f4c2f3432

のようなoauth_tokenのみがクエリに付ければいいとなっているけど、実際は”perms”パラメータもつけないとうまく動作しない。

Additionally, you can pass the optional perms= parameter, asking for read, write, or delete privileges. This parameter will override the setting defined in your application’s authentication flow.

サイトの説明にはoptionalとなっているので、指定しなければデフォルト(readのみ)になってくれるかと思っていたのだけど、違うようだ。

http://www.flickr.com/services/oauth/authorize?oauth_token=72157626737672178-022bbd2f4c2f3432&perms=read

↑この形が正解。

OAuthにsignpostのライブラリを使っている場合は、OAuthProvider#retrieveRequestToken()で返るリダイレクトURLに自分でpermsパラメータを付ける。

(参考)http://www.flickr.com/groups/api/discuss/72157626891119797/#comment72157627007728025


Nexus7購入

Nexus7を買いました。

DSCN0997

発売日の25日の出勤前に注文がすでにできるのを知って即注文完了。それから届いたのは27日の夕方だったのだけど、仕事で不在だったので土曜の午前配達で受け取り。Fedexの再配達はトラブルがあるとかネットで見ていたのだけど、土曜日の再配達は日通航空が時間通りに持って来て特にトラブルらしきものは無し。再配達の依頼でFedexに電話したときも「その荷物には担当者がいますので折り返し連絡します」と言われたので、今回のGoogleの発売に合わせてFedex側も何か準備していたのかも。

Androidタブレットは、ここ刈谷にも以前買ったAcer A500を持って来ているのだけどA500は公式には4.xへのアップデートも提供されず終わってしまったデバイスなので、やっぱりAndroidの最新バージョンを使ってみたいという思いが。

Nexus7を手に取ると、小さい。そして重さも動作も軽い。サクサク動いてストレスをほとんど感じない。

重さが軽いのがとてもいい。タブレットは主にベッドで寝転がっているときに使ったりするのだけど、A500は重くてずっと持っていると疲れてしまう。10インチの良さはあるけれど、Nexus7の軽さを体験するとこっちでもいいかなという気分になる。

これで2万円なら開発デバイス、動画見る用とか用途は広いから、けっこうお買い得かも…。


組み込みの現場でRTOSベースの既存システムをAndroidに移植しようとした時にありがちなこと

今の仕事は、いちおうAndroidをプラットフォームにした仕事ではあるのだけど、もともと組み込みのRTOSベースのシステムを移植するようなプロジェクトでシステムのアーキテクチャはAndroidというより”組み込み”の考え方。過去「スマートフォン開発もやっぱりデスマか」でも書いたのに似ていて以下のような感じ。

  • 他社から出てくるモジュールのJavaレイヤのI/FがC(Native)レイヤの関数をそのままラップしている
  • RTOSアーキ時代のタスクがそのままAndroidのSerivceになってる
  • Service間やActivityの間でやたらと非同期の呼出しや通知が多い
  • RTOS時代はこの方式で上手くいってたので、と押し切られる

他社から出てくるモジュールのJavaレイヤのI/FがC(Native)レイヤの関数をそのままラップしている

例えばJavaレイヤに、int xxxFunc(byte[] data) のようなI/Fが提供されて、引数byte[]に自分でバイナリデータを組み立てて(しかもビット単位で)呼び出さないといけない。nバイト目のn~mビット目にはxxを指定する、のような。

システム内で広く使われる予定のコアなモジュールの割にはI/Fが不親切。既存のNativeライブラリがそういうI/Fだからということらしいが、ヘルパーメソッドくらい用意すべきと思う。

こういうケースは、

  • 担当者がAndroid(というかJava)の経験が浅いか無い
  • 単に期間的、工数的に楽になる実装にしたかった(ラップするだけだものね)

であることが多いように思う。

でもそのI/Fの使用者がシステム内の各所にいるような重要なモジュールなら多少はヘルパーなり呼び出しやすいI/Fで提供して欲しいところなのだが、要請しても必要性が分からないとか「今までのシステム(RTOS)はこうだったから」と言われてお終い。

経験上、こういうひどいI/Fを出して来るときの一番多い言い訳が「呼び出し側の実装の自由度を考えた」というのだけど、いちいち引数組み立てたりしないといけない実装を各モジュールで作らせるのが自由度とは思わないけどもね。

こういうひどい設計は、上手く呼び出し側の他社も巻き込んで「使いにくいから考え直せ」と攻めてみるのが筋だろうけども…。

RTOSアーキ時代のタスクがそのままAndroidのSerivceになってる

xxxxTask -> xxxxServiceに名前が変わって再実装。

モジュール分割がRTOSと同じ感覚でちょっと細かすぎやしないだろうか、というケース。AndroidのServiceが乱立するのもね。RTOS時代から関わってる人には同じ感覚で仕事できるからいいのかもしれないけど。

Service間やActivityの間でやたらと非同期の呼出しや通知が多い

RTOSのタスク間メッセージと同じ感覚でI/F設計してしまうから。

→”xx要求”
←”xx受付通知”(相手側が受け付けましたという非同期通知)
←”xx応答”(相手の処理が完了して結果が乗ってくる通知)
でワンセットになってたりするケース。

応答を受けるまでは次の要求を投げてもエラーになります、キューイングはしないので呼び出し側で管理してください、が割合多い。

確かに、ハードウェアまでアクセスするために応答時間が数100msかかる可能性があるので非同期処理、というのは組み込みでは多い。

RTOSならセマフォやシグナルとか駆使して実装するのがセオリーだろうけど、Androidだとメインスレッドはブロックできないし、I/Fを使う側としては呼び出しと応答後の続きの処理がソースコード内の離れたところになってしまう。なのでソースコードを見たときに処理が見通しにくい。

多少、ブロッキングするメソッドであっても同期型でI/Fを用意してもらって、使う側でスレッド立ててその中で呼び出すなりできるけどなぁとは思うけれど正解がよく分からない。

ただ、コールバックやスレッドを上手く設計しておかないと後からバグだらけの懸念。内部の状態管理もきちんとしないといけないだろうし。

RTOS時代はこの方式で上手くいってたので、と押し切られる

…今回のプラットフォームはAndroidなんですけど…?

開発メンバーにRTOS時代からずっと関わってる人が多いと、「今までのやりかたが最強」ということになりがち。上に書いてるように、モジュール構成とかI/Fの考え方を既存のRTOSでのシステムからそっくり持ってくるからってことなんだろうけど。

でもAndroidのアーキテクチャと合わない設計をして無理やり作り込んで後で火を噴かなければいいけども…。ActivityとかServiceのライフサイクルは考え方としてそれなりに特殊だし、Android Frameworkとの兼ね合いもどう付けるのか…。たぶん火を噴いた時にはさらにパッチ的な回避をしてどんどん複雑化していくのだろうな。

こういう感じのシステムだと

もはや作っているものはAndroidというよりRTOSの仕事をしているのと大差が無くなってしまっている。よく分からないxx管理タスクと先にやりとりしないとアプリの起動ができないとか、シーケンスを引いていくとアプリ層やService層でやたらとあちこちの”タスク”に対して複雑なシーケンスをこなさないと処理が進まない仕組みに。

いろいろ改善を試みて一部はとりあってもらったものもあるけど、もう既に各社で設計が進んでしまっててひっくり返すには遅すぎるし、プロジェクト内のパワーバランス的にこちら側の力が足りない。

たぶんこれは結合試験以降の工程で大変なことになりそうだ…。

1つの処理に対してシーケンスが多いからユーザ目線でのレスポンシビリティーが心配だとか、クロスシーケンスを各社どこまで事前にケアできてるかとか(下位レイヤは単なるラッパーレベルでしか作ってこないだろうから期待薄)、どこかにしわ寄せが来そうな気がする。

携帯電話開発の現場でも、ガラケーからAndroidスマホに開発がシフトしていく時に通った道ではあるけど、これからAndroidの採用が見込まれている色んなデバイスの開発現場は「Androidでの初物」の開発では同じ道を通っていくのだろうか。

せっかくAndroid経験のあるメンバーを投入しても、もう少しアーキテクチャや設計の考え方には、既存システムの開発に長けていて自負があったとしても耳を傾けたほうが良いと思う。数年前と違ってAndroidのエンジニアは大きく増えているしAndroidのノウハウを持った人間もたくさんいるのに、その意見を頭から潰していたら良い物はできないと思う。

既存のRTOSの資産やノウハウを流用するとしてもAndroidに載せたときにどうするのが良いのか折衷案は出せると思うし、あとあと火を噴かないために注意すべきこととかは上流工程で検討しておくのが良いはずだけど。

往々にして開発スケジュールに余裕が無いからなどの理由で既存をベースに流用すればなんとかいけるだろう、というのはどこでもある話だけれども、それで進めると設計、実装、単体テストあたりまでは一見うまくいく。けど、各モジュールを結合していくとシーケンスの不備、Android特有の動作、動いてもモッサリ、メモリ食い、Low Memory Killerで殺される現象などにきっと泣くことになる…と思うなぁ。


Galaxy NexusとArduino MEGA ADKをArduino1.0環境で接続する

特に珍しいことは何も無く、単にADKのサンプルアプリが動くところまでを確認しただけだけど。

DSCN0605

先代のGalaxy Sが2.3.4カスタムROMにアップデートしてもADKサポートせず、Android3.xデバイスとして買ったAcer ICONIA TAB A500も結局ADKサポート無しという悲しい状態で、買ってあったArduino MEGA ADKだけが浮いていたのだけども、ようやく日の目を見ることができたと言うべきか。

Arduino周りの環境構築は、Arduino1.0になってArduino側ライブラリのAPI定義などが変更になった関係などで、GoogleのADKページ

http://developer.android.com/guide/topics/usb/adk.html#getting-started / Android Open Accessory Development Kit | Android Developers

を見るより、ArduinoのMEGA ADKのページに書かかれている方法のとおりにするほうが良い。変にハマらなくて済む。

http://labs.arduino.cc/ADK/AccessoryMode / Arduino Labs – Accessory Mode browse

ポイントは、Arduino1.0のフォルダにライブラリとしてAndroidAccessoryとUSB_Host_Shieldを入れる必要があるのだが、それの入手元。Googleのサイトだと、Google提供のADKパッケージに含まれるAndroidAccessoryとUSB_Host_Shieldを使うように書かれているけど、Arduino1.0の場合はArduinoのサイトで配布されているアーカイブを使う、というところ。

3. Arduino 1.0 + Arduino Libraries

As with Processing, you need to run the IDE once to create your sketchbook folder. Once created, download this file. The two folders, “libraries” and “tools” need to be placed in your Arduino sketchbook folder.

“this file”とさらっと目立たないリンクになっているけど、ここからダウンロードできるアーカイブをArduino1.0のフォルダにコピーすること。これですんなり認識する。

ADKやAndroid側アプリの作り方については、以下のgclueさんのサイトの解説がとても解りやすくてオススメ。

ちなみに、gclueさんのサイトの”ADKの開発環境の構築”に書かれている「ソースコードの修正」は、Arduinoのサイトでは既に修正済みのライブラリがダウンロードされるようなのでこの手順は必要無くなっている。

ADKの開発環境の構築 – IoT Docs
ADKのライフサイクル – IoT Docs
Androidアプリの作成 – IoT Docs


UbuntuにOracle (Sun) Java 6 SDKをインストールする

AOSPのソースビルドなどのために、UbuntuにOracle(Sun)のJava6環境が必要なケースはあると思うのだけども、ここ数ヶ月くらいの間にUbuntuリポジトリから削除されてしまってるとのこと。

なので、AOSPのサイトに書かれている以下の方法も今では「パッケージが見つかりません」みたいなエラーになって使えないと。

$ sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner"
$ sudo apt-get update
$ sudo apt-get install sun-java6-jdk

で、これを回避しようとググってみるとPPAで有志が独自に公開してるaptリポジトリを追加してそこからインストールするとか、aptを使わずにOracleサイトからパッケージ落としてきてインストールするなどあるらしい。

お手軽なのはPPAリポジトリ形式で、これはppa:ferramrobertoを使うサンプルを多く見かける。

$ sudo apt-get install python-software-properties
$ sudo add-apt-repository ppa:ferramroberto/java
$ sudo apt-get update
$ sudo apt-get install sun-java6-jdk sun-java6-plugin

ただし正確にはOracle(Java?)のライセンスや著作権的にppaで独自にパッケージ配布するのはNGなようなのでこの方式はグレー(実際にはきちんとインストールできるし、動作は問題無いけど)。

かといって、いちばん真っ当な手順と思われるOracleサイトからダウンロードしてインストールする方式だと、インストールした後の環境設定が少し面倒。

Ubuntu公式のドキュメントでJava6の項を見てみると、

Java – Community Ubuntu Documentation

ppa:ferramrobertoを公開していた人がライセンス・著作権問題をクリアにした形でインストールできるスクリプトを作って公開していた。

flexiondotorg/oab-java6 · GitHub

Downloads the Java binary installers from Oracle, builds the .deb packages locally on your computer and then installs them. Packages are compatible with the “official” Ubuntu ones and will upgrade Java 6 that was previously installed from packages.

・Oracleサイトからのバイナリパッケージダウンロード
・.debファイル化
・ローカルのaptリポジトリとして構築

までを自動で行うスクリプトのようだ。JDKのバイナリをOracleサイトからきちんとダウンロードすることで諸問題を回避しているぽい。

githubのreadmeに書かれているとおりにスクリプトをダウンロードして実行する。

cd ~/
wget https://github.com/flexiondotorg/oab-java6/raw/0.2.0/oab-java6.sh -O oab-java6.sh
chmod +x oab-java6.sh
sudo ./oab-java6.sh

すると、

oab-java6.sh v0.1.9 - Create a local 'apt' repository for Ubuntu Java packages.
Copyright (c) Martin Wimpress, http://flexion.org. MIT License

By running this script to download Java you acknowledge that you have
read and accepted the terms of the Oracle end user license agreement.

* http://www.oracle.com/technetwork/java/javase/terms/license/

If you want to see what this is script is doing while it is running then execute
the following from another shell:

  tail -f /home/findup/oab-java6.sh.log

Downloading common.sh
 [x] Installing Java build requirements success
 [x] Making build directories success
 [x] Removing clones of https://github.com/rraptorr/sun-java6 success
 [x] Cloning https://github.com/rraptorr/sun-java6 success
 [x] Checking out v6.31-2 success
 [x] Getting Java SE download pagesuccess
 [x] Getting current release download page success
 [x] Downloading jdk-6u31-linux-i586.bin : 81.34 MB success
 [x] Symlinking jdk-6u31-linux-i586.bin success
 [x] Downloading jdk-6u31-linux-x64.bin : 81.62 MB success
 [x] Symlinking jdk-6u31-linux-x64.bin success
 [x] Updating the changelog success
 [x] Building the packages success
 [x] Moving the packages success
 [x] Creating Packages.gz file success
 [x] Creating Release file success
 [x] Signing the 'Release' file success
 [x] Exporting public key success
 [x] Adding public key success
 [x] Update package list success
All done!

っという感じでダウンロードとローカルなaptリポジトリを設定するところまで行ってくれる。あとはいつものように

$ sudo apt-get update
$ sudo apt-get install sun-java6-jdk

とやればJava6 SDKがインストールできる。

Java6 SDKの最近のインストール方法はいろいろあるけど、こういう方法もあるよ、ということで。

まぁ個人的にはAOSPビルドにしか使わないので、AOSPがOpenJDKに対応してくれるほうが良いかなぁとは思うけど。


早起き

作業場所が百道になってから、通勤時間が3倍になり睡眠時間が1時間減った。

フレックス出勤ができなくなったのが辛いところ。前日遅くまで仕事して帰っても朝は定時だし、サラリーマンとして普通なのかもしれないけど、家に帰っても自由時間ががほとんど無くなった。

これで休日出勤も朝定時出勤が必須だと体力がなぁ。

でも毎日深夜まで仕事して、次の日の朝8時半くらいに普通に出社している人も多いのよねぇ。メーカー系の会社は8時半始業だったりするし。どんな生活リズムと体力があればやれるんだろ。…そんなに仕事したくはないけれど。

とりあえず仕事は長年やっていた携帯電話系の分野から離れました。ただ新しい仕事もAndroid。何作ってるかは書けないけれど。

今度はAndroidでもアプリではなくて下位レイヤが中心になりそう。割り込みやら排他制御やら、チップの電源管理やらの話が飛び交っていて、なんだかAndroid、という仕事じゃ無い感じが強いのだけども。まだまだ要件とかプロジェクトの状況やインプット資料の整理が頭の中でできてなく、どうやって作業していくかのイメージがはっきりと沸いてない。

ただまぁAndroidの中身をあちこち調べて手を入れていくような仕事になりそうなので、Androidの中身を大解剖、というようなことはしないといけなさそう。そう簡単に行かないことは過去ソースを読んでて分かってるので、苦労する仕事になるだろうなぁ。

さて、6時起きなので寝ないと…。


ドコモのGalaxy Nexusを入手

ドコモの投げ売りに乗っかって、新規契約で入手。

DSCN0479

今までAndroidはGalaxy Sメインで使ってきたけど、1年と9ヶ月経った間にAndroidデバイスの進化はすごいね、サクサク感は雲泥の差。解像度が大きいのと、インチ数が大きいのがとても見やすくていい感じ。

ただサクサクはするんだけど、ちょっとだけ動きが引っかかることもあるので、4.0はけっこう重いのかも。あとバッテリーの持ちは良くないね。外出時はWifiをoffにしていても1日持たない感じ。

当面はFOMA契約でデータ通信も使うつもり。メインにしてる端末がiPhone 3GSなので、画面の綺麗さとサクサク感、通信の速さ的にGalaxy Nexusが(当然ながら)勝ってるな…。

とりあえずは普段使いもしつつ、開発用にも使いつつ。4.0かつNFCが使えるので、まずは4.0系のアプリの作り方を勉強しつつNFCとか色々使ったアプリを作ってみたい。

Galaxy Sは2.3系のテスト端末として余生を。Galaxy Sも買った時はすごくサクサクしてた覚えがあったんだけど、今はけっこうもっさりが目立つ感じで、それぞれのアプリが重くなる傾向にあるのか2.2から2.3が重くなってるのか色々あるんだろうけど。


Android SDKにFramework部のソースがダウンロードできるようになっていた

いつの頃からか、Android SDKでFramework部分のソースがダウンロードできるようになってたのね。気づいてなかった。

わざわざAOSP経由でrepo syncして来なくても(Linux必要ないし)、ちょっとFramework側の実装を確認したいときには良いかも。たぶん、Eclipseにソースフォルダとして設定すればデバッグもできそうな気がする。

今のところ4.x系のみっぽいけど、2.3もあるといいんじゃないかなぁ。

(追記)ちなみにソースコードは、android-sdk\sources\android-15 というようなフォルダにある

Android_Sdk_Source


Android2.3互換指定にしていても、2.3と4.0でPreferenceActivityの見た目が異なる

2.3(Gingerbread)ベースで作ったアプリを修正せずに4.0で動かすとき、AndroidManifest.xmlにtargetSdkVersionやmaxSdkVersionを”10″にしておけば、下位互換で2.3までと同じ見た目(テーマ)で表示されると思っていたのだけど、PreferenceActivityに関しては少し見た目が異なるようだ。

↓は2.3(Gingerbread/GB)での表示。ListView部分は画面幅いっぱいに表示されてる。
device-2012-03-18-010735

↓は4.0(Ice cream sandwich/ICS)での表示。
device-2012-03-18-010651

なぜか4.0だとListView部分が画面の真ん中に縮小したような感じで表示されてしまう。

どうもこれには条件があるようで、
・横画面
・横画面にしたときの画面解像度幅が1280px以上(上記の場合は1280×720)
の時らしい。

大画面タブレット向けのレイアウトになってるのかな?とも思わなくもないのだが、manifestでSdkVersionを10にしているので、2.3と同じように表示して欲しいところ。2.3ベースで作ったアプリを、特に4.0に特化した修正をせずに(fragment使ったり)そのまま載せたいケースもあると思うのだけど、こういう風に挙動が少し異なると厄介。

まぁ、このせいで仕事でバグ票切られてて(同じはずなのに見た目が違う)どうしよう…って話なんだけど。


スポンサーリンク