KeyHoleTV開発者のブログ

日々の質問や開発の日記

KeyHoleTV開発秘話(その1)

なぜ、KeyHoleTVは、連続して11年間も配信できるのか

海外で、日本のテレビを視聴できるサービスは、数多くあります。 しかし、多くのサービスは、途中で止めたり、配信が停止したりします。 しかし、KeyHoleTVは、11年連続して配信をしています。 どうしてでしょうか?

答えは、KeyHoleTVのシステムの秘密にあります。

殆どのサイトは、日本から参照できない

海外で日本のテレビを視聴できるサービスを運営しているサイトのほとんどは、日本からは、参照できません。 例えば、

上記のサイトは、日本からは、アクセスできません。 海外からアクセスすると、以下のような表示がブラウザに現れます。

f:id:KeyHoleTV:20190613061656p:plain

SKYLINVE NET TVのスクリーンショット

これは、自分たちが日本の法律を犯していて、停止させらる可能性があるので、できるだけ日本からは、アクセスできないようにしているためです。 これらのサイトには、アクセスされた場所によって、サイトを表示したり、しなかったりする機能が埋め込まれています。

海外の人が上記のサイトにアクセスできない旨を確かめるためには、VPNを使う必要があります。 VPNサービスは、VPNサーバを置いている場所から、サイトにアクセスします。 自分のブラウザは、あくまでも VPNサービスのサーバとの間で暗号化した通信を行います。 このため、VPNサーバが置いている国(や地域)がサイトへのアクセスされた場所になります。

VPNの設定は、OSやVPNを使うアプリによって、難易度が変わります。 比較的容易に行えるのが、アンドロイド端末です。 VPNを使うアプリがあり、利用できるサイトが公開されています。

www.vpngate.net

アンドロイドで、日本のVPNを接続して、ブラウザでSKYLIVE NET TVをアクセスした結果は、

f:id:KeyHoleTV:20190613140847p:plain

日本のVPNを介してサイトにアクセス


となります。 左上に小さくError と出ています。 これは、アクセスしたアドレスが日本の場合、エラーを表示するようになっているためです。 また、VPNを使うことで、日本国内にいても、あたかも海外からアクセスできるようになります。

また、日本からVPNを使わないで、あたかも海外からアクセスしたようなサービスが、海外にはあります。

www.browserling.com

このサイトの入力バーに  http://skylivetv.net/ を入力すると、ページが正しく表示されます。

 

一方KeyHoleTVのサイト 

 

www.oiseyer.com


は、日本はもとより世界中からアクセスできます。 では、どうして、KeyHoleTVのサイトは日本からアクセスできるのでしょうか?

関係省庁に再配信の許可の依頼

おそらくKeyHoleTVが唯一関係省庁に再配信の許可の申請を出しています。 他のネットを使った視聴システムは、放送局が行っているもの以外、おそらくどこも申請をしていません。 ネットを使ったのシステムは、申請ができる条件を残念ながら満たしてません。 ケーブルテレビは、再配信の申請をして、再配信をしてます。 これは、地上波デジタル放送が場所によって、通常のアンテナでは視聴できないため、ケーブルテレビで難視聴地域を解消するためです。 ただ、難視聴地域を解消する目的だけで、ネットを利用した配信は許可されないようです。 日本における放送は、特殊な意味を持っています。 放送を行うには、当然認可が必要で、国の裁量によって、決定されます。 放送には、緊急時にいち早く情報を伝達する義務(法律で決まっています)があり、この義務を守れていない場合、許可が下りません。 多くのネットを使った再配信は、この義務を守ることができていません。 だから、再配信の許可が下りないのです。

KeyHoleTVは、他の配信システム(地上波デジタル放送を含む)より、早く情報の伝達ができるため、 関係省庁に再配信の許可の申請を行いました。 早く受信できる事実は、YouTUBEに掲載しています。

youtu.be

これは、地方で地デジをテレビで受信したものと、KeyHoleTVで受信したものを比較しています。 明らかにKeyHoleTVの方が早く受信できています。

次回は、なぜKeyHoleTVが早く送信できるかをお伝えします。

(つづく)

 

KeyHoleTVのダウンロード・プレミアムモジュールキーの購入は、

www.oiseyer.com

で。

Windows10でKeyHoleTV動作しなくなった

利用者からWindows10 でインストールしたKeyHoleTVが、動作しなくなったとの報告を受ける。 ダブルクリックしても、アプリケーションが起動しないとのこと。

アプリケーションが起動しないのは、起動しない理由がある。もし、アプリケーションがエラーや「アプリケーションに問題が発生しました」などのメッセージを表示せず、動作しなくなったのは,大きく分けて二つの原因がある。 一つは、アプリケーションが入っているフォルダが何らの原因で壊れている可能性。
もう一つは、OSがアプリケーションの動作を停止している可能性。 アプリケーションが格納されているフォルダが壊れている場合、OSがアプリケーションをピックして、実行させようとして、正しいライブラリがピックできないか、実行中ファイルが壊れていて、中に格納されている命令が正しく動作しない。 この場合、ファルダが壊れているので、別のフォルダにインストールすると、動作する可能性がある。 しかし、フォルダが壊れる現象は、ハードディスクが何らかのエラーがあるので、そのうちPCが動作しなくなる可能性が高い。

OSがアプリケーションの動作を停止している場合、殆どはセキュリティソフトウェアが通信の許可リストに入っているアプリケーションを外しているのが原因。 現在、3例の報告があり、その全てが、SOURCENEXTのウィルスソフトウェアである。 過去にも、ここのソフトウェアは、他のセキュリティソフトウェアと比べて、反映が遅く、他のセキュリティソフトウェアがウィルスではないというソフトウェアをウィルスと判断したことが多々ある。

報告をした利用者のセキュリティソフトウェアもSOURCENEXT製である。おそらく、通信の例外リストに載っているソフトウェアを利用者の許可なしに消してしまう。 消してしまった、通信の許可リストにKeyHoleTVを追加すれば、解決する。

通信の許可は、

に詳しい。 

KeyHoleTVは、

C:\Program Files (X86)\ KeyHoleTV

にKeyHoleTV.exe がある。 このEXEを通信を許可するリストに追加すれば、よい。

 

また、何らか理由でアプリがローカルグループポリシーのアプリ項目の拒否リストに載る場合もある。 何故このようなことになるのかは、原因が分からないが、おそらくセキュリティソフトウェアが何らかのメッセージを出して、それに答えたことが原因だと思う。 マイクロソフトは、自分が認知していないソフトウェアや例外設定の場合、多くの場合、「拒否」がデフォルトになっている。 このため、OKを押すと「拒否」が設定される。 また、セキュリティソフトウェアもおそらく、「拒否」がデフォルトになっていて、「OK」を押すと、拒否されると予想する。

ローカルグループポリシーの実行拒否リストに登録された場合、そのログイン名では、ソフトの実行ができない。 

answers.microsoft.com

上記の記事を読むと、別のユーザを作ってみると、アプリが動作したとある。 おそらく、これは、ローカルグループポリシーで、アプリを起動させないような設定になっていると思う。 そこで、解決方法は、ローカルグループポリシーエディタを起動して、KeyHoleTVを許可するか、新しくユーザを作る以外方法がない。 

Windows10では、ローカルグループポリシーを編集するのに、OSの種類によっては、エディタが内包されていないようだ。

appli-world.jp

ローカルグループポリシーエディタが開いたら、

www.livefree.jp

の 

https://www.livefree.jp/wp-content/uploads/2019/04/spr02.png

https://www.livefree.jp/windows10_srp_store/からの転用) 

で、追加の規則の中におそらくKeyHoleTVが入っているので、制限を解除すればよいはず。 また、KeyHoleTVは、32bit アプリケーションなので 32bit アプリが全て実行不可能になっている可能性もある。 その場合、KeyHoleTVに例外を設定すればよい。 ローカルグループポリシーに実行拒否が設定されれば、アプリケーションを再インストールしても無駄で、 ローカルグループポリシーを変更するか、新しくユーザをWindows10で作る以外おそらく対処する方法がない。

 

なお、KeyHoleTVのダウンロード・プレミアムモジュールキーの購入は、

www.oiseyer.com

で。

Cydia への対応

脱獄事始め

顧客から JB(脱獄)したiPhoneをiOS12に上げたら、 前のバージョンのi-KeyHoleTVが動作しなくなったと報告を受ける。 でiOS12では、AD-HOC版のネットでのインストールがうまく行かない不具合がある(この不具合は、 XCdoe10.2.1でやっと解消されました)。 この不具合は、 Code Signの埋め込みの不具合で、Appleが直さなければ、開発者としては、どうしようもない。

それで、Cydia でインストールできるようにするために、

putidevelopersblog.blogspot.com

を参考にして、i-keyholetvをアップロードした。 すると、顧客からは、 error 404 が出てくるとの報告を受ける。 

Cydiaでは、Debianのパッケージ読み取りをCydiaのリポジトリで行っている。 このため、Packages.gz2 と XXX.deb ファイルがあると、パッケージとして認識して、 404のエラーはでないはず。 一般に404のエラーは、HTMLのブラウザが表示する。

こちらとしては、顧客が何をしているかのか分からないし、手元に脱獄した iPhoneがないため、

本当のことが分からない。 また、Cydiaのリポジトリをアップする情報が極端に少ないため、どうすれば、正解なのかが分からない。

で、手元に古いiPhone 5があったので、それを脱獄して、Cydiaのリポジトリの表示がどうなるか調べてみた。 また、脱獄した iPhoneで i-keyholetvがインストールできるか調べてみた。

iPhoneの脱獄

一般に IOSのデバイスは、 AppleStoreにあるアプリケーションとAD-HOCと呼ばれるUDID(機器に付随するユニークな番号)を登録している機器に対して、有効なアプリケーションしかインストールすることができない。 しかし、脱獄すると、AppleStoreにないアプリケーションや AD-HOCのアプリケーションをインストールすることができる。

脱獄には、様々な方法が存在するようだが、

ja.wikipedia.orgCydiaで脱獄したアプリケーションをインストールを調べる目的があるので、 Cydiaを使った脱獄を試みる。

Cydiaのインストール

iPhoneにCydiaを入れるためには、Cydia Impactor を使う

cydia-app.comCydia Impactorで、Cydiaアプリが入ったIPAファイルをiPhoneに入れる。 Cydiaアプリは、iOSのバージョンによって、インストールするIPAが異なっている。

cydia-app.com手持ちのiPhone 5にCydiaを入れる際、 Cydia Impactorが動作する。Linux (CentOS 64 bits, Ubuntu 32bits)Windows32bits,Windows64bits, MacOSが存在するが、私の環境では、 Windows 32bitでしかインストール出来なかった。 Linuxでは、 Cydia Impactorが

lockdown.cpp:57 LOCKDOWN_E_INVALID_CONF

のエラーを吐き出して、処理が進まなかった。 Cydia Imapctor を動作させて、 IPAを入れる際、 Apple のAPP SPECIFIC PASSWORDSが必要で、AppleIDを管理するサイトにログインして、APP SPECIFIC PASSWORDSをCentOS, UbuntuのFireFoxで作ってみたが、Cydia Impactor で、作ったパスワードを入れても、上記のエラーがでてしまう。

yalujailbreak.net直す方法をいろいろ試してみて、iTunsが必要になって、 結局 MacOSで、サファリを使って、

APP SPECIFIC PASSWORDSを構築した。 Windowsの32bitsでは、iTunesを使って、

Appleにサインインしようとすると、なぜか、iTunesがエラーを出して、停止してしまう。 しかたがないので、 Macを使って、 iTunesを起動して、そこから Safariでログインした。 それで、構築した APP SPECIFIC PASSWORDS を Windows32 bitsのCyida Impactorで入力すると、インストールが始まった。 関係があるのかないのか分からないが、APP SPECIFIC PASSWORDS を構築する際、適当な名前を入力する必要があるが、Linuxでは、本当に適当な名前を入れて、 MacOSでは、Cydiaと入れた。 

脱獄開始と問題発生

インストールが始まってしばらくしてから、Cydia Impactorが Generating Application Mapを表示して停止した。 iPhoneには、h3lixのアイコンが表示されていた。 脱獄する際、 対象のIPAは、IOSのバージョンで異なる。 h3lixは、 iOS10.3.3 用のIPAで、別のバージョンのiOSは、他のIPAを利用する。 一旦iPhoneを再起動してみて、 h3lixをタップしてみる。 h3lixが起動できたので、うまくいったと思って、 Jail Break のボタンをタップしようして、確認のため、脱獄のサイトを見てみると、

www.iphonehacks.comTrust Developer Profile とある。 iPhoneを調べてみても、General > Profile(s) & Device Managementが表示されない。 で、iPhoneにDeveloper Profile をインストールする。 Developer Profileがインストールされいないと、Profile(s) & Device Managementが表示されないようだ。 Profile をインストールするためには、 iPhoneでSafariを起動して、

beta.apple.com をアクセスする。 AppleIDでログインする。

developer.apple.comログインした後、Appleからセキュリティコードを聞かれる場合がある。 これは、登録している iPhoneに送られてくる番号をiPhoneで受信して、その番号を入れる。 サイトに入って

Enroll Your Device を選んでダウンロードプロファイルをタップすると、iPhoneにProfile が入る。

iOS10.3.3では、General のVPNの下にプロファイルが表示される。

これで、h3lixをタップして、 Jail Break ボタンをタップする。 タップすると Cydiaがインストールされ、 iPhoneを再起動するか聞いてくる。 再起動して、 Cydiaのアイコンをタップすると、

Cydia が起動して、 脱獄が完了。

 

Cydia でのリポジトリの設定

Cydiaを起動して、下にある Sourceをタップする。 すると、リポジトリが表示される。 リポジトリを追加するには、 Edit をタップして、Addをタップする。 すると、URLを聞いてくるので,

www.oiseyer.com/iOS12/

を入力する。 すると、リポジトリは、

f:id:KeyHoleTV:20190402101040p:plain

Cydiaリポジトリ

と表示される。 www.oiseyer.com をタップして、i-KeyHoleTVのインストールを行う。 また、ここまで、404のエラーは、表示されない。 

i-KeyHoleTVのインストール

リポジトリのwww.oiseyer.comをタップする。 すると All Packages とVideo Player と表示される。 アプリは、 Video Playerなので、 Video Player をタップする。 すると、画面の左上にInstallが表示されるので、タップする。 最後に確認してくるので、許可してインストールを続行する。 すると、エラーが表示された。

f:id:KeyHoleTV:20190402110021p:plain

Cydia Install Error

表示されるエラーは、404ではなく、 dpkg-deb が吐き出すエラーで、置いているファイルの.deb の認識ができないようだ。 Ubuntu で Cydia用の Packages.gz2は、正しく構築されているが、 XXXX.debの解凍ができいない。 Ubuntuで解凍を試したらできたので、解凍する仕組みか圧縮の方法がCydiaとUbuntuでは異なっている。 おそらくCydiaの方が古いと予想して、

dpkg-deb -b で作る  .deb を -Zgzip のオプションを付けて、行う。

dpkg-deb -b -Zgzip  Appのデレクトリ

とした。 これを www.oiseyer.com/iOS12

にアップして、再びCydiaでインストールを試みる。 すると、今度は正しくインストールできた。

f:id:KeyHoleTV:20190402111032p:plain

 

で、結局、404のエラーは、表示されない。 またCydiaでi-keyholetvが正しくインストールも

できた。

Cydiaでインストールしたアプリの運用

iOS10用のCydia は、h3lixをCydiaImpactor を使って導入する。 導入した後、 iPhoneの電源を入れ直すと、Cyida や Cydia を介してインストールしたアプリが動作しなくなる。 タップしても、一瞬は立ち上がるが、すぐにアプリケーションが終了してしまう。 他のバージョンの Cydia では、どうなるか分からない。 

h3lixの脱獄は、恒久的に反映されるのではないようだ。 CydiaやCydiaを介してインストールしたアプリを再び動作させるためには、h3lixのアイコンをタップして、起動しする。

起動すると、「Kickstart」というボタンが表示されるので、それをタップする。 タップすると、 iOSが再起動する。 これで、CydiaやCydiaを介してインストールしたアプリケーションが利用可能な状態になる。

 

なお、Cydia 対応のi-KeyHoleTVのインストール、プレミアムモジュールキーの購入は、

www.oiseyer.com

で。

Android, WindowsCE KeyHoleTV

開発の動機

WindowsCE (Windows Mobile 6.0)の端末(iPaq)が手元にあって、それでKeyHoleTVを動作させていた。 iOS用のKeyHoleTVをアップデートして、GUIを Android 、iPhoneで同じようなインタフェースにしたので、WindowsCEでも同様なインターフェースにするようにした。

f:id:KeyHoleTV:20181208044315p:plain f:id:KeyHoleTV:20181208044845p:plain f:id:KeyHoleTV:20181208045048p:plain f:id:KeyHoleTV:20181208045123p:plain

   Windows CE KeyHoleTV      Android KeyHoleTV

 共有GUIライブラリ

WindowsCEのGUIには、Android と同じGUIのライブラリを利用している。 このライブラリは、 Androidでは、OpenGL ES 2.0 を使い、Linuxでは、 OpenGL 2.1/3.0, Windows CEでは、フレームバッファに直接描画するようになっている。 この下層部分だけをOSにより切り分ければ、GUIの部品例えば、ボタンや、インプットバーなどは、全てのプラットフォームで、共通に使える。 更に、GUIライブラリがLinuxで動作できることから、Android, Windows CEで動作するKeyHoleTVが同じソースコードで、Linux上でも動作するようになる。 アプリやGUIライブラリのデバックも、Linux上できるためGDB が利用可能になる。 また、fprintf を入れることで、アプリやライブラリの動作のデバックが容易に行える。 

例えば、Android の場合、 Android Studio を利用して、シミュレータでデバックできるが、とにかく遅い。 起動するの時間がかかるし、アプリの実行にも時間がかかる。 LinuxでGUIライブラリを利用すると、 make してから、実行まで、数秒もかからずできてしまう。 

GUIライブラリや、GUIを持ったアプリのデバックでは、デバック対象に移行するまで、なんらかの操作を行う。 Android Studio や XCode, Visual Studio には、イベントを自動発生させて、デバックするような機構が用意されている。 しかし、イベントを自動発生させる処理を記述するにも、時間がかかる。 特に、アプリが不具合で停止しないで、挙動がおかしい場合には、その発見が結構大変で、何度もコンパイル・実行を繰り返す必要がある。 この時、実行までの時間が短いと、試行錯誤で、繰り替えしてデバックできる。

 

f:id:KeyHoleTV:20181208051640p:plain f:id:KeyHoleTV:20181208051750p:plain f:id:KeyHoleTV:20181208051957p:plain f:id:KeyHoleTV:20181208052036p:plain

  CE 用Debug Linux 240x320 GUI          Android 用 Debug Linux 400x700 GUI

Androidでのデバイス回転の不具合

Android KeyHoleTVで、デバイスを回転(横にしたり、縦にしたりする)すると、アプリが停止する不具合があった。 ログを出力するようにしたり、アプリの異常停止のログをみても、原因がわからない。 アプリに終了イベントが送られ、再び起動する処理になっている。 Androidの場合、ホームボタンを押し、すぐさまアプリの起動をしているように見える。 

原因は、マニフェストにあった。 Androidアプリは、マニフェストに、どのような動作をするのかを記述する。 今までは、Activityに

<activity

....

   android:configChanges="orientation|keyboardHidden”/>

と記述していた。 これで、デバイス回転時には、終了のイベントが発生しないで、連続してアプリが処理できた。 11月1日より、Googleから、Android アプリは、 SDKレベルを28以上にしないと、Play Store に載せられないとの要請がきたので、KeyHoleTVのSDKレベルを

<uses-sdk android:targetSdkVersion="28" android:minSdkVersion="9" />

とした。 この結果、 Activity を規程するマニフェストの android:configChanges が

"orientation|keyboardHidden" だけでは、一旦アプリが終了して、Activity を起動するような設定になっていたようだ。 これが分かるまで、結構な時間がかかった。 

targetSdkVersion="28" にすると、 configChangesは、

android:configChanges="orientation|keyboardHidden|screenSize"

としないと、回転後に終了イベントが送られる。

さて、マニフェストは、XMLで記述する。 XMLは、タグと属性は、任意に記述できて、それを解釈する機構に依存する。 このconfigChangesの属性の値を考えた人の設計が誤っているとしか思えない。 SDKのバージョンを変えると、configChangesの意味が変わるような設計は、正しいとは思えない。 それなら、回転に関する属性を設けて、その動作をYES/NOで表した方が、明解になる。

更に、Native-Activity で構築しているアプリケーションの多くは、OpenGL ESを使っている。 OpenGL ESで利用するオブジェクトは、Windowに依存する。 Window は、Activityに付随している。 すなわち、Activity が終了すると、Windowもなくなり、それに依存しているOpenGLのオブジェクトも利用できなくなる。

さて、OpenGLのオブジェクトは、アプリのプロセスが完全に終了するまで、メモリが確保されたままになる。たとえ、アプリがOpenGLESの関数を使って開放しても、メモリ自身は残ってしまう。 すなわち、 Activity が終了して、再びActivityが作られるような構造では、回転するたびに、OpenGL ESで利用するオブジェクトのメモリ消費を加算してしまう。 Javaで記述したアプリでもOpenGL ESを利用したアプリでは、同様な問題が発生するかもしれない。

WindowsCEで、ナビゲーションボタンの操作(実機と、シミュレータの違い)

WindowsCEには、ナビゲーションボタンがついている。 ナビゲーションボタンは、画面の下に、上、下、右横、左横、真ん中に押せるボタンがある。 画面をタップしたり、ナビゲーションボタンで、アプリを操作できるようになっている。

f:id:KeyHoleTV:20181209142519p:plain

ナビゲーションボタン

KeyHoleTVもナビゲーションボタンやキーボードで、操作できるように設計してあり、ボタン等に下線が引かれているものや、表示が濃くなっているものが現在、選択されている表示オブジェクトである。 選択されている状態で、エンター(リターン)キーをヒットすると選択されている表示オブジェクトがあたかもタップされてたような動作をする。 選択対象は、タブキー(もしくはシフトタブ)で、選択対象が移動する。 これは、Windows,Mac,LinuxのKeyHoleTVと同等な動作になっている。

WindowsCEのKeyHoleTVは、ナビゲーションボタンの左が、アンドロイドのバックボタン、上、下が番組表が表示されているとき、番組選択を移動、右がタブキーに割り当てている。 真ん中のボタンがエンターキーにするようにしている。 シミュレータでは、真ん中ボタンを押した操作が、うまく動作したが、実機(iPaq)では、どうしても動作しない。 さらに、WindowsCEでは、実機でのVisual Studio を使ったデバックができにくいので(おそらく出来ない可能性が高い)、一体どのようなコードが入力されているのかが、分からない。

そこで、GUIライブラリのインプットバーにグリフ(文字の形を表したもの)が定義されていないコード(例えば,HEX 009DやHEX 009Eなどは、グリフがないので、四角が表示される。) に対して、16進数の表示ができるようにした。 なお,ASCIIで定義されているコードに関しては、UNICODEのU+2400 以降にグリフがあるので、それを利用している。 例えば、 U+2400では、

             

と表示される。 グリフがない文字は、16ビットのHEXで表示されるようにしたので、009Eの表示結果は、

f:id:KeyHoleTV:20181209010504p:plain

HEXでの表示

となり、何が入力されいるのかが分かるはず。 で実機でためしたらみたら、 00 0D と表示された。 00 0Dは、CRのはずで、それが表示されなければ、ならない。 で、GUIライブラリのコードを調べてみたら、Control+CRが入力されていることが分かった。 シミュレータでは、CRが入力され、実機では、Control+CRが入力されていた。 

WindowsCEのイベント処理は、Windowにイベントプロシジャーを登録して行う。 イベントプロシージャで、 case WM_KEYDOWN:  で切り分けている。 キーボードで押された全てのキーがコードで、wparam に渡される。 当然、シフトキーも、コントロールキーも押されたとき、このイベントが発生する。 従って、シフトキーを押しながら、英字キーを押して、大文字にする処理は、自分でプログラムを記述する必要がある。 実機では、コントロールキーを押してから、リターンキーが押されているようなイベントが発生していた。

共有GUIライブラリのデバイス依存部分

AndroidやLinuxのOpenGL (AndroidではES)は、テキスチャバッファをライブラリないで保持し、テキスチャに対して、書き込みを行う。 書き込みが終了すると、 テキスチャをGPUに送って、4点のポリゴン(三角形が二つ)にテキスチャを貼り付ける命令をGUPの送っている。 OpenGL ES 2.0では、 Vertex Shader と Fragment Shader を用意した。 

 

const char* vertex_shader =
        "attribute vec4 position;\n"
        "attribute vec2 texcoord;\n"
       "varying vec2 texcoordVarying;\n"
       "void main() {\n"
             "gl_Position = position;\n"
             "texcoordVarying = texcoord;\n"
       "}\n";

 

const char* fragment_shader =
        "precision mediump float;\n"
        "varying vec2 texcoordVarying;\n"
        "uniform sampler2D texture;\n"
         "void main() {\n"
               "gl_FragColor = texture2D(texture, texcoordVarying);\n"
         "}\n";

 

これらの Shader で、利用する texture とposition, texcoord をライブラリで用意して、GPUに渡してやれば、textureに描かれた内容が、 4点で示した矩形に貼り付けられる。

glTexSubImage2D で、texture の絵をGPUに送信する。 その後、glDrawArraysで三角形二つを描画させ、glFlushで、描画内容をフレームバッファに送ると、画面に絵が表示される。

具体的には、OpenGL ESの初期化処理の中で、

const GLfloat vertices = {
-1.0f, 1.0f, 0.0f,
-1.0f, -1.0f, 0.0f,
1.0f, 1.0f, 0.0f,
1.0f, -1.0f, 0.0f
};

static GLfloat texcoords = {
0.0f, 0.0f,
0.0f, 1.0f,
1.0f, 0.0f,
1.0f, 1.0f
};texcoords

      position = glGetAttribLocation(program, "position");

      texcoord = glGetAttribLocation(program, "texcoord");

      textures[0] = glGetUniformLocation(program, "texture");

Shader 中の position, texcoord, texture とGUIライブラリ中の変数 position, texcoord, textures[0] を関連づける。  positionには、点の座標( vertices ) をいれ、

glVertexAttribPointer(position, 3, GL_FLOAT, GL_FALSE, 0, vertices);

texcoordには、テキスチャの座標(texcoords) をいれる。

glVertexAttribPointer(texcoord, 2, GL_FLOAT, GL_FALSE, 0, texcoords);

 

描画処理の中で、

       glBindTexture(GL_TEXTURE_2D, textures[0]);

       glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0,Width, Height, 

                                          GL_RGB,GL_UNSIGNED_SHORT_5_6_5, (void *)Buffer);

Buffer に入っている絵データをGL_TEXTURE_2Dに送り込む。  送り込まれた絵データは、Shader プログラム中の texture にとして、GPUで処理される。

   glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);

で、二つの三角形を描いて、テキスチャを貼り付ける。

 

 Android の機種によっては、 OpenGL ES 2.0 であっても、Textureのサイズがが4の倍数でないと表示されない。 OpenGL ES 2.0 では、一応、テキスチャの大きさは、任意でよいとなっている。 また、Android も iOSも、表示する絵は、16ビットの深さである。

 

WindowsCEの場合、フレームバッファのポインタがもらえるので、テキスチャバッファの内容をフレームバッファのポインタに送り込んでやれば、画面に絵が表示される。 

hdc = GetDC (hWnd);
if (hdc) {
     if (ExtEscape (hdc, GETRAWFRAMEBUFFER, 0, 0,
                                  sizeof (RawFrameBufferInfo), (char *) & rfbi)) {
                  if (rfbi.wFormat == FORMAT_565){
                               m_framebufwidth = rfbi.cxPixels;
                               m_framebufheight = rfbi.cyPixels;
                               m_xpitch = rfbi.cxStride;
                               m_ypitch = rfbi.cyStride;
                               m_cbpp = rfbi.wBPP;
                               m_framebuf = (unsigned char *)rfbi.pFramePointer;

                              ReleaseDC (g_hWnd,hdc);
                  }

      }

}

m_framebufが、フレームバッファのポインタである。 FORMAT_565は、16ビット深度のバッファで、WindowsCEの場合、FORMAT_565となる。

 

Linuxで利用しているOpenGL の場合、Vertex Shader と Fragment Shader は、OpenGL ES 2.0 と基本は同じである。 しかし、Linuxで実装されているグラフィックスカードによっては、

OpenGL2.1とOpenGL3.0 になっており、Shader のプログラムが異なっている。

const char *vert_code_array =
"#version 130\n"
"in vec3 VertexPosition;\n"
"in vec2 VertexTexCoord;\n"
"uniform mat4 RotationMatrix;\n"
"out vec2 TexCoord;\n"
"void main (){\n"
    "gl_Position = RotationMatrix * vec4(VertexPosition, 1);\n"
    "TexCoord = VertexTexCoord;\n"
"}\n";

const char *vert_code_array120 =
"#version 120\n"
"attribute vec3 VertexPosition;\n"
"attribute vec2 VertexTexCoord;\n"
"uniform mat4 RotationMatrix;\n"
"void main (){\n"
    "gl_Position = RotationMatrix * vec4(VertexPosition, 1);\n"
     gl_TexCoord[0].xy = VertexTexCoord;\n"
"}\n";

 #version 130がOpenGL3.0で#version 120がOpenGL2.1 となる。 version は、OpenGLの関数 ss = (const char *)glGetString ( GL_SHADING_LANGUAGE_VERSION );

で取得して、ss の値を文字列比較で、バージョンをみる。

具体的には、

  if( strcmp(ss,"1.20") == 0 )

で、OpenGL 2.1 の場合、vert_code_array120 を使って、Shaderのコンパイル・ロードを行う。

GUIライブラリの不具合で、KeyHoleTVの停止

Android版KeyHoleTVは、GUIライブラリの不具合で、処理がループしてしまう不具合があった。 この不具合は、特定の領域で、文字列を表示する際、自動折りたたみ処理の不具合であった。 当然、この不具合は、WindowsCE版のKeyHoleTVでも同じGUIライブラリを用いているので、発生する。

自動折りたたみは、ある領域に文字列を表示する際、文字列がその領域をはみ出してしまう場合、改行して次に行に表示する機能で、KeyHoleTVでは、番組の詳細の表示に利用している。

この機能は、英語・日本語に対応しているが、英語と日本語が混ざった文字列では、折りたたみの処理で、ループしてしまった。 英語の場合、スペース、カンマ、ピリオド、ハイフォンの次の文字でしか、折りたたむ(改行する)ことができない。 一方日本語の場合、行の先頭に点(、)や丸(。)があってはいけないが、これ以外どこでも折りたためる。 このルールを実装したが、折りたたむ必要がある文字が英字の場合、前のスペース等の文字まで、戻って、折りたたんでいる。 

f:id:KeyHoleTV:20181210041938p:plain

上記の例では、赤線が境界で、赤線を越えて表示しないで改行を行う。 しかし、改行する文字が 'A'であるため、GUIライブラリが英語と判断してしまって ’’ まで戻って、改行していた。そのため、'ABCDEDFG’ の先頭から計算を行っていた。 しかし、結局改行できず、繰り返して計算を行っていた。

修正は、スペース等まで、戻る処理の中で、英数字以外の場合、折りたたみができるように変更して、ループから抜けるようにした。 上記の例では、'' で改行する。

この不具合は、デバイスの大きさと文字列に依存しており、再現するのに、Linux版のGUIライブラリがないと、対処出来にくかったと思う。 Linux版のGUIライブラリは、OpenGLで表示するウィンドウの大きさを任意に変更できるので、容易の再現できた。

 

なお、KeyHoleTVのダウンロード・プレミアムモジュールキーの購入は、

www.oiseyer.com で。

 

 

 

GoDaddy への対応で苦労する

KeyHoleTVのホームページ OISEYER.com は、 GoDaddyで管理してもらっている。 ホームページの更新に ssh で使っているが、ある時、ssh の通信で、いきなり、ssh_exchange_identification: read: Connection reset by peer
とエラーがでて、接続できなくなった。 これは、Goddy 側のサーバが、こちらで使っているIPアドレスからの接続を拒否するリストに登録され、接続できない状況に陥っているから発生するようだ。

短時間のうちに何度も接続したり、何度もパスワードを間違えると、自動的に登録されるようで、これは、GoDaddyに頼んで、アクセス制限を解除もしくは、接続可能なリストに、こちらのIPアドレスを登録してもらうようお願いするしか方法がない。  こちらは、 static IP(アドレス固定)を使っているので、こちらのアドレスを変える方法がとれない。*1

で、電話した。

状況を説明すると、相手がこちらの状況をまったくわかってくれない。 「このようなサービスはない。」と言い出す。 そもそも、 ssh を知らなし、 GoDaddy のプライベートサーバへの契約をさせようとする。 何度もやりとりをして、埒があかないので、スーパーバイザーに代わってくれと、頼んでも、頑なに拒否する。 何度も頼んで、やっと代わってもらってた。 この間、約40分以上、同じやりとりを行った。

スーパーバイザーからの最初の質問は、「あなたは、ルートアカウントが必要なのか」というもので、ちょっと驚いた。 そうではなくて、こちらのstatic IPから ssh 接続が、出来なくなったと伝えると、「ちっとまって、 こちらでsshのサーバ(sshd)が動いているか確認するから」と言われて、待っていると、「sshdは、問題がないみたいだが、拒否リストにあなたのIPが登録されているようだ、 ホスティングの部署に代わる。」と言われた。

で、ホスティング部門の人と話して、状況を伝えると、「たまにあるんだ。 いっぱい通信したでしょう ?」と言われて、「実は、ホームページの更新を行っている」と伝えると、やっぱりという返事。

で、使っているIPアドレスを伝えると、変更したから、5分ぐらい待ってと言われたが、 すぐにテストしたら、繋がった。 スーパーバイザーに代わってからこの作業を終えるまでの時間は、およそ 5分。 最初の40分は、なんだったんだ と思ってしまう。

個人的に知っているゲームでは、最初はやさしく、徐々に難しくなる。 しかし、 GoDaddyというダンジョンは、最初のハードルがむちゃくちゃ高い。 あまり知らない人では、諦めたり、高いプライベートサーバとの契約を行ってしまうのではないか。

米国では、訴訟が無茶苦茶に多い。 背景には、このような状況が多々あるのかもしれない。 言われるままに契約をしたり、諦めたりして、状況が更に悪化したり、損害がでた時に訴訟になるのではないか。

 

なお、KeyHoleTVのダウンロード・プレミアムモジュールキーの販売は、

www.oiseyer.com

 で。

 

*1:通常のプロバイダとの契約の場合、 ADSL、ケーブル、光のモデムの電源を切って、立ち上げるとプロバイダーが新しくIPアドレスを割り振ってくれる。 この部分は、中国国内で、KeyHoleTVを使う方法で詳しく説明する。

CSS HTML iOS Safari に悩む

KeyHoleTVのホームページ OISEYER Inc. は、ダサイデザインで、開発者が手で書いている。 HTMLやCSSを emacs で記述しており、デザインツールのたぐいは、gimp と OpneOffice ぐらいである。 デバックは、appach をCentOSにいれて、それで、動作の検証をしている。

 

ホームページの中で、チェックボックスにチエックを入れると、ボタンが有効になる部分がある。今まででは、JavaScript を使っていたが、CSSでも出来そうなので、CSSに書き換えた。

処理は、

HTMLとCSSだけ!要素の表示・非表示を切り替える方法

[CSS]チェックボックスにチェックを入れた時に要素に変化を付ける方法|CSS擬似要素・擬似クラス|WEBデザインの小ネタとTIPSのまとめサイト「ウェブアンテナ」

を参考にした。 

これらのページで紹介されているCSSで肝になる部分は、おそらく、

.hidden_box .hidden_show {
    height: 0;
}
.hidden_box input:checked ~ .hidden_show { height: auto; }

div.changed {
    color: #000;
}
input[type=checkbox]:checked ~ div.changed {
    color: #ff0000;
}
であろうと思う。 これらは、 inputタグで、タイプがcheckbox の時、checkedされているか、いないかで、対象の属性を変える。 上記の例では、checkedされているとき、 .hidden_show、.div.changedの属性を更新するようになっている。 個人的に思う重要な点は、属性の更新ができるものとできないものがあるという点。 例えば、buttonには、 disabledという属性があるが、CSSでは、どうもこの属性の更新ができないようだ。 例えば、 disabled:none; ができると、便利だと思うのだが。 (display:none; は、できるくせに、何故だ。Javascriptを押す人たちが強く主張しているからなのか) これをするためには、JavaScript を用いるしか方法がないみたい。 方法があったら、教えてほしい。
 
HTMLでは、
<label for="label2">クリックして表示</label>
<input type="checkbox" id="label2"/>
<input type="checkbox" id="toggle">
<label for="toggle">Toggle Button</label>
となっている。 
 
さて、iOSのSafariである。 iOSのSafari は、ボタンのtypeやinput のタイプにsubmitを指定すると( <button type="submit" ...> <input type="submit"..> )、
表示上では、頑なに、トラックの絵のボタンになってしまう。 だから、
<button type="submit" ...>
<img src="xxx" ...>
テキスト
</button>
で括った場合でも、img やテキストが表示されず、細長いトラックの絵になってしまう。 同じSafariでもMacでは、img やテキストが表示される。
これを解消するために、google でいろいろ探したら、
input[type='submit']
{
   -webkit-appearance: none;
}
に行き着く。 どうやら、' -webkit-appearance:'
の属性をnoneにしないといけないようだ。 でもこれでは、正しく表示されない。 理由は、input タグを用いていること。  input タグのタイプがsubmitの場合、 -webkit-appearance をnoneにしている。 上記のbutton の場合、
button [type="submit"]
{
    -webkit-appearance: none;
}
としないといけない。 これで、iOSのSafariでも正しく表示された。 この書き方は、いろいろ探したが、でてこない。 CSSやHTMLを扱っている人にとっては、当然なのかもしれないが、答えを見つけるまで、えらく苦労した。  まず、button に [type="submit"] が使えるかどうか分からないし、タグは、なんでもよいのかもよく分からない。 個人的には、[type="submit"] は、いろいろなサイトで紹介されており、上の例でもあるように input タグの専売のように見えてしまう。
 
サイトで、<button ..> タグにする必要性は、 販売用のJavaScript がどうやら、 buttonタグ のtype しかみておらず、input タグのtype="submit" にしても、JavaScript がそれに反応しない。 当然
idや名前もbutton のものと同じにしても、JavaScript が反応しない。 これも理由がよく分からない。
<form> で囲っているので、 その中にある input であろうが、buttonであろうが、 変わらないような気がしてならないのだが。。。
 
なお、KeyHoleTVのダウンロード・プレミアムモジュールキーの販売は、

www.oiseyer.com

 で。
 
 
 
 

 

iOS 12 は、おそらく不具合がある

原因の発覚

iOS12 にアップグレードしたら、i-KeyHoleTVが動作しなくなったと利用者から報告があった。手持ちのiPhoneをiOS12にアップグレードしたら、iOS11で動作していたアプリが直ぐに終了する。 このとき、XCodeのターゲットのOSのバージョンを変えれば、動くのではないかと思って、ターゲットのバージョンを変えて、アプリを再構築した。 エミュレータで、動作確認をして、アプリをインストールしてから、実行してみると、直ぐに終了する。 

IPhoneを開発用マックに接続して、XCodeで実機での実行を行った。 すると、XCodeがダイアログを表示して、アプリがLaunch できない。端末(iOSデバイスの固有の名前)がアプリの実行を拒否したと表示された。

プロビジョンプロファイル

i-KeyHoleTVは、AD-HOCで開発されている。 AD-HOCは、端末の識別子(UUID)がアプリに梱包されている。 端末の識別子は、Provision Profile というファイルで、自分のAppleのアプリケーション開発ページよりダウンロードする。 このファイルを、XCodeに格納しないと、まず、アプリを実機用に作成(Achiveという表現をXCodeでは使っている)ができない。

初期のiOSの場合、端末の識別子を端末にiTunesで送る必要があったが、iOSやXCodeがバージョンアップされ、アプリに梱包された。 昔は、正しいプロビジョンプロファイルがアプリに梱包されていないと、インストールすらできなかった。おそらく、今でもできない。

iOSの脱獄というのがある。 使ったことがないが、AD-HOCのアプリケーションやアップルストアで販売されているアプリケーションがAppleStoreを介さないで、インストールできるようだ。

AppleStoreに置いているあぷりには、AppleStore用のプロビジョンプロファイルがある。このプロビジョンプロファイルがアプリに梱包されている。 脱獄は、おそらく、このプロビジョンプロファイルを識別を無効、もしくは、バイパスする処理を行っているのでないかと思っている。

動作しない原因の予想

iOS12では、iOS11以前とおそらくアプリのプロビジョンプロファイルの認識の方法が異なっているのでは、ないかと思っている。多分、脱獄や有料アプリケーションがAppleStore以外で出回るのを避ける処置がとられている。 この結果、AD-HOC用のアプリケーションが動作しなくなった。

XCode で、エミュレータを用いてデバックを行うと、正しく動作する。 しかし、実機にインストールして、動作させると、直ちに終了する。 エミュレータと実機のOSの違いは、エミュレータは、梱包されれているプロビジョンプロファイルと自分のUDIDの比較などを行わず、アプリを実行する。 このため、エミュレータは、プロビジョンプロファイルがないアプリも実行できるし、たとえプロビジョンプロファイル梱包されているアプリのUDIDの比較などの作業を行わないため、アプリが実行される。 一方、実機は、おそらく梱包されているプロビジョンプロファイルからUDIDの取り出しや自分自身のUDIDとの比較を行っているはずで、そのプログラムに不具合があるか、KeyHoleTVに梱包されているプロビジョンプロファイルの構成が異なっているため、正しく妊娠できないため、アプリが落ちると思われる。

KeyHoleTVに梱包されているプロビジョンプロファイルの構成がたとえ、おかしくなっていても、それを構築するのは、XCodeに付随するプログラムが行っている。 XCodeは、アップルが提供するソフトウェアであるため、たとえ構成が違っていても、OSが正しく処理を行う必要があると思う。

現在の対策

iOS12にアップグレードしないことが第一。もし、してしまったら、ダウングレードをする。 現在、Appleに対策を聞いている。また、iOS12のバグとして、報告も行った。 残念ながら、アプリの開発者では、対策をとる方法がみつけられない。 エミュレータで動作確認ができて、正しいプロビジョンプロファイルをXCodeにいれて、それをリリース用に仕上げても、実機でアプリが動作しないのは、おそらく、iOS12の不具合だと思う。 これを調べるためには、 iOSのデバッグが必要で、アプリの開発者では、iOSのデバックができない。 また、アプリを構成する仕様などが、明らかであれば、それに合わせることができるが、仕様は、公開されていない。 このことからも、Appleが対処しなくてはならないと思う。

 分かったこと

アプリをXCode9で再コンパイルした。 XCode10のプロジェクトをXCode9で、読込ますと、当然プロジェクトは認識できない。 仕方ないので、新しくプロジェクトを作り直した。 この時、このプロジェクトは、StoryBoard を使わないで、本当によかったと思う。 もしStroyBoardを使っていたら、全て使えない可能性が生じて、StoryBoardを一からやり直す必要がある。

さて、XCode9で、再コンパイルしたら、iOS12のデバイスで動作した。 これで、iOS12は、Code Signを調べる処理に問題があるか、XCode10がCode Signを埋め込む処理に問題があるかになった。

因みに、この問題は、AppleのBUG Reportor というバグの報告に上げている。 実は、2回同じ問題で上げているのだが、一度目は、「わざと落としている」というエンジニアの見解で、バグがクローズされた。 

Appleのテスターたちは、おそらくシミュレータに似た実機のデバイスでテストしていると想定される。 AppleStore用のCode Signに認可をするために、アプリの動作確認を行っているが、 おそらく、Code Signの確認をしない実機だろう。 これで、テストをすれば、Code Signの検証に誤りがあるのに、Code Signを検証しない実機で、テストしても現象が現れるはずもない。 だから、「わざとアプリを終了させている」という回答は、理解できる。

で、Appleは、市販されている実機で、アプリやOSの検証を行っていない可能性がある。 開発者には、実機での検証を求めているくせに、自分たちはしていない。 米国が得意の二律背反であろうと思う。

この不具合は、一でも市販の実機でiOS12のリリース時、もしくはXCode10のリリース時で試していたら、簡単に見つかる。 その手順を起こったいるとしか思えない。 おそらく、XCode10で開発した企業向けのアプリも影響がでるのでは、ないかと想定する。

更に分かったこと

XCode9を使えるようにして、ゴミ箱に入っていたXCode10を戻した。この結果、XCode10でも

iOS12で動作するipaを作ることが出来た。 何故なのかがよく分からないが、 ipa ファイルの大きさを調べると、XCode9, XCode10の併用後で、構築したipaファイルの方が大きい。 

  • iOS12で動かないipa : 873,845 バイト
  • iOS12で動く ipa         : 875,190 バイト

現在は、iOS12でも動作するアプリを OISEYER Inc. に載せている。 おもしろいことに、iOS12で動作(起動しない)アプリでも、シミュレータ、iOS10,iOS11では起動する。 このことから、何らかの不具合が、 iOS12もしくは、XCode10にあるとしか思えない。

 

続 更に分かったこと

XCode10をしばらく使っていたら、XCode10.1にインストールせよと表示され、勝手にXCodeが停止した。 しかたがないので、 XCode10.1 にアップグレードした。 その結果、 iOS12で起動しなくなった。 XCodeを消して、 ~/Library にあるXCode関連のファイルもフォルダも全て消しても、 XCode9 , XCode10.1 を再インストールしても、 iOS12.1 で起動できるアプリが作れなくなった。 しかし、 iOS10, iOS11では、アプリが起動できる。

色々調べてみたら、

stackoverflow.com

XCode10 beta でも同様の問題があって、 Key Chain アクセスに入っているApple World Wide Developer Relations Certification Authority を消せばよいらしい。

早速試したみたら、 iOS12.1 でアプリの起動が確認できた。 これで、解決と思って、AD-HOC版をリリースして、  OISEYER Inc. 上げたみた。 残念ながら、ネットでのインストールは出来なかった。 灰色のアイコンが表示されるだけ。

以上のことで、分かったこと

  • Xcodeは、Code Signをアプリに挿入している
  • 挿入場所は、 Key Chain アクセスの項目に依存する
  • iOS10, iOS11 と iOS12では、 アプリのCode Sign をアクセスする物理的な場所が異なっている。
  • ネットインストーラも、 アプリの Code Sign をアクセスしている。 しかし、参照する場所は、iOSとは異なっている。
  • おそらく、 Xcode9 では、複数の場所にCode Sign をアプリに格納している。 このため、サイズが大きくなる。

で、個人的な見解として、 iOS12 iOS12.1 は、不具合がある としか、思えない。 Appleは、少なくとも、製品テストを十分に行っていない。 自分たちが用意した Code Sign の機構で、不具合が生じている。

 

ネットで調べた結果で、 アカウントを増やす対策は、 XCode10.1 では、iOS12で起動するアプリが作れなかった。

KeyChainという史上最低なプログラム

KeyChainというプログラムがある。 このプログラムは、Mac OSに付属していて、パスワードや、Certificate、秘密鍵、公開鍵を管理するソフトウェア。 Xcodeで、iOSのアプリを作るとき、このソフトウェアを利用しないと、アプリの構築ができない。 更に、一年に一度、Appleが発行するCertificate を更新しないと、 iOSのアプリの更新ができないので、KeyChainを必ず使う必要がある。

さて、KeyChainは、内部データを利用して、鍵やCertificate を管理している。 この内部データは、Certificate の更新などにより、比較的簡単に壊れる。 壊れても、 KeyChainを使っている側からすると、壊れている認識ができないし、 表示される鍵やCertificate は、正しく格納されているように見えるし、ほとんどのMacの操作は、問題なく行える。

ところがである。 このデータが壊れると、 iOS用のアプリが突然作れなくなる。 アプリ自身は、Xcodeで作ることができるが、 動かすことができなくなる。 特に iOS12に対しては、全く動作しなくなる。 更にやっかいなことに、 壊れた内部データがないと、不具合を他の機器で

再現できないし、 壊れた内部データを吐き出す機能もない。

まとめると、KeyChainは、 内部データを簡単に壊すし、壊したことがほとんど分からない。 しかも、 壊れた内部データを Exportする機構もない。 しかし、内部データが壊れたら、他のソフトウェアに多大な迷惑をかけるが、 直接使っている人に迷惑をかけるのでなく、 生み出されたソフトウェアを利用している人に迷惑をかける。 SONYの SONYタイマーよりたちが悪いと思う。 不具合を検証させない仕組みとしては、ある意味完璧だと言える。

遅々として進まない Appleのバグ修正

Appleの Bug Reporter に、 Over the air (iOSデバイスのサファリでアプリをインストールする機能)で、 iOS12ではインストールできない不具合を上げている。 Appleから度々、このようにしてみくれ、結果を送れとの連絡が入る。 その都度、言われたことをやって、報告をしている。

このやりとりの中で、 Appleの技術者の質が落ちたと感じている。 最も質が落ちたの感じたのは、 iOSのログについてだ。 アプリが不正終了したりすると、ログがiOSデバイスの中に残る。 このログを送れとの連絡がきた。 以前から知っているが、 サファリでインストールできない不具合は、 ログが一切残らない。 同様に Code Sign が違っていても、ログが残らない。 これは、 iOSデバイスで、 Code Sign に関連した情報を外に漏らさないために Appleがわざと行っている。 Code Sign の不具合である旨を何度も伝えているにも拘らずである。 で、しかたがないので、ログをスクロールしながら、画面コピーして(画面コピーでは、画面いっぱいに表示したものしか、撮れない)で、送付した。 すると、 Appleから、 ログが送られていないとの連絡が来た。 ここで、こいつは、全然分かっていないと感じた。 そこで、ログの画面コピーの絵を一から説明して、 ログが残るぐらいなら、こちらで対処できる旨を伝えた。 すると、何も言わなくなった。 つまり、 Appleは、自分で作ったバグを解決できない。 もう少し待って、解決策がみつからない場合、 Code Signを埋め込む仕様の提出を求めようと思う。

Apple やっとバグ修正(2019年5月1日PST)

MacOSのアップデートで、10.14.4 に上げた。 上げたら、 XCodeのアップデートがあったので、アップデートした XCodeは、10.2.1 になった。 このバージョンで、AD-HOCアプリを作り、

ネットワーク上にアップロードした。 このバージョンで、iOSデバイス上でネットを介してインストールできたことを確認できた。 報告してから、約8ヵ月もかかった。 

 

なお、KeyHoleTVのダウンロード、プレミアムモジュールキーの販売は、

www.oiseyer.com

で。