Android OS ⇒ Android 2.3.x - konfigurační Default.prop

[Marek marek]

Pěkný den všem,

můj dotaz se týče OS Android a již z nadpisu je snad jasné oč mi jde. Vím a vidím to, že skoro všichni Jelly Beanují jako prdlí , ale asi se ani nebudu plést v tom, že tihle se ani nepokusili ladit verze 2.3.x. Chtěl bych, kdyby mi někdo hodný z odbornějších a moudřejších v Androidu, napsal popis položek co obsahuje default.prop ve verzích 2.3.x (Build.prop znám). Jejich význam (těch 4 položek) prostě. Já to nikde na internetu nemohu najít. Pokud dám do Googlu default.prop nic moc nenajde a popis těch příkazů už vůbec ne
No jde mi o to, znát popis těch příkazů. Je zajímavé, že u svého rootlého tabletu klidně přepíšu build.prop (třeba přepíšu velikost dalviku - tyhle obsažené příkazy se dají lehce vygooglit), uložím, restart a vše je naprosto OK. A pokud to samé udělám u rootlého mobilu, pokud tam cokoliv přepíšu (třeba změním velikost dalviku) a uložím, restaruji a... zacyklí se a fertik prostě.
Napadlo mne, jestli náhodou jen tak čistě - v tom nemá prsty ten default.prop. Nevím, proto se ptám. Na obou zařízeních je odlišný. Napíšu i výpis. Tak děkuji moc, za poučení, rád se poučuju a laboruju (někdy to dopadne ale špatně (viz včera Odin. Ale díky dobrým duším tady, je to v pohodě, jsem moc vděčný a budu)). Děkuji moc.


Android 2.3.x (DEFAULT.PROP)

1 - položka RO.SECURE=0 (dělá přesně co ?) - (tablet 0, mobil 1)
2 - položka RO.ALLOW.MOCK.LOCATION=0 (dělá přesně co ?) -(tablet 0, mobil 0)
3 - položka RO.DEBUGGABLE=1 (dělá přesně co ?) - (tablet 1, mobil 0)
4 - položka PERSIST.SERVICE.ADB.ENABLE=1 (dělá přesně co ?) - (tablet 1, mobil 0)


- stačí odpovědět: 1 dělá ... 2 dělá... (nebo vložte odkaz, kde se něco o tom dovím). Díky moc, kamarádi Androidi

[Marek marek]

Položka 3. Co jsem prozatím vyštrachal složitě a krkolomně přeložil:

Každý VM, který povoleným laděním začíná "JDWP" závit. The thread typically sits idle until DDMS or a debugger connects. Závit obvykle nečinně čeká, až DDMS nebo debugger připojí. The thread is only responsible for handling requests from the debugger; VM-initated communication, such as notifying the debugger when the VM has stopped at a breakpoint, are sent from the affected thread. Nit pouze za vyřizování žádostí z debuggeru, VM-initated komunikace, jako jsou oznámení, když debugger VM se zastavil na unese, jsou zasílány z postižené závitu.

When the VM is started from the Android app framework, debugging is enabled for all applications when the system property ro.debuggable is set to 1 (use adb shell getprop ro.debuggable to check it). Pokud je VM spustit z Android App rámce, je povoleno ladění pro všechny aplikace, pokud systém vlastnost ro.debuggable je nastavena na 1 (použijte adb shell getprop ro.debuggable podívat se na to). If it's zero, debugging can be enabled via the application's manifest, which must include android:debuggable="true" in the <application> element. Pokud je to nula, může být povoleno ladění pomocí aplikace, seznamy, které musí obsahovat android:debuggable="true" v <application> prvku.

The VM recognizes the difference between a connection from DDMS and a connection from a debugger (either directly or in concert with DDMS). VM rozpozná rozdíl mezi připojení od DDMS a spojení z Debugger (buď přímo, nebo ve shodě s DDMS). A connection from DDMS alone doesn't result in a change in VM behavior, but when the VM sees debugger packets it allocates additional data structures and may switch to a different implementation of the interpreter. Spojení z DDMS sám nemá za následek změny v chování VM, ale když vidí, ladicí pakety VM alokuje další datové struktury, a může přejít do jiného plnění tlumočníka.

Because Dalvik maps bytecode into memory read-only, some common techniques are difficult to implement without allocating additional memory. Vzhledem k tomu, Dalvik mapy bytecode do paměti pouze pro čtení, některé běžné techniky jsou obtížně proveditelné bez přidělení další paměti. For example, suppose the debugger sets a breakpoint in a method. Předpokládejme například, že ladicí program nastaví breakpoint v metodě. The quick way to handle this is to insert a breakpoint instruction directly into the code. Rychlý způsob jak to udělat je vložit breakpoint instrukce přímo do kódu. When the instruction is reached, the breakpoint handler engages. Když je dosaženo instrukce, zarážka psovod se zabývá. Without this, it's necessary to perform an "is there a breakpoint here" scan. Bez toho, že je nutné provést "je tam zarážka tady" skenovat. Even with some optimizations, the debug-enabled interpreter is much slower than the regular interpreter (perhaps 5x). Dokonce s některými optimalizace, ladění s podporou tlumočníka je mnohem pomalejší než běžný tlumočníka (možná 5x).

Hmmmm, nevím, že to nikoho tady nezajímá, takové zajímavé ladící věcičky , hmmm, asi jsem tu jediný šťourač do androidu

[Marek marek]

Nový poznatek. Položka RO.DEBUGGABLE=1
V Samsung Galaxy mini pokud je na 1 (origoš 0), v SuperUseru.apk (3.1.x) nyní LZE aktualizovat SU binary. Předtím to nešlo ani omylem a skončilo to chybou.

- po dalším restartu telefonu se hodnota vrátila sama na 0, hmmmm... mě by to zajímalo, fakt, co to je a jak to funguje...

Jinak další tip pro Android a SG mini. Vytočte číslo: hvězda, křížek 9900, křížek. Zvolte v tajném menu DISABLE FAST DORMANCY. A ušetříte si baterku (ale spomalíte 3G - netestováno, jedu přes veřejnou wi-fi).

Jinak jsem zvědav, jestli mi někdo někdy hodí ten popis těch 4 tajemných položek, myslím si, že by to zajímalo více lidí krom teda fazolí