Der kleine SecOp in mir rebelliert... twitter.com/rammdoesig/sta…
— adlerweb|BitBastelei (@adlerweb) 15.12.2016 12:31
Archiv für das Jahr: 2016
@GreatScottLab and don’t dare to say no of you don’t want endless discussions ;)
@GreatScottLab and don't dare to say no of you don't want endless discussions ;)
— adlerweb|BitBastelei (@adlerweb) 15.12.2016 11:13
BK #Andernach ist ohne Fritteuse unterwegs – also nur Non-Chicken-Burger & Getränke verfügbar
BK #Andernach ist ohne Fritteuse unterwegs - also nur Non-Chicken-Burger & Getränke verfügbar
— adlerweb|BitBastelei (@adlerweb) 15.12.2016 11:05
It’s alive! pic.twitter.com/4aEtcYKIDE
It's alive! pic.twitter.com/4aEtcYKIDE
— adlerweb|BitBastelei (@adlerweb) 14.12.2016 20:23
Wenn man keine Lust auf Mathe hat lässt man die Kalibrierung halt per Bruteforce laufen… >_> pic.twitter.com/1KWhPttzDU
Wenn man keine Lust auf Mathe hat lässt man die Kalibrierung halt per Bruteforce laufen… >_> pic.twitter.com/1KWhPttzDU
— adlerweb|BitBastelei (@adlerweb) 14.12.2016 17:24
Blog Post: Amdroid/CM: Eingehende SMS werden nicht angezeigt bit.ly/2hNNRvt
Blog Post: Amdroid/CM: Eingehende SMS werden nicht angezeigt bit.ly/2hNNRvt
— adlerweb|BitBastelei (@adlerweb) 14.12.2016 16:21
Amdroid/CM: Eingehende SMS werden nicht angezeigt
Die Älteren unter euch können sich eventuell erinnern: SMS. Ein System um Textnachrichten an Mobiltelefone zu senden. Begrenzte Textlänge, hohe Gebühren und nicht verschlüsselt. Eigentlich heute Obsolet, aber einige Anbieter denken immer noch, dass dieses Verfahren modern sei – auch wenn es seit fast 7 Jahren als unsicher eingestuft wird. Hallo Banken. Es kam wie es kommen musste: Ich sah mich genötigt ein Produkt über eine dieser Gesellschaften zu bezahlen und – nichts. Während die Webseite freudig vermeldete, dass ich eine passende TAN erhalten hätte machte mein Handy keinen Mucks. Toll, ich hab ein Zahlungsziel. Aber auch nichts ungewöhnliches – im Telefonica-Netz kommt es ja nicht unbedingt selten zu Störungen, also warten wir halt.
Einige Stunden später noch immer nichts, also müssen wir wohl selbst Hand anlegen. Erste Anlaufstelle: Test-SMS senden. Gar nicht so einfach, denn SMS-Funktion hab ich eigentlich auf keinem anderen Gerät mehr installiert. Glücklicherweise habe ich noch einen „echten“ Telefonanschluss ohne VoIP und konnte daher per Modem ein SMS-Gateway erreichen. Allerdings ohne Erfolg. Also machen wir mal ein altes Handy fit und versuchen es da – woho, SMS. Es muss also an meinem Endgerät liegen.
Per ADB zeigt sich nach einigem (teuren) Geteste folgender Fehler:
12-14 11:07:05.216 3179 5307 W MmsSmsDatabaseHelper: Upgrading database from version 64 to 67. 12-14 11:07:05.216 3179 5307 E SQLiteLog: (1) table sms_restricted already exists 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: table sms_restricted already exists (code 1): , while compiling: CREATE VIEW sms_restricted AS SELECT * FROM sms WHERE type=1 OR type=2; 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: android.database.sqlite.SQLiteException: table sms_restricted already exists (code 1): , while compiling: CREATE VIEW sms_restricted AS SELECT * FROM sms WHERE type=1 OR type=2; 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: at android.database.sqlite.SQLiteConnection.nativePrepareStatement(Native Method) 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: at android.database.sqlite.SQLiteConnection.acquirePreparedStatement(SQLiteConnection.java:889) 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: at android.database.sqlite.SQLiteConnection.prepare(SQLiteConnection.java:500) 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: at android.database.sqlite.SQLiteSession.prepare(SQLiteSession.java:588) 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: at android.database.sqlite.SQLiteProgram.<init>(SQLiteProgram.java:58) 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: at android.database.sqlite.SQLiteStatement.<init>(SQLiteStatement.java:31) 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: at android.database.sqlite.SQLiteDatabase.executeSql(SQLiteDatabase.java:1677) 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: at android.database.sqlite.SQLiteDatabase.execSQL(SQLiteDatabase.java:1608) 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: at com.android.providers.telephony.MmsSmsDatabaseHelper.upgradeDatabaseToVersion66(MmsSmsDatabaseHelper.java:1721) 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: at com.android.providers.telephony.MmsSmsDatabaseHelper.onUpgrade(MmsSmsDatabaseHelper.java:1466) 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: at android.database.sqlite.SQLiteOpenHelper.getDatabaseLocked(SQLiteOpenHelper.java:256) 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: at android.database.sqlite.SQLiteOpenHelper.getReadableDatabase(SQLiteOpenHelper.java:187) 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: at com.android.providers.telephony.SmsProvider.query(SmsProvider.java:160) 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: at android.content.ContentProvider.query(ContentProvider.java:1020) 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: at android.content.ContentProvider$Transport.query(ContentProvider.java:239) 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:112) 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: at android.os.Binder.execTransact(Binder.java:565) 12-14 11:07:05.218 3179 5307 E MmsSmsDatabaseHelper: Destroying all old data.
Das kommt mir doch irgendwie bekannt vor… Schade, dass der Fehler nicht in der GUI erscheint und man so vermutet, dass alles ohne Störung funktionieren würde. Also löschen wir auch hier die kaputte Datenbank. Leider nicht ganz so einfach, denn zu dieser Meldung schweigen sich die Suchmaschinen aus und auch im Log wird der Dateiname der betroffenen Datenbank leider nicht erwähnt. Abhilfe schafft „Self Rubber Ducking“ , welcher augenscheinlich sehr von Migrationscode angetan ist. Fündig wurde ich dann im Ordner, welcher sich auch schon bei der Telefonie als Verursacher zeigte – hätte man drauf kommen können. Meh.
Also – leicht angepasst:
adb shell su - rm -rf /data/user_de/0/com.android.providers.telephony/databases/mmssms.*
Nach einem Reboot kann dann auch der Fintechler wieder mit mir kommunizieren. Ich wäre ja dafür langsam mal offene Standards für sowas zu schaffen – sowas wie U2F mit angezeigten Transaktionsdaten…
Blog Post: Amdroid/CM: com.android.phone force-close nach Update bit.ly/2hNPmcY
Blog Post: Amdroid/CM: com.android.phone force-close nach Update bit.ly/2hNPmcY
— adlerweb|BitBastelei (@adlerweb) 14.12.2016 16:16
Amdroid/CM: com.android.phone force-close nach Update
Ja, schmutzig ist praktisch – zumindest wenn es um Updates geht. Obwohl die meisten Entwickler empfehlen möglichst bei jedem Update mit einem frischen System zu beginnen versuche ich meine Daten so lange wie möglich mitzuschleifen („Dirty Flash“) – leider gibt es noch immer unzählige Apps, welche keine brauchbare Backup-Funktion bieten und auch systembasierte Lösungen wie Titanium Backup sind leider nicht unfehlbar.
Zuletzt war ich etwas nachlässig – mein Handy war noch auf Version 2, aktuell Version 9 meiner aktuellen ROM. Zeit zum Aktalisieren, vor allem da Dirty Cow gerade bekannt wurde.
Also, Sideload drüber und – narf. „Telefon reagiert nicht mehr“. Gemeint ist hierbei die Telefon-App, also jene, welche Sprachtelefonie ermöglicht. Brauch ich zwar normal nicht, aber die Popups nerven doch etwas.
Über ADB ließ sich folgendes im Log erspähen:
12-06 16:43:32.820 3708 3708 E AndroidRuntime: FATAL EXCEPTION: main 12-06 16:43:32.820 3708 3708 E AndroidRuntime: Process: com.android.phone, PID: 3708 12-06 16:43:32.820 3708 3708 E AndroidRuntime: java.lang.IllegalArgumentException: column 'user_network_mode' does not exist 12-06 16:43:32.820 3708 3708 E AndroidRuntime: at android.database.AbstractCursor.getColumnIndexOrThrow(AbstractCursor.java:333) 12-06 16:43:32.820 3708 3708 E AndroidRuntime: at android.database.CursorWrapper.getColumnIndexOrThrow(CursorWrapper.java:87) 12-06 16:43:32.820 3708 3708 E AndroidRuntime: at com.android.internal.telephony.SubscriptionController.getSubInfoRecord(SubscriptionController.java:293) 12-06 16:43:32.820 3708 3708 E AndroidRuntime: at com.android.internal.telephony.SubscriptionController.getSubInfoUsingSlotIdWithCheck(SubscriptionController.java:1631) 12-06 16:43:32.820 3708 3708 E AndroidRuntime: at com.android.internal.telephony.SubscriptionInfoUpdater.updateSubscriptionInfoByIccId(SubscriptionInfoUpdater.java:593) 12-06 16:43:32.820 3708 3708 E AndroidRuntime: at com.android.internal.telephony.SubscriptionInfoUpdater.handleSimLoaded(SubscriptionInfoUpdater.java:421) 12-06 16:43:32.820 3708 3708 E AndroidRuntime: at com.android.internal.telephony.SubscriptionInfoUpdater.handleMessage(SubscriptionInfoUpdater.java:338) 12-06 16:43:32.820 3708 3708 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:102) 12-06 16:43:32.820 3708 3708 E AndroidRuntime: at android.os.Looper.loop(Looper.java:154) 12-06 16:43:32.820 3708 3708 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:6140) 12-06 16:43:32.820 3708 3708 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method) 12-06 16:43:32.820 3708 3708 E AndroidRuntime: at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:888) 12-06 16:43:32.820 3708 3708 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:778)
Dankenswerterweise gibt es einen passenden Post von Daan, welcher die Ursache genau beschreibt und einen passenden Befehl zum zurücksetzen der defekten Datenbank anbietet. Hierbei gehen ggf. Einstellungen verloren, diese muss man ggf. später von seiner Datensicherung wieder einspielen.
adb shell su - rm -rf /data/user_de/0/com.android.providers.telephony/databases/telephony.*
Nach dem Befehl war dann Ruhe und sogar das telefonieren funktioniert wieder. Fein.
Vermisstensuche. Online. Mit Bild. Hinter Paywall. m(
Vermisstensuche. Online. Mit Bild. Hinter Paywall. m(
— adlerweb|BitBastelei (@adlerweb) 14.12.2016 14:33