Related
Fatal1ty made me think about the fact that the two versions of HTC Magic sold in Italy come with a different RAM amount:
adb shell cat /proc/meminfo gives these results:
Vodafone: about 98436 KB
TIM: about 192000KB
HOW COULD IT BE???
If it'll be confirmed, would it be legal to sell the same device with different characteristics without informing consumers?
asci said:
Fatal1ty made me think about the fact that the two versions of HTC Magic sold in Italy come with a different RAM amount:
adb shell cat /proc/meminfo gives these results:
Vodafone: about 98436 KB
TIM: about 192000KB
HOW COULD IT BE???
If is it confirmed, would it be legal to sell the same device with different characteristics without informing consumers?
Click to expand...
Click to collapse
if u look at the htc site u will see the original htc magic is listet with 288 mb ram
and the htc brandet witz 192mb ram
so why should this be not legale
kingchris said:
if u look at the htc site u will see the original htc magic is listet with 288 mb ram
and the htc brandet witz 192mb ram
so why should this be not legale
Click to expand...
Click to collapse
Well because to the most of people (consumers) is not asked to be PPC expert and informations should be done clearly, without doubts. So when I go to buy my Magic to Vodafone shop rather than to HTC or TIM shop I should know exactly what I am buying and what are the technical differences...and I also dare to exepct a different price. People generally know that HTC Magic is ONE and it is sold with two different brand (TIM - Vodafone), or no brand, and not that they are different devices technically speaking. Don't you think that if I should know it in advance I would buy the one with more ram at the same price???
EDIT:
and YES, I have checked it and it reports a different RAM amount between HTC and Vodafone...BUT once again, don't you think that this specific has been a little hidden in commercial comunication???
I've been wondering how to find the ram of an Android phone. I just opened /proc/meminfo and found this on my Google Ion:
MemTotal: 98328 kB
MemFree: 3260 kB
Buffers: 8 kB
Cached: 21776 kB
SwapCached: 0 kB
Active: 38508 kB
Inactive: 43660 kB
Active(anon): 30124 kB
Inactive(anon): 31568 kB
Active(file): 8384 kB
Inactive(file): 12092 kB
Unevictable: 1008 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 61416 kB
Mapped: 15660 kB
Slab: 3804 kB
SReclaimable: 760 kB
SUnreclaim: 3044 kB
PageTables: 4092 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 49164 kB
Committed_AS: 1114796 kB
VmallocTotal: 155648 kB
VmallocUsed: 65680 kB
VmallocChunk: 44028 kB
Click to expand...
Click to collapse
So it looks like my Ion has 192MB RAM (96MB for the OS, and the rest is shared with hardware). That's lame, especially for a second-generation, developer-targeted phone.
This is my Vodafone ITA with ION ROM.
MemTotal: 98356 kB
MemFree: 3288 kB
Buffers: 36 kB
Cached: 20996 kB
SwapCached: 0 kB
Active: 37936 kB
Inactive: 43640 kB
Active(anon): 26956 kB
Inactive(anon): 34864 kB
Active(file): 10980 kB
Inactive(file): 8776 kB
Unevictable: 964 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 61532 kB
Mapped: 16248 kB
Slab: 4180 kB
SReclaimable: 876 kB
SUnreclaim: 3304 kB
PageTables: 4044 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 49176 kB
Committed_AS: 1137064 kB
VmallocTotal: 155648 kB
VmallocUsed: 66660 kB
VmallocChunk: 21500 kB
Click to expand...
Click to collapse
Fatal1ty points out that:
- If the the first value is around 100MB it means it has 192 MB (baseband included)
- If the the first value is around 190 MB it means it has 288 MB (baseband included)
MemTotal: 98356 kB
MemFree: 4164 kB
Buffers: 36 kB
Cached: 23480 kB
SwapCached: 0 kB
Active: 38528 kB
Inactive: 43712 kB
Active(anon): 27148 kB
Inactive(anon): 32828 kB
Active(file): 11380 kB
Inactive(file): 10884 kB
Unevictable: 964 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 59712 kB
Mapped: 13048 kB
Slab: 3684 kB
SReclaimable: 844 kB
SUnreclaim: 2840 kB
PageTables: 4020 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 49176 kB
Committed_AS: 1059424 kB
VmallocTotal: 155648 kB
VmallocUsed: 65260 kB
VmallocChunk: 33788 kB
Italian Magic Vodafone with Noverca Rom
cat /proc/meminfo gives me the following results:
MemTotal: 98328 kB
MemFree: 3908 kB
Buffers: 112 kB
Cached: 19228 kB
SwapCached: 0 kB
Active: 36896 kB
Inactive: 44348 kB
Active(anon): 29336 kB
Inactive(anon): 33984 kB
Active(file): 7560 kB
Inactive(file): 10364 kB
Unevictable: 1008 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 62936 kB
Mapped: 11304 kB
Slab: 3900 kB
SReclaimable: 808 kB
SUnreclaim: 3092 kB
PageTables: 4028 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 49164 kB
Committed_AS: 1034044 kB
VmallocTotal: 155648 kB
VmallocUsed: 64652 kB
VmallocChunk: 21500 kB
Click to expand...
Click to collapse
Australian Magic Vodafone with SuperHeroV2 port by Fatal1ty2787 & NK02
I feel so duped, especially considering I am now, somewhat 'stuck' with this phone for the next two years. The reduced memory size on the Vodafone HTC Magic must be what is causing such huge slow downs whilst running the SuperheroV2 ROM...
my-demise said:
cat /proc/meminfo gives me the following results:
Australian Magic Vodafone with SuperHeroV2 port by Fatal1ty2787 & NK02
I feel so duped, especially considering I am now, somewhat 'stuck' with this phone for the next two years. The reduced memory size on the Vodafone HTC Magic must be what is causing such huge slow downs whilst running the SuperheroV2 ROM...
Click to expand...
Click to collapse
Same here.
But i dont think it should cause slowdowns?
If we're sure it does, i might go back to vodafone and claim false advertising. :-/
Ooops. I think, we're buggered.
HTC webpage has 2 magics one for vodafone one not.
clearly states in the specs of the VF has 192MB and on the regular 288MB
I bought my device from Vodafone Germany with Sapphire Rogers Rom:
MemTotal: 98356 kB
MemFree: 1904 kB
Buffers: 1940 kB
Cached: 18832 kB
SwapCached: 0 kB
Active: 39144 kB
Inactive: 43948 kB
Active(anon): 31844 kB
Inactive(anon): 31940 kB
Active(file): 7300 kB
Inactive(file): 12008 kB
Unevictable: 964 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 63308 kB
Mapped: 13612 kB
Slab: 4340 kB
SReclaimable: 1052 kB
SUnreclaim: 3288 kB
PageTables: 4492 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 49176 kB
Committed_AS: 1235236 kB
VmallocTotal: 155648 kB
VmallocUsed: 67316 kB
VmallocChunk: 19452 kB
Qualcomm® MSM7200A™ in HTC magic
Qualcomm® MSM7201a™ in the HTC magic from vodaphone
is there some difference?
looks like its manufacturing process. MSM7201A is 65nm chipset while the MSM7200A is manufactured on the 90nm process.
can anyone confirm?
So htc magic from vodaphone should drain less battery right? =)
You're correct in that it (Vodafone HTC Magic w/ Qualcomm® MSM7201a) will draw less power. In fact I was just about to post those finding now.
I guess in the future it'll be best to read the fine print haha!!
OT:
I suppose the lack of RAM isn't a HUGE deal as thankfully we can move all apps and dalvik-cache to the SDcard to free up what little RAM we already have. In fact I have seen great performance gains by moving all apps, cache and Rosie to my SD card.
192 and 288mb of RAM has nothing to do with the 512mb ROM.
moving apps and caches to your SD card isn't going to free RAM... it will free ROM space, which the Magic has plenty of (unlike the G1).
RAM is for apps that are currently running, and if you open too many it just saves their state and shuts them down until you switch back.
ROM is where everything is stored or "saved". So when you install an app its on your ROM, and when you launch the app it is STILL on your ROM, but is loaded into your RAM while running. I hope that helps the less savvy peeps.
That said, it is unfortunate that we have the 192mb models, as it will have to shut down apps and relaunch them more often... Down the road it might be limiting if we are porting ROMs from the Hero and the fancy interface needs more RAM than we have and things get sluggish. I will likely pickup a Hero as soon as one is available with US 3G bands.
Oh of course! Thanks for clearing that up. Everyone can disregard my previous post - well, except the part about the better power consumption of MSM7201a > MSM7200A
I don't know how to copy/ paste from the terminal emulator, but my HTC Magic with Rogers in Canada has:
Memtotal: 197144
Memfree: 5416
Active: 157248
I guess I should be happy... but at least you guys can root your phones!
Agggh. I created an account just to vent about this after reading this thread.
I cant believe I got so shafted by vodafone. I thought I was getting a phone with roughly the same performance specs as the hero, but instead I've got a dream without a keyboard!
This sucks.
Do you think its possible to upgrade the ram in the phone? Seriously.
diggyz said:
looks like its manufacturing process. MSM7201A is 65nm chipset while the MSM7200A is manufactured on the 90nm process.
can anyone confirm?
So htc magic from vodaphone should drain less battery right? =)
Click to expand...
Click to collapse
The MSM7200a is the 65nm version of the MSM7200 (90nm)
I couldn't find link from manufacturer to proof this, may be someone could.
So there is no difference in power consumption!
But i'm hear, that MSM7201A lacks ability to records vga with 30 fps due qualcomm patent problems.
Maybe it's part of the whole "with Google" initiative and not just Vodaphone. T-Mobile's going to have a "with Google" version, and it's only got 192 megs of ram. :-\ Well, guess this is a non-buyer for me.
http://www.engadget.com/photos/t-mobile-mytouch-3g-user-guide/2102338/
Here are the difference between the HTC and Vodaphone(T-Mobile?):
HTC Magic
Qualcomm® MSM7200A™, 528 MHz
ROM: 512 MB
RAM: 288 MB
Vodaphone
Qualcomm® MSM7201a™, 528 MHz
ROM: 512 MB
RAM: 192 MB
(According to the leaked manual, the MyTouch still has the Qualcomm® MSM7200A™, which tells me that there's actually 3 versions of the phone? If that's correct, then the specs for the T-Mobile version are as follows:
Qualcomm® MSM7200a™, 528 MHz
ROM: 512 MB
RAM: 192 MB
For reference, here's the HTC Dream (G1) and Hero Specs:
HTC Dream or T-Mobile G1
Qualcomm® MSM7201A™, 528 MHz
ROM: 256 MB
RAM: 192 MB
HTC Hero
Qualcomm® MSM7200A™, 528 MHz
ROM: 512 MB
RAM: 288 MB
Ps. Shouldn't this be in the regular section and out of the Dev area?
hmm, so I guess this is why the phone gets sluggish while using the media player, and actually closing down the download of the podcast app if switching to other apps.
I'm sure there is some way to make sdcard work as virtual ram? class 6?
bufodill said:
hmm, so I guess this is why the phone gets sluggish while using the media player, and actually closing down the download of the podcast app if switching to other apps.
I'm sure there is some way to make sdcard work as virtual ram? class 6?
Click to expand...
Click to collapse
If it's rooted, you could use swapper. It's an app that allows for a swapfile.
Hi all,
I can easy remake the bug of wifi sleep!
my ip is auto : 192.168.1.23 and work perfect!
why?
tape in terminal emulator:
iproute:
192.168.1.0/24 << 23MAX
if i put a ip fixe 192.168.1.50 the wifi bug in sleep is here!!!
please make a ip fixe in 192.168.1.2/24 Maximum 23 please !!!!
Reboot after
Nice one
i tried it with ...1.23 and it's not working.
yes he work,
put your ip fixe in 192.168.1.23 etc, deactivate and reactivate your wifi
and reboot
Afraid it made no difference to me... (thought I'd try a static address for the hell of it)
With Dynamic IP (assigned via DHCP)
Code:
# ip route
192.168.5.0/24 dev eth0 src 192.168.5.126
default via 192.168.5.1 dev eth0
# #Screen Awake
# ping 192.168.5.1
PING 192.168.5.1 (192.168.5.1) 56(84) bytes of data.
64 bytes from 192.168.5.1: icmp_seq=1 ttl=64 time=14.5 ms
64 bytes from 192.168.5.1: icmp_seq=2 ttl=64 time=13.7 ms
64 bytes from 192.168.5.1: icmp_seq=3 ttl=64 time=11.9 ms
64 bytes from 192.168.5.1: icmp_seq=4 ttl=64 time=10.5 ms
64 bytes from 192.168.5.1: icmp_seq=5 ttl=64 time=9.33 ms
64 bytes from 192.168.5.1: icmp_seq=6 ttl=64 time=7.44 ms
^C
--- 192.168.5.1 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 7.446/11.276/14.587/2.462 ms
# #Screen Asleep
# ping 192.168.5.1
PING 192.168.5.1 (192.168.5.1) 56(84) bytes of data.
64 bytes from 192.168.5.1: icmp_seq=1 ttl=64 time=810 ms
64 bytes from 192.168.5.1: icmp_seq=2 ttl=64 time=732 ms
64 bytes from 192.168.5.1: icmp_seq=3 ttl=64 time=652 ms
64 bytes from 192.168.5.1: icmp_seq=4 ttl=64 time=881 ms
64 bytes from 192.168.5.1: icmp_seq=5 ttl=64 time=806 ms
64 bytes from 192.168.5.1: icmp_seq=6 ttl=64 time=731 ms
^C
--- 192.168.5.1 ping statistics ---
7 packets transmitted, 6 received, 14% packet loss, time 5998ms
rtt min/avg/max/mdev = 652.954/769.292/881.775/73.098 ms
With Static IP (low-range)
Code:
# ip route
192.168.5.0/24 dev eth0 src 192.168.5.7
default via 192.168.5.1 dev eth0
# #Screen Awake
# ping 192.168.5.1
PING 192.168.5.1 (192.168.5.1) 56(84) bytes of data.
64 bytes from 192.168.5.1: icmp_seq=1 ttl=64 time=1.92 ms
64 bytes from 192.168.5.1: icmp_seq=2 ttl=64 time=43.6 ms
64 bytes from 192.168.5.1: icmp_seq=3 ttl=64 time=14.5 ms
64 bytes from 192.168.5.1: icmp_seq=4 ttl=64 time=2.22 ms
64 bytes from 192.168.5.1: icmp_seq=5 ttl=64 time=10.8 ms
64 bytes from 192.168.5.1: icmp_seq=6 ttl=64 time=9.36 ms
^C
--- 192.168.5.1 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5008ms
rtt min/avg/max/mdev = 1.923/13.753/43.640/14.108 ms
# #Screen Asleep
#
# ping 192.168.5.1
PING 192.168.5.1 (192.168.5.1) 56(84) bytes of data.
64 bytes from 192.168.5.1: icmp_seq=1 ttl=64 time=710 ms
64 bytes from 192.168.5.1: icmp_seq=2 ttl=64 time=937 ms
64 bytes from 192.168.5.1: icmp_seq=3 ttl=64 time=860 ms
64 bytes from 192.168.5.1: icmp_seq=4 ttl=64 time=781 ms
64 bytes from 192.168.5.1: icmp_seq=5 ttl=64 time=702 ms
^C
--- 192.168.5.1 ping statistics ---
6 packets transmitted, 5 received, 16% packet loss, time 5002ms
rtt min/avg/max/mdev = 702.759/798.571/937.408/89.778 ms
I've found this on Google Bugs... Explains what it could possibly be...
http://code.google.com/p/android/issues/detail?id=9781
Also, where you say 23 is MAX, it isn't...
IP Address ranges are defined like that....
It designates a network address in the CIDR notation (Classless Inter-Domain Routing) which is defined in >RFC 1519<. It provides a more flexible notation of network addresses for subnets. The Number after the slash (/) in your case 24 bescribes how many bits of an anddress a uses as network bits, since here the typical subdivision in classes (A=8,B=16,C=24 bits) is no longer the only way to subclass.
So with 192.168.1.0/24 you have still your typical C-class IPv4 network with addresses form 192.168.1.0 - 192.168.1.255.
But you could have the following as well: 192.168.1.0./22 this denotes IPv4 addresses starting at 192.168.1.0 and ending at 192.168.4.255 inclusive, with 192.168.4.255 being the broadcast address for the given network.
wifi policy set to never and i use ip fix with 192.168.1.23 but it's not working goes to sleep. wifi turned off and later turned on but it's not changing result.
I've found this on Google Bugs... Explains what it could possibly be...
http://code.google.com/p/android/issues/detail?id=9781
Also, where you say 23 is MAX, it isn't...
IP Address ranges are defined like that....
It designates a network address in the CIDR notation (Classless Inter-Domain Routing) which is defined in >RFC 1519<. It provides a more flexible notation of network addresses for subnets. The Number after the slash (/) in your case 24 bescribes how many bits of an anddress a uses as network bits, since here the typical subdivision in classes (A=8,B=16,C=24 bits) is no longer the only way to subclass.
So with 192.168.1.0/24 you have still your typical C-class IPv4 network with addresses form 192.168.1.0 - 192.168.1.255.
But you could have the following as well: 192.168.1.0./22 this denotes IPv4 addresses starting at 192.168.1.0 and ending at 192.168.4.255 inclusive, with 192.168.4.255 being the broadcast address for the given network.
Click to expand...
Click to collapse
LOL never been so confused in my life
me too, ...
When i put my ip in 192.168.1.1/23 no wifi sleep issue ... after 23 ... issue bug for me
meLIanTQ said:
me too, ...
When i put my ip in 192.168.1.1/23 no wifi sleep issue ... after 23 ... issue bug for me
Click to expand...
Click to collapse
Tried your proposal but no success. I even configured my router to only DHCP the IPs you mentioned.
I think Paul is right here and is it hard to understand what HTC is doing for this? I.e. reverse engineer their ROMs and see how they solve the problem.
I am trying to figure out how to change the max sending size for MMS on the EVO. By default when sending pictures it compresses them down to around 60k. It was accomplished on the Nexus One HERE and the G1 HERE. The MMS.apk for the EVO does not have the same file to modify as the Nexus One, and I can't figure out which xml to edit. The default compression for MMS is ridiculous on the EVO, by default when sending pictures it compresses them down to around 60k. We should be able to set it to 300k and not have any problems.
No offense to anyone, but please do NOT reply with "hancent works for this, xxx can do this, such and such fixed this", or any other app/ROM/etc for that matter.
I am asking how to modify the stock EVO MMS app, not how to install a different ROM or app!
Here is the original EVO MMS.apk (Froyo)
the max on the Evo is 2m it would be nice to have more but thats the max the way you see what your max is set to is go to all message screen then press menu go to settings then it will be maximum message size
stercast said:
the max on the Evo is 2m it would be nice to have more but thats the max the way you see what your max is set to is go to all message screen then press menu go to settings then it will be maximum message size
Click to expand...
Click to collapse
I don't think you understand my question/problem. Read the Nexus One link in the OP. The issue is when sending MMS, the EVO compresses the living hell out of any image. That 2mb setting you are referring to is not the same thing, that is an overall message size, not individual image size.
I was wondering if anyone else was annoyed by this. I wish I could help you in some way though..
I hope this gets resolved.
i believe the evio rom fixed this issue
zaft1 said:
i believe the evio rom fixed this issue
Click to expand...
Click to collapse
Well, the dev of that ROM says he fixed this, but not how. It would be nice if he would share the fix with everyone.
I sure hope someone gets this done, the compression is really annoying.
Tapatalk'd on Evo
Could a possible workaround be to zip said pic and send the zip? I don't remember if I tested this or not when I was experimenting with the mms apps.
SteelH
I have looked in the preference_att.xml and preference.xml and found pref_key_mms_max_size. I dont understand binary so I am not much help here.
dwertz said:
SteelH
I have looked in the preference_att.xml and preference.xml and found pref_key_mms_max_size. I dont understand binary so I am not much help here.
Click to expand...
Click to collapse
I saw that as well, but there is no byte size near it to edit like in the Nexus One.
SteelH said:
I saw that as well, but there is no byte size near it to edit like in the Nexus One.
Click to expand...
Click to collapse
Have you asked Calkulin yet if he would let you know what he did to fix it? I would hope the open nature of everything he would gladly help.
MrDSL said:
Have you asked Calkulin yet if he would let you know what he did to fix it? I would hope the open nature of everything he would gladly help.
Click to expand...
Click to collapse
I have asked him, he has not replied. Also, I can tell you simply using the mms.apk from his ROM will not solve the compression problem.
if you use chomp sms there's a selection for no limit on mms size you could pull that apk apart and see what it uses to regulate the size limit
BLOWNCO said:
if you use chomp sms there's a selection for no limit on mms size you could pull that apk apart and see what it uses to regulate the size limit
Click to expand...
Click to collapse
Good suggestion but unfortunately that won't help us.
I hope someone fixes this issue. I always wondered why the stock MMS compresses images so much. Its terrible. I shall be keeping watch for anything.
Is there a way to be able to dicifer logcat by starting it right when you add the picture and when it autosizes to see what's doing it? Here is a logcat of when I attach a picture to mms when it auto resizes if anyone knows whats doing it.
Code:
D/ComposeMessageActivity( 564): initFocus: true
D/ComposeMessageActivity( 564): syncRecipientListButton:
D/ComposeMessageActivity( 564): mRecipientList.size(): 0
D/Jerry1 ( 564): 2222
I/XT9_C ( 195): [loadDefaultDB] xt9_raw/ldb_0409.ldb size=98056 (loaded)
I/XT9_C ( 195): [registerXT9LDB] ldb_0409.ldb loading [done]
D/XT9_ldb ( 195): wLdbNum=109, first wLdbNum=109, second wLdbNum=0
D/XT9_C ( 195): [registerXT9LDB] current LdbNum=109, First LdbNum=109, Second LdbNum=0
D/dalvikvm( 195): GC_EXTERNAL_ALLOC freed 304 objects / 15192 bytes in 164ms
D/ComposeMessageActivity( 564): get the ContactNameCache
D/MainActivity( 5880): [HTCAlbum][MainActivity][onStop]: Begin
D/dalvikvm( 564): GC_EXTERNAL_ALLOC freed 402 objects / 49256 bytes in 56ms
D/dalvikvm( 564): GC_FOR_MALLOC freed 70 objects / 25688 bytes in 41ms
I/dalvikvm-heap( 564): Grow heap (frag case) to 3.863MB for 63504-byte allocation
D/dalvikvm( 564): GC_FOR_MALLOC freed 0 objects / 0 bytes in 69ms
D/dalvikvm( 564): GC_FOR_MALLOC freed 4 objects / 30840 bytes in 41ms
I/dalvikvm-heap( 564): Grow heap (frag case) to 3.957MB for 129040-byte allocation
D/dalvikvm( 564): GC_FOR_MALLOC freed 0 objects / 0 bytes in 65ms
D/dalvikvm( 564): GC_FOR_MALLOC freed 7 objects / 67784 bytes in 48ms
D/dalvikvm( 564): GC_FOR_MALLOC freed 7 objects / 129272 bytes in 42ms
V/MmsProvider( 212): Insert uri=content://mms/9223372036854775807/part, match=11
D/dalvikvm( 5880): GC_EXPLICIT freed 1562 objects / 103600 bytes in 585ms
D/MainActivity( 5880): [HTCAlbum][MainActivity][onDestroy]: Begin
V/MmsProvider( 212): Query uri=content://mms/part/43, match=12
V/PduPersister( 564): Saving data to: content://mms/part/43
D/MediaPicker( 564): --------original uri: content://mms/part/43, type: null
V/MmsProvider( 212): Query uri=content://mms/part/43, match=12
V/MmsProvider( 212): Query uri=content://mms/part/43, match=12
D/UriImage( 564): ---------mContentType: image/jpeg
V/MmsProvider( 212): Query uri=content://mms/part/43, match=12
D/ComposeMessageActivity( 564): onMediaPicked:media: image/jpeg
I/MessageBodyEditor( 564): addMedia:> [email protected]
D/ComposeMessageActivity( 564): updateMessageBodyContentUI:
V/ComposeMessageActivity( 564): Message type: SMS -> MMS
D/MessageTextEditor( 564): resetCounter:SmsMode> false
D/ComposeMessageActivity( 564): checkReachRecipientMaxNumber> 0, updateUI> true
D/MessageBodyEditor( 564): EditableMediaViewFactory.create()[email protected]
I/EditableMediaViewImpl( 564): onFinishInflate:
D/MessageUtils( 564): loadThumbnailBitmap: content://mms/part/43
D/dalvikvm( 212): GC_FOR_MALLOC freed 11212 objects / 585848 bytes in 60ms
V/MmsProvider( 212): Query uri=content://mms/part/43, match=12
V/MmsProvider( 212): Query uri=content://mms/part/43, match=12
D/dalvikvm( 564): GC_FOR_MALLOC freed 1222 objects / 345504 bytes in 43ms
V/MmsProvider( 212): Query uri=content://mms/part/43, match=12
D/MessageUtils( 564): Create message thumbnail cache file: /data/data/com.android.mms/cache/PART_1282502974576
D/OnlineDataCenter( 5880): [HTCAlbum][OnlineDataCenter][unbindContext]: Begin
D/OnlineDataCenter( 5880): [HTCAlbum][OnlineDataCenter][unbindContext]: [email protected] size: 0
D/OnlineDataCenter( 5880): [HTCAlbum][OnlineDataCenter][unbindContext]: No more clients. release resources.
D/OnlineDataCenter( 5880): [HTCAlbum][OnlineDataCenter][unbindContext]: End 0
I/XT9_C ( 195): [loadDefaultDB] xt9_raw/ldb_0409.ldb size=98056 (loaded)
D/ThumbnailWorker( 5880): [stopWorking] Stop working, now join #-1, Decode Complete!!
I/XT9_C ( 195): [registerXT9LDB] ldb_0409.ldb loading [done]
D/XT9_ldb ( 195): wLdbNum=109, first wLdbNum=109, second wLdbNum=0
D/XT9_C ( 195): [registerXT9LDB] current LdbNum=109, First LdbNum=109, Second LdbNum=0
D/AlbumAdapter( 5880): set thread priority to normal
D/AlbumMapper( 5880): cancel current decode operation
D/AlbumMapper( 5880): cancel current decode operation
D/ThumbnailWorker( 5880): [stopWorking] Stop working, now join #-1, Decode Complete!!
D/AlbumAdapter( 5880): set thread priority to normal
D/AlbumAdapter( 5880): Join worker thread in destroy
D/AlbumAdapter( 5880): Join time: 0
D/dalvikvm( 195): GC_EXTERNAL_ALLOC freed 250 objects / 13312 bytes in 88ms
I/MainActivity( 5880): mWorker finishes jobs at onDestroy().
D/CollectionsActivity( 5880): [HTCAlbum][CollectionsActivity][onDestroy]: Begin
D/AlbColAdap( 5880): [HTCAlbum][AlbumCollectionsAdapter][onDestroy]: Begin
D/AlbColAdap( 5880): [HTCAlbum][AlbumCollectionsAdapter][onDestroy]: End
Yeah someone needs to fix this?
MrDSL said:
Have you asked Calkulin yet if he would let you know what he did to fix it? I would hope the open nature of everything he would gladly help.
Click to expand...
Click to collapse
Good idea Ill shoot him a pm
Calkulins rom sends out mms uncompressed?
Tapatalk'd on Evo
brol1k said:
Calkulins rom sends out mms uncompressed?
Tapatalk'd on Evo
Click to expand...
Click to collapse
His evio rom changelog says mms compression is fixed.
Something else I noticed, if I take an 8MP shot and try to MMS it, it gets squashed down to 60k. If I take a 5MP shot and MMS it, it gets squashed to 300K. Something is clearly screwed up there. So if I send a 5MP image it comes out 5x better than an 8MP image via MMS.
I'm trying to build CM10.1 following these instructions: http://wiki.cyanogenmod.org/w/Build_for_p3110 for the GT-P3110 tablet (wifi only). I already installed the latest M build on the device but am getting the following output when running extract-files.sh:
Code:
~/android/system/device/samsung/p3110$ ./extract-files.sh
Pulling common files...
56 KB/s (5596 bytes in 0.096s)
299 KB/s (39248 bytes in 0.128s)
629 KB/s (2220784 bytes in 3.443s)
152 KB/s (15012 bytes in 0.096s)
remote object '/system/bin/smc.ini' does not exist
remote object '/system/bin/smc_pa.ift' does not exist
521 KB/s (180925 bytes in 0.338s)
529 KB/s (200010 bytes in 0.368s)
498 KB/s (189219 bytes in 0.371s)
542 KB/s (186061 bytes in 0.335s)
16 KB/s (1018 bytes in 0.059s)
16 KB/s (1017 bytes in 0.058s)
545 KB/s (297924 bytes in 0.533s)
371 KB/s (60536 bytes in 0.159s)
53 KB/s (5360 bytes in 0.097s)
57 KB/s (5508 bytes in 0.094s)
149 KB/s (14548 bytes in 0.095s)
57 KB/s (5732 bytes in 0.097s)
147 KB/s (14740 bytes in 0.097s)
189 KB/s (18880 bytes in 0.097s)
198 KB/s (18944 bytes in 0.093s)
251 KB/s (23340 bytes in 0.090s)
603 KB/s (471986 bytes in 0.763s)
324 KB/s (52896 bytes in 0.159s)
remote object '/system/lib/libion.omap4.so' does not exist
139 KB/s (14268 bytes in 0.099s)
95 KB/s (9620 bytes in 0.098s)
143 KB/s (14036 bytes in 0.095s)
317 KB/s (52011 bytes in 0.160s)
640 KB/s (5132164 bytes in 7.821s)
432 KB/s (99632 bytes in 0.224s)
635 KB/s (2444080 bytes in 3.755s)
385 KB/s (72976 bytes in 0.184s)
297 KB/s (38160 bytes in 0.125s)
Pulling device specific files...
270 KB/s (45380 bytes in 0.163s)
140 KB/s (13768 bytes in 0.095s)
235 KB/s (31256 bytes in 0.129s)
adbd is already running as root
Pulling common files...
remote object '/system/etc/powervr.ini' does not exist
remote object '/system/vendor/bin/pvrsrvctl_SGX540_120' does not exist
remote object '/system/vendor/bin/pvrsrvctl_SGX544_112' does not exist
remote object '/system/vendor/bin/pvrsrvinit' does not exist
47 KB/s (4812 bytes in 0.098s)
remote object '/system/vendor/lib/egl/libEGL_POWERVR_SGX544_112.so' does not exist
582 KB/s (445892 bytes in 0.747s)
remote object '/system/vendor/lib/egl/libGLESv1_CM_POWERVR_SGX544_112.so' does not exist
575 KB/s (371532 bytes in 0.630s)
remote object '/system/vendor/lib/egl/libGLESv2_POWERVR_SGX544_112.so' does not exist
remote object '/system/vendor/lib/hw/gralloc.omap4430.so' does not exist
remote object '/system/vendor/lib/hw/gralloc.omap4460.so' does not exist
remote object '/system/vendor/lib/hw/gralloc.omap4470.so' does not exist
remote object '/system/vendor/lib/libIMGegl_SGX540_120.so' does not exist
remote object '/system/vendor/lib/libIMGegl_SGX544_112.so' does not exist
remote object '/system/vendor/lib/libPVRScopeServices_SGX540_120.so' does not exist
remote object '/system/vendor/lib/libPVRScopeServices_SGX544_112.so' does not exist
remote object '/system/vendor/lib/libglslcompiler_SGX540_120.so' does not exist
remote object '/system/vendor/lib/libglslcompiler_SGX544_112.so' does not exist
remote object '/system/vendor/lib/libpvr2d_SGX540_120.so' does not exist
remote object '/system/vendor/lib/libpvr2d_SGX544_112.so' does not exist
remote object '/system/vendor/lib/libpvrANDROID_WSEGL_SGX540_120.so' does not exist
remote object '/system/vendor/lib/libpvrANDROID_WSEGL_SGX544_112.so' does not exist
remote object '/system/vendor/lib/libsrv_init_SGX540_120.so' does not exist
remote object '/system/vendor/lib/libsrv_init_SGX544_112.so' does not exist
remote object '/system/vendor/lib/libsrv_um_SGX540_120.so' does not exist
remote object '/system/vendor/lib/libsrv_um_SGX544_112.so' does not exist
remote object '/system/vendor/lib/libusc_SGX540_120.so' does not exist
remote object '/system/vendor/lib/libusc_SGX544_112.so' does not exist
Thinking "oh well, that can't be that bad" I continued with the build only for it to break with this message message:
Code:
make: *** No rule to make target `vendor/samsung/omap4-common/proprietary/system/etc/powervr.ini', needed by `/home/gardarh/android/system/out/target/product/p3110/system/etc/powervr.ini'. Stop.
make: *** Waiting for unfinished jobs....
I searched for the powervr.ini file on the entire device without luck.
Copying those files from a working CM10.1 build should work, right? Where would I find them in order to complete my build?
PS. This is my first attempt at ever building CM so don't rule out noobish mistakes
ⴰⵣⵓⵍ,
When i say dead, it's typically dead.
The tablet is a Crius Mea Q7A+, uses the Qualcomm MSM8625 SoC based on the ARMv7-A arch that combines 2 ARM Cortex-A5.
While this tablet was just bricked for a long while, and i couldn't and didn't have time and firmware to reflash it, since it's one of those useless chinese low end tablets.
Having such a desirable SoC for a programmer i thought i can test on it my first steps bootloaders and Embedded OS while developing them for this sole purpose.
ⵣ Space to avoid readers jumping lines ⵣ
The tablet after i flashed it with a lower firmware of an equivalent or almost another SoC, was booting in fastboot mode only thinking that i could get more info's with that about partitions.
I didn't, so what i did was erasing the modem partition, and that left the tablet open as a generic storage drive, i saved almost every information i could have about this SoC, the partition that were available, Qualcomm's boot sequence, UART serial connection of the SoC, and read for week several pages to gather information useful to make a bootloader.
ⵣ Space to avoid readers jumping lines ⵣ
At the end i failed, i thought i could repartition the Flash memory of the SoC to prepare it for future uploading of my bootloader, there was a partition that is miss aligned, which was maybe the 3gb internal storage, so what i did is delete the partition and recreate it erasing the secondary ones, it was working normally as expected.
But then tomorrow i decided to plug the tablet again, but it doesn't get detected, this happened before, i cant really explain how the Primary core is trying to establish connection with the PC, but it's a bad mofo. Still it was detected all the time if i remember well.
But today the tablet was dead, i can even feel the SoC is not responding at all.
Not even detected when plugged to PC.
The battery does charges, cause i tested with a diode since i dont have a multimeter, which burned even with a resistor after the current was too high, but then with a DC brushless motor.
Mainly the charging circuit is separated from other components and connected directly to DC, that's why it's charging.
I opened the tablet, and took off the battery cables thinking i might be able to get the core to QDload mode which pressing some combinations...
And yeah i tried every combination i can think off, i even tried pressing my mouse in the PC and pressing the Vol UP in the tablet... am so funny.
I hope anyone can tell me a way to communicate with the SoC in this state, or any other solution thanks peace.
Finally i forgot the partition i saved as a text before i repartitioned the last ones only :
Code:
Disk /dev/sdd: 3.7 GiB, 3909091328 bytes, 7634944 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sdd1 * 1 40 40 20K 4d QNX4.x
/dev/sdd2 41 540 500 250K 45 unknown
/dev/sdd3 541 102940 102400 50M c W95 FAT32 (LBA)
/dev/sdd4 102941 7634943 7532003 3.6G 5 Extended
/dev/sdd5 131072 135167 4096 2M 46 unknown
/dev/sdd6 135168 141311 6144 3M 58 unknown
/dev/sdd7 141312 147455 6144 3M 4a unknown
/dev/sdd8 147456 153599 6144 3M 4b unknown
/dev/sdd9 153600 157695 4096 2M 5d unknown
/dev/sdd10 157696 165887 8192 4M 90 unknown
/dev/sdd11 165888 167935 2048 1M 63 GNU HURD or SysV
/dev/sdd12 167936 169471 1536 768K 47 unknown
/dev/sdd13 169472 196623 27152 13.3M 60 unknown
/dev/sdd14 196624 217103 20480 10M 91 unknown
/dev/sdd15 217104 413711 196608 96M 83 Linux
/dev/sdd16 413712 440863 27152 13.3M 48 unknown
/dev/sdd17 440864 1362463 921600 450M 83 Linux
/dev/sdd18 1362464 1567263 204800 100M 83 Linux
/dev/sdd19 1567264 1567303 40 20K 4c unknown
/dev/sdd20 1567304 4536903 2969600 1.4G c W95 FAT32 (LBA)
/dev/sdd21 4536904 7510599 2973696 1.4G 83 Linux
/dev/sdd22 7510600 7634942 124343 60.7M 83 Linux
As you can the sdd4 partition was overlapping other partitions sectors so i had to erase it, the rest got erased in the way, but the main boot and from 1 to 3 are intact.
Something else, the MSM7627a is a close SoC to this one, except for the one i have got 2 Cores instead of one, and supports LPDDR and have a more developed GPU, here's a note i wrote :
Code:
MSM7627 seems close enough to the MSM8625, except that it uses a single core ARMv7-A CORTEX A5.
Which is the primary core that we need to boot up, then add the next core to the equation for the kernel.
Some differences about the MSM7627a and the MSM8625 :
MSM7627a | MSM8625
CPU Clock Speed 1,000MHz 1,200MHz
CPU Cores 1 2
GPU Qualcomm Adreno 200 Qualcomm Adreno 203
RAM Interface LPDDR2 SDRAM LPDDR, LPDDR2 SDRAM
As we can see here, they are almost identical, except for the cores which wont make a wall since we're making a bootloader, the GPU... and the RAM interface
Am on Debian Stretch and i dont have any ways of visualization but i accept any link on any platform. Thanks everyone peace again
I also want to add, that i can feel a bit of heat over the tablet it's certainly not from the battery, i dont really know if its coming from the SoC, but if it is am really glad he's doing some cycles.
And i thought i had a chance in this forum lol. looks like am on ma own.