たとえば本体がUSキーボードでBluetoothで日本語キーボードを使いたいとき

ずいぶん前にも同じようなことをやっていたが、ググると微妙にヒットしない。リンクを張れば有用なページが上がるかな？

Windows10で配列の異なる複数のキーボードを使う方法 https://www.opensourcetech.tokyo/entry/20200606/1591370282

昔にやったことは本体が日本語で外付けのキーボードがUSキーだった気がする。その時からBluetoothキーボードは配列が違っても設定さえ行えば大丈夫になっていた。上記のリンクは2020/06/06になっているが、過去に行ったのはもっと古い。基本的な考え方はUSB接続のものにも使えた気がする。

HIDキーボードのハードウェアインスタンスパスを見つけて、、とここで複数のHIDキーボードがあるとどれかわからないので、一旦Bluetoothキーボドの接続を切って、デバイスマネージャで非表示デバイスの表示を行うと結構一目瞭然だったりします。

解らない場合は、親のプロパティー値を見て辺りをつける必要が出てきます。

レジストリキー HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum ぐらいまで手で開いてHIDのデバイスのインスタンス パスのUUIDっぽい部分で文字列検索すればレジストリエディタですぐに見つかるはず。

必要なのはDevice Parametersに以下の値を追加すること。

KeyboardSubtypeOverride 2
KeyboardTypeOverride 7

USキーボードであれば

KeyboardSubtypeOverride 4
KeyboardTypeOverride 0

と設定する。基本的にbluetoothデバイスの初期化は接続時に行われるので、レジストリの設定を行えば再起動は不要。 

 

追記

現時点(2022/01/15)の状態のWindows10でProではうまく動作していますが、Homeでは再起動してもダメな模様。詳細は不明ですが、キーボードレイアウトは切り替わったので、単純にドライバが異なっているのかも？

自動的に公開されるアプリってなんなんだよ（怒

ドはまりしました。

ContentProviderでデータ共有しているアプリとそれを利用しているResolverで全くうまくいかなかった。

ここ数年正直Androidへの興味が正直失せていたのは事実なんですが、ここまでガードするかというほどガードされてました。まぁいいんですが。言いたいことはあるけどもキリがないですねぇ…。

と、今回ハマった経緯は、SDKレベル29か30で止めておくとそれなりにエミュレータ上のAndroid12でも動いてくれていた。が、targetSDKを31に上げると動作が怪しくなっていくという。よくあるパターン。Androidの方針としては従来のリソースはできる限りリソースが動作できるようにAndroid側でカバーして実行してくれるのですが、その指標としてビルド時のtartgetSDKレベルを使用しています。それでもダメとなるとバッサリ行かれちゃいますが、その辺は色々な人がかかわっているようで、流行やら何やらで色々変わっている印象を受けます。

とりあえず利用する側の調整が落ち着いたので、共有側に手を入れたのですが、Android11とか12だと全くうまくいかないという結果に。

エラーを見ても全くどういう状況下把握すらできず、ひたすらググるのみ。ただ、ほとんどの情報は枯れた過去のAndroidバージョンの話とかが大半でほしい情報がなかなか得られず、右往左往しました。その中でも興味深いと思ったのが、uriのcontent://com.hogehoge.provider/tableという記述の「content://」を取ったらうまくいったという記述。いやいやまさかｗと思いつつもやってみると実行時エラーの内容が変わっていって、しかも何となく内部で動いてくれているっぽいような記述に変わっているという。実際のソースを追いかければその辺も見えてきそうなんですが、SDKは定義体ぐらいしか見れないのでなんていうかね…ソースは公開されているという話だけど、未だ見たことがない。

そんなブラックボックステストをしつつ、必要そうな記述を追加したり外したり、入れ替えたりと。ですが、結局変わらず。

あきらめついでにバッテリーが膨らんで放置しているスマホの電源を入れて動作確認したりしながらいろいろと考えてみるが、わからんものはわからんという当たり前の話。

しかしながらググりまくってなんか面白いサイトがあって、そこのページを見ていると今まで見たことないAndroidManifestのキーワードが。

<queries>

なんかパッケージ名とか記述してるみたいだけどなんなんだろうと、さっそくデベロッパーズドキュメントへ。

Android 11 以降をターゲットとするアプリで、自動的に公開されるアプリ以外のアプリとの連携が必要な場合は、アプリのマニフェスト ファイルに <queries> 要素を追加します。

は？自動的に公開されるアプリ？何を言ってるかマジわからんが…。

ん～っと、もしかしてパッケージとかインテントとかそれなりに投げればそれなりに処理されていたのが、アプリ側からは相手がいないように見えるってことか？しかもそれがデフォルト？

いやなにそれｗ

はぁ…kitkatぐらいの時点でAndroidの変更点とか見るのが嫌になってるんですが、そこのつながりにこんなこと書いてあったっけか？？

と、ものすごい現状の動作の状況が納得いくので、期待して記述を追加してみました。

ちなみに、ContentProviderは基本的に何らかのpermissionを設定するように強制されているのか推奨されているのか不明な状態ですが、どっちにしてもandroid:protectionLevel="signature"が最低でも強要されると思われるので設定していたりします。リリース時はあれだけどデバッグ時はどうなんだろうと思って最初はリリースビルドを行ってエミュレータにファイルを入れてインストールしていたのですが、試しにそのまま実行したらうまくいきました。記憶をたどれば確かデバッグ用の認証キーでパッキングしているとかなんとか見かけた気がします。そのおかげでデバッグはそこまで面倒ではなさそう。

ただ、Android11はnormalでも動いた。12はどうだろう？→ダメでした。何らかの権限設定が必要で、ContentResolver単体で行おうとするとsignature以外に選択肢はなさそうです。

部屋の赤外線リモコンが挙動不審に

夜になってエアコンの電源を入れようとしたところ反応がない。

とうとうこのエアコンも壊れたか…と、緊急ボタンを押したところ動作はするので、電源を抜いたり本体の電源を入れ直したりしてみた。

初めはリモコンの電池を疑って電池を入れ替えてみたものの、変化なし。しかも電池残量は問題なさそうという。

スイッチの確認をするために高所にあるエアコンをスマホで撮影したところ埃が目立ったので清掃してみても変化なし。

そういえば照明のリモコンも反応が怪しい。

手持ちのスマホは赤外線フィルターが入っていないので撮影すると赤外線が光ったのが明確にわかるので、レンズ越しに覗いてみると若干暗くなってるかな？という程度だったのですが、こちらも電池を取り換えてみる。が、電池残量も問題なさそう。ただ少しだけ反応は良くなった感じがする。

照明のカバーや受光部分の清掃も行ってみる。２回目に外したところなんかカバーの縁が少し割れた…orz

照明は電池交換と清掃作業で反応はするようになった。が、なんか微妙。真下だと反応するけど今までのような反応の良さは無し。太陽光もないのでノイズもなさそうだし、まさか赤外線照射でも外部から受けているのか！？とかよくわからん事が頭をよぎるものの嫌がらせで赤の他人の家に照射するとかそんな暇な奴はいないとおもうｗ いや…地味だけど結構嫌かもｗ カーテンで簡単に防げそうだけど。

問題のエアコンは結局反応がない。赤外線受光センサーはRaspberry piのために結構手持ちにあるので部品が合いそうならすぐに交換できると思いつつも、この時間から取り外してとか面倒なので明日行おうとあきらめた。

が、やっぱり気になるのでエアコンのカバーを開けて、リモコンを受光部分から５ｃｍ程度の距離でつかってみると、電源が入る！！

ちょっと感動したものの、双方向通信である現在温度の確認はできず。もしかして本体側の赤外線ＬＥＤが壊れた？とか思ったものの…そもそも論としてＬＥＤとかって壊れるときは基板上のほかの部分が壊れているはず。しかもこんな距離を変えたからと言って反応することなんてまずない。物理的な汚れや埃で光がとおらなければ別ですが、そこまでさえぎるような状況には突然ならない。

なので、ただ部品が壊れたとはおもえず…とはいえエアコンが反応してくれたので寝ることに。

翌日、午後にでも部屋を暖めてから作業するかと思っていたところ、AmazonのFirestickのリモコンのLEDがかなりゆっくりと赤い点滅を繰り返している。あーこいつも電池切れか？と電池を交換。でも電池残量はまだあるんだが。

赤点滅ってなんだろうな？と、色々調べてみるたが、あまりそれといったのが見つからず。

最近Firestickリモコンが青色を点灯したままになってたことがあったが、それも気になってはいた。その時、音声ボタンを押したあと、ちゃんとFirestickは反応してリモコンの青点灯は消えたと思う。まぁなんか押しちゃったのかな？程度に軽く考えてたが、この時も何かあったのかも？

オレンジ色の点滅とか、赤と違うのか？とか気になるもののまぁあきらめ。最悪Amazonの取説的な何かが引っかかればよかったのだが、引っかかったのは怪しいサイトの偽ウィルス系のページでした。あんまり闇雲にページ開くのは危険。

で、ふと照明の電源をリモコン操作したところ…反応がいい感じ。あれ？普通に戻った？部屋の中どこ向けてもちゃんと反応する！！

エアコンのリモコンも押してみる。

エアコン「ピッ！」

まじかｗちゃんと反応する！温度もちゃんと表示される！

くっそぉー。そういえばFirestickのリモコンって無駄に赤外線LEDも搭載してるんだったっけか…と思い出した。そういえばほかの場所で照明のリモコンの反応がものすごく悪かった時があったが、その時もFirestickのリモコンがあった気がする。

すっげぇ納得いったけど、脱力ｗ

無駄でも部屋を真っ暗にして部屋全体をカメラで見渡してみればよかったなぁと今更ながらに感じたものの、エアコンとか照明とか壊れてなくてよかったと喜ぶべきなのだろう。

七転八倒

いつもタイトル通りのような気がしますが、一時期まともにビルドできなかったAndroidStudio（DEV版ですが）がようやくまともにビルドできるようになった感じなので使用しているアプリから順にビルドし直していたりします。

Googleさんからちょくちょくとポリシー変更なりなんなりのメールが来てはいたのですが、先日、軒並み公開中のアプリがストアから削除されたという報告メールが多数送られてくるという事態に。

きっかけと思われるのは、あるアプリのレビューがとてつもなく幼稚なレビューが書き込まれることが目についたので、対象年齢を１８歳以上としたことが原因なんだと思います。

ほかのアプリは特に対象年齢は指定していなかったのですが、おそらく中の人かAIがほかのアプリも対象年齢をごまかしているに違いないという憶測で一気にストア上から排除したんだと思います。

基本的にレビューに対して直接返信することはしないようにしていたりします。理由は単純でうまく意思の疎通が取れるとは思えないからということ。ですが、結構レビューはちゃんと見てたりします。全く知らない言語で書かれていても翻訳してなんとか意味を汲み取ったりしていますが、言葉の壁は厚いｗ

しかしながら、どうしょもないようなレビューで★☆☆☆☆とか連発されると慣れたとはいえ精神衛生上よろしくないので、なにか対抗手段はないものかと思いついたのが年齢制限。意味はなさそうですが（笑）

そんなこともあり、リビルドせにゃいかんと思ってはいたので時間ができたときに気を改めてAndroidStudioのアップデートを行ったところリリース版ではうまくゆかず。新規プロジェクトを作っても一回目のビルドは通るのに二回目から失敗するとか意味わからん。

直接的な原因はgradleのテンポラリだかキャッシュだかのフォルダを手で削除すればビルドは通った（メッセージを見るとどうもマージがうまくできていないようでした）のですが、なんか気持ち悪すぎるのであきらめてDEV版を使って試したところ、ようやくまともにビルドが通るようになりました。なんていうか、AndroidStudioのビルド動作ってgradleのバージョンが上がりすぎてついていけてない感じになっててかなり面倒なんですよね。

ビルドが通るようになったので、gradleの書き換えやらリポジトリ変更に伴う書き換えやら、SDKのバージョンアップに伴うライブラリやアーティファクトの書き換えやらを半ば機械的に行いながら作業を行っていました。

そして地道に作業を進めていたのですが、ここ数日でドはまりしていたのがSSID Widgetです。とりあえずSDK31でビルドが通るようにしようとしていたのですが、ビルド後の動作がうまく動かず何が原因かわからず丸２日ほど途方に暮れ、仕方なしにSDKバージョンを下げて動作するかどうか確かめることにしました。

ちなみに手元にあるデバイスはAndroid10なのでSDKは29です。

Wifiの扱い方が大きく変わるのがSDK31からっぽいのですが、それまでにも権限周りの扱い方がSDK26(Oreo)から変わっていてかなり面倒になってはいました。その後は、そんな変わっていないだろうと見ない振りをしていました。しかし、細かいところでさらに面倒なことになっていたようで…

ACCESS_BACKGROUND_LOCATIONなんて知るか！しかもWIFI関連でFINEロケーションが必要とか聞いてないですｗ

https://developer.android.com/training/location/permissions?hl=ja#request-background-location

ただのアクティビティーならもうちょい楽だったのにねぇ。

動作させてみていると、何かのきっかけでまれにSSIDが表示されることがあったんです。もうね、何が原因なのか見当もつかずで。

で、SDK29でとりあえず満足することにして、一旦SDK31ベースに追加したコードは捨てることに（31用に追加しなければいけないコードがあって面倒だったんですが、見通しが悪くなりすぎるのと、ビルドも通らなくなるので(笑)）。さらに全体的な動作を見直し、動作確認していると、権限を変更すると動作が不安定になったり、サービス自体が消えたままとなってしましました。

一部はコードに原因があったりしましたが、助長な部分を削ったり、怪しいところは片っ端からデバッグログを入れたりして様子を見ていましたが、どうも権限を変更するとサービスの動作があまり安定しないことがわかりました。

マイクロソフトやASUSのメールアプリで挙動不審というか、メール受信がしなくなることがあったのですが、原因はきっとAndroidのサービスの扱い方が雑というところなんでしょう。単純に思いつくのは、適当なタイミングでサービスの動作チェックをする必要がありそうだということ。Androidって結構こんな感じがします。そもそもプロセスなども強制終了させて起動し直せばいいでしょ適な発想が主体だし。クソ仕様ですがｗ

で、Widgetでそこまでするか？

ストアで公開すると結構文句言われそうですけど、とりあえずする気はないｗ実用的に問題なさそうだしｗ

通常アクティビティーがあるアプリなら、権限許可を得るためにダイアログを表示させて、許可されたタイミングで処理が行えるのですが、Serviceなんてそんなダイアログ開けませんし、最悪アプリの詳細から設定したり、権限管理系の設定画面で許可されたりするので何とかできないか調べましたが、使えそうなブロードキャストは無さそうでした。

そもそも権限が変更されるとどうなるの？ってことで触ってみて実感したのは、

権限を新たに許可した場合、そのまま。

許可された権限を取り消した場合、実行中のアプリはリスタートされる。バックグラウンドのServiceは一定時間経過後に強制終了され、直後にStartされる。もしかすると終了させられることを通知するintentか何かを受け取っているのかもしれないけど…どうなんだろう？

権限を取り消したり、許可したり少し雑にちょこちょこ切り替えてみると、アプリが落ちたままとなってしましました。

色々触ってみた結果、権限関連以外はまともに動いてそうなので、とりあえず一段落かな？

富士通の

 昨日まとめ系で見かけたツイートで、推奨パソコンがwikipediaを開くだけでCPU使用率が100%のままとなっているというのを見かけた。

【悲報】文科省推奨スペックの富士通製パソコン、WikipediaでCPU使用率100%にｗｗｗｗｗｗ

実際のツイートでは店頭でwikipediaのページを開いてタスクマネージャーのパフォーマンスタブページを開いている様子の写真が写されていた。

 

で、じっさいに手元のネットブックで開いてみました。最初はFirefoxで開いて、Edgeでも開いて様子を見てみました。

似たようなスペックなので数秒CPUリソースを使い果たしていましたが、その程度です。（メモリが減っているところ（グラフの中央当たり）でEdge以外のアプリを終了させたところで、CPU使用率が跳ね上がっている山はEdgeの起動、ようこそページの表示、Wikipediaの表示のタイミングになっていると思います。CPUの動作クロックは、通常1.1GHz程度でフルパワー時は2.4GHzとか2.5GHzぐらいまでクロックが上がると思います。）

明らかにおかしいのは、ツイートの写真ではハンドル数が異様に多いということでした。

気になったので手持ちのほかのWindowsでも確認してみましたが、どれも似たり寄ったりでした。桁が違うというのはどういうことなのでしょうね。

手持ちは64bitばかりなので、32bit版とは使用メモリなどは差が出ますが、ハンドル数はあまり変わらないとおもいます。

ツイートのレスにも書かれていましたが、富士通のPCには「いつもアシストふくまろ」と言うアシスタントアプリが入っているそうで、これがその原因なのかとも思われますが、これだけでそこまで重くなるような代物なのか？と言う感じがします。

一番ありえそうなのは、Windowsのメンテナンス系のサービスが起動してそれが止まらなくなっているのか？

ちょっと気になったのでメモ書き。